JEV ゲーム デモは、抽象的な質問を観察可能な質問に変えます。意思決定モデルは、変化する Game State を受け取り、Legal Actions の中から選択し、ゲームを続行する必要がある前に有用な答えを返すことができますか? JEV はエンジンの代替品ではありません。これは、より大きなゲーム ループ内の制限された決定ステップです。具体的な参照については、JEV 破滅実験 を比較してください。 JEV Pong 実装_、_NPC アーキテクチャ ガイド_、 JEV ラボ ボードゲームとローカル -NPC の例_。これらは研究すべき例であり、すべてのゲームが同じレイテンシーまたは統合コントラクトを共有することを保証するものではありません。JEV ゲーム デモが証明する便利なデモにより、境界が可視化されます。ゲーム コードは世界の状態とルールを所有し、現在可能なアクションを生成し、JEV に型指定された決定を評価するように要求し、実行前に答えを検証します。一般的な例としては、アーケード スタイルのゲーム、ボードゲームのポジション、Doom や Pong などのリアルタイム制御の実験などが挙げられます。詳細は異なりますが、パターンは状態が入力され、制限された決定が出力されます。ゲーム ループ内で JEV が位置する場所信頼できる事実を観察してください。フィルタ不可能アクション。JEV に入力した質問をします。現在の質問に対する応答を検証します。状態。コマンド、動作ツリー、アビリティ システム、またはコントローラーを通じて実行します。イベント、完了したインテント、または制限された後に再検討します。タイマー。レンダリングと物理演算はフレームごとに実行される可能性がありますが、戦術的な決定の実行は遅くなります。レンダリングされたフレームごとにデシジョン サービスを呼び出すと、遅延とジッターが追加されます。 JEV は意味のある Choice を処理する必要があります。ステアリング、衝突、アニメーション、レプリケーション、およびマルチプレイヤー権限は決定論的なシステムに留まります。ゲーム コードが所有する世界状態、物理学、ナビゲーション、衝突、衝突検出、権限。NPCの認識と情報Legal Actions、パラメータ、前提条件、および実行ハンドラ。タイムアウト、古い応答チェック、レート制限、フォールバック の動作。JEV の貢献JEV は、候補者 Score を 1 人選択するか、限定された「はい」または「いいえ」の質問に答えることができます。これは、ゲームが提示した Choice に対する状況依存の判断に貢献します。完全なアクションシーケンスを考え出すべきではありません。 3 ～ 6 つの意味のあるオプションから始めて、既存のゲーム コード内で実行を続けます。レイテンシー、周波数、普遍的なリズムはありません。ターンベースのゲームでは、ターンごとに 1 回決定することができます。戦術ゲームでは、脅威が出現した後、または数百ミリ秒ごとに決定が行われる場合があります。探検仲間は、その目標がいつ変更されるかを決めるかもしれません。状態のキャプチャから検証された実行までの完全なパスを測定します。すべてのリクエストには期限が必要です。遅れている場合は、現在のインテントを維持し、カバーに移動するか、作成されたビヘイビアー ツリーを実行するか、ポジションを保持します。デモの評価方法状態投影と Legal Actions が表示されるかどうか、無効な応答が安全に拒否されるかどうか、決定リズムがレンダリングとは別個であるかどうか、および決定論的な フォールバック が表示されるかどうかを確認します。強力なデモでは、選択したアクション、遅延、有効性、および フォールバック 理由が記録されます。比較する価値のある 4 つのデモ パターンアーケード デモは、小さな状態での rAPId アクションの選択をテストします。 Doom のような実験では、視覚的な状態が急速に変化する間、エージェントが動作を継続できるかどうかをテストします。 Pong や類似のゲームでは、アクション スペースが明確になり、期限を過ぎたことがすぐに明らかになります。 NPC またはボードゲームのデモは、時間はかかりますが内容の濃い質問をテストします: モデルはルールの所有権を持たずに目標、脅威、合法的な動きを比較検討できますか?これらのデモは、単一のヘッドライン レイテンシで比較しないでください。これらは、観察コスト、アクション数、ネットワーク パス、レンダリング ループ、フォールバック ポリシーが異なります。公正な比較では、各実行の同じフィールド (状態サイズ、候補数、決定期限、中央値と末尾の待ち時間、有効結果率、フォールバック 率、タスクの結果) が記録されます。実践的なデモ Scoreカード寸法何記録するその理由件 _決定ケイデンスイベント駆動、ターンベース、または時間指定モデルが右側で使用されているかどうかを示しますレイヤーアクションスペース候補数とパラメータのタイプ結果が制限されているかどうかを明らかにしますテスト可能 鮮度状態バージョンと古い結果率ライブでの競合状態を測定します再生
_フォールバック動作タイムアウトまたは無効な出力の後デモを回復力のあるゲームから分離しますシステム__ _結果勝利レート、生存率、目標の進捗状況、または設計者の評価モデルではなく有用な動作を測定しますアクティビティデモを本番スライスに変換決定的なベースライン ポリシーを記録します。明確な所有者と 3 ～ 6 つの決定を 1 つ選択してくださいLegal Actions.ネットワーク呼び出しをライブ レベルに追加する前に、記録された状態をオフラインで再生します。期限とフォールバック秒前にアクション スペースを拡張します。品質、レイテンシ、コスト、およびフォールバックレートを比較してください最強のJEVゲームページは、単なるギャラリーではありません。デモで何が証明され、何が証明されないか、出荷前にチームがどのエンジニアリング証拠を収集する必要があるかについて説明します。NPC アーキテクチャについては、JEV を参照してください。 API 契約については、JEV API 使用法 を参照してください。 Unity 統合については、JEV Unity チュートリアル., and the Jev Lab board-game and local-NPC example. These are examples to study, not a guarantee that every game shares the same latency or integration contract.What JEV game demos prove
A useful demo makes the boundary visible. Game code owns world state and rules, produces the actions currently possible, asks JEV to evaluate a typed decision, and validates the answer before execution. Public examples include arcade-style games, board-game positions, and real-time control experiments such as Doom or Pong. Their details differ, but the pattern is state in, bounded decision out.
Where JEV sits in the game loop
Observe authoritative facts.
- Filter impossible actions.
- Ask JEV a typed question.
- Validate the response against the current state.
- Execute through a command, behavior tree, ability system, or controller.
- Reconsider after an event, completed intent, or bounded timer.
- Rendering and physics may run every frame, while a tactical decision runs more slowly. Calling a decision service every rendered frame adds latency and jitter. JEV should handle meaningful choices; steering, collision, animation, replication, and multiplayer authority stay in deterministic systems.
What game code owns
World state, physics, navigation, collision, hit detection, and authority.
- Perception and the information an NPC is allowed to know.
- Legal actions, parameters, preconditions, and execution handlers.
- Timeouts, stale-response checks, rate limits, and フォールバック behavior.
- What JEV contributes
JEV can choose one candidate, score candidates, or answer a bounded yes-or-no question. It contributes context-sensitive judgment over choices the game has presented; it should not invent a complete action sequence. Start with three to six meaningful options and keep execution inside existing game code.
Latency, frequency, and フォールバック
There is no universal cadence. A turn-based game may decide once per turn; a tactics game may decide after a threat appears or every few hundred milliseconds; an exploration companion may decide when its goal changes. Measure the complete path from state capture to validated execution. Every request needs a deadline. If it is late, keep the current intent, move to cover, run an authored behavior tree, or hold position.
How to evaluate a demo
Check whether the state projection and legal actions are visible, whether an invalid response is rejected safely, whether decision cadence is separate from rendering, and whether a deterministic フォールバック is shown. A strong demo logs the selected action, latency, validity, and フォールバック reason.
Four demo patterns worth comparing
Arcade demos test rapid action selection over a small state. A Doom-like experiment tests whether the agent can keep acting while the visual state changes quickly. Pong and similar games make the action space obvious and expose missed deadlines immediately. NPC or board-game demos test a slower but richer question: can the model weigh goals, threats, and legal moves without taking ownership of the rules?
These demos should not be compared by a single headline latency. They differ in observation cost, action count, network path, rendering loop, and フォールバック policy. A fair comparison records the same fields for each run: state size, candidate count, decision deadline, median and tail latency, valid-result rate, フォールバック rate, and task outcome.
A practical demo scorecard
Dimension
| What to record | Why it matters | Decision cadence |
|---|---|---|
| Event-driven, turn-based, or timed | Shows whether the model is used at the right layer | Action space |
| Candidate count and parameter types | Reveals whether the result is bounded and testable | Freshness |
| State version and stale-result rate | Measures race conditions in live play | Fallback |
| Behavior after timeout or invalid output | Separates a demo from a resilient game system | Outcome |
| Win rate, survival, objective progress, or designer rating | Measures useful behavior rather than model activity | Turning a demo into a production slice |
Record a deterministic baseline policy.
- Choose one decision with a clear owner and three to six legal actions.
- Replay recorded states offline before adding network calls to a live level.
- Introduce deadlines and フォールバックs before expanding the action space.
- Compare quality, latency, cost, and フォールバック rate separately.
- The strongest JEV game page is therefore not just a gallery. It explains what the demo proves, what it does not prove, and which engineering evidence a team should collect before shipping.
For NPC architecture, read
JEV NPC. For the API contract, see JEV API usage. For Unity integration, continue to the JEV Unity tutorial..
