_このチュートリアルでは、小規模な JEV 統合について説明します。NPC はコンパクトな Game State を受け取り、1 つの実行可能なアクションを選択し、通常のゲーム コードを通じてそのアクションを実行します。この例は意図的に控えめにしています。信頼できる 3 つのアクション NPC は、状態、権限、フォールバック の動作が不明瞭な大規模なエージェントよりも多くのことを教えます。API の名前と SDK の詳細は統合によって異なる場合があります。アーキテクチャ上の契約は変わりません。ゲームが真実を所有し、JEV が実行可能な選択肢から選択し、実行者は世界を変更する前に Choice を検証します。最小の有用な統合権威のある Game State、状態プロジェクション、法的措置ビルダー、JEV クライアント、およびアクション実行プログラムの 5 つの部分を使用します。状態投影では、無関係な詳細が削除されます。アクション ビルダーは現在の前提条件を付加します。クライアントは決定リクエストを送信します。エグゼキュータは、応答がまだ有効であることを確認し、それを移動、能力、またはアニメーション コマンドに変換します。_
game state -> state projection -> JEV decision -> validation -> executor -> game state
_Unity では、これらの部分は MonoBehaviour、ゲームプレイ サービス、およびコマンド コンポーネントにまたがって存在する可能性があります。 Unreal では、アクターまたはマス プロセッサ、サブシステム、およびゲームプレイ アビリティまたはビヘイビア ツリー タスクにマップされる場合があります。名前は異なりますが、所有権の境界は明示的なままにする必要があります。ステップ 1: コンパクトな を設計する次の決定を変える可能性のある事実から始めます。戦闘 NPC の場合、それは役割、健康率、目に見える敵、最も近いカバー、味方の健康状態、目標ステータス、弾薬、クールダウン、現在のアクション、単調な状態バージョンなどです。生のエンジン オブジェクトや世界全体を送信することは避けてください。コンパクトなスキーマは、検査、送信、および再生が容易です。_
{ agentId: 'guard-07', role: 'defender', healthRatio: 0.42, objectiveUnderThreat: true, visibleThreats: 1, ammo: 3, healReady: true, stateVersion: 1842 }
game state -> state projection -> JEV decision -> validation -> executor -> game state、 _攻撃_、および撤退_。弾薬がゼロの場合、_攻撃
は送信されません。安全なカバーが存在しない場合は、_takeCover を送信しないでください。_
[ { name: 'takeCover', coverId: 'wall-a' }, { name: 'attack', targetId: 'raider-02' }, { name: 'holdPosition', locationId: 'relay' } ]
{ agentId: 'guard-07', role: 'defender', healthRatio: 0.42, objectiveUnderThreat: true, visibleThreats: 1, ammo: 3, healReady: true, stateVersion: 1842 }const decision = await jev.decide({ agent: npc, gameState: projectState(state), legalActions: buildLegalActions(state), objective: 'Protect the relay', stateVersion: state.version });
_遅れた応答を盲目的に適用しないでください。リクエストが実行されている間に世界が変わった可能性があります。応答の状態バージョンと現在のバージョンを比較し、選択したアクションを再検証します。ステップ 4: 実行および検証執行者が最終権限を持ちます。アクションが現在のリーガルアクションセットに存在すること、そのターゲットがまだ存在すること、NPC の動作が許可されていること、および状態バージョンがアクションに対して古すぎないことをチェックします。その後、通常の動作、能力、またはビヘイビア ツリー コードを呼び出します。_
const action = legalActions.find(candidate => candidate.name === decision.name);
if (!action || !matchesParameters(action, decision)) return フォールバック(state);
return executor.run(action);_サービスが信頼できる場合でも検証が行われる必要があります。古い状態、競合状態、スキーマ ドリフト、およびゲーム コントラクトに一致しない偶発的なモデル出力から保護します。ステップ 5: 決定頻度の設定レンダー ループではなく、決定に基づいてケイデンスを選択します。ターンベースの NPC はターンの開始時に決定できます。リアルタイムの戦闘員は、現在の意図がいつ完了するか、いつ脅威が認識されるか、または数百ミリ秒ごとなどの予算に基づいたタイマーで決定する可能性があります。システムがキャンセルと注文を明示的にサポートしている場合を除き、同じエージェントに対する重複したリクエストを避けてください。衝突前に停止する、サーバー側のスタンを尊重するなど、待機できない即時対応には、ローカルで作成されたポリシーを使用します。 JEV は、すべての安全チェックではなく、意味のある戦術的な Choice を処理する必要があります。ステップ 6: レイテンシ、タイムアウト、 を処理するすべてのリクエストには期限が必要です。期限が切れた場合は、NPC を安全な現在のアクションに保持するか、決定的な フォールバック を使用してください。 フォールバック は、ポジションを保持する、カバーに移動する、最後の有効なインテントに従う、または作成されたビヘイビア ツリーを実行するなどの単純なものにすることができます。役割と状況に応じて選択してください。タイムアウト:_ リクエストをキャンセルまたは無視して、 フォールバック.無効なアクション:_ 契約の失敗をログに記録し、状態を再構築し、金庫を使用してくださいポリシー。古い状態: 結果を破棄するか、残っているアクションのみを再検証します。安全です。サービス障害:_ ゲームをブロックせずにローカル動作に低下しますループ。繰り返し失敗:_ 毎回再試行するのではなく、バックオフとサーフェス テレメトリを適用しますフレーム。ステップ 7: 意思決定層のテスト状態予測、Legal Actions、応答、検証結果、実行結果、待ち時間、および フォールバック 理由を記録します。体力低下、弾薬なし、複数の脅威、目標の喪失、アクションの中断、ナビゲーションの利用不可などのリプレイ ケースを構築します。設計者が予期しない Choice. を引き起こした正確な状況を再現できると、意思決定システムのバランスをとることがはるかに容易になります。Unity および Unreal 統合の場合は、エンジン アダプターを薄くしておきます。アダプターはエンジンの状態を JEV コントラクトに変換し、検証されたアクションを既存のコマンドまたは能力システムに変換し直す必要があります。これにより、完全なレベルをロードせずにコアの意思決定テストを実行できるようになります。製造チェックリストGame Stateには、関連する許可された情報のみが含まれています。すべての法的措置には前提条件があり、実行できる所有者がいます。 _応答は現在の権限のある状態に対して検証されます。リクエストには期限、キャンセルまたは失効ルールがあり、バックオフ。フォールバック の動作は、NPC ロールごとに設計されています。ログにより、不適切な決定を再現可能にします。遅延、有効性、アクションの品質、およびフォールバックレートが監視されます。 _基本的な概念については、JEV とは何ですか? を参照してください。ゲーム ループおよび NPC デザイン コンテキストについては、JEV ゲーム AI_. を参照してください。, attack, and retreat. If ammunition is zero, attack should not be sent. If no safe cover exists, takeCover should not be sent.
[ { name: 'takeCover', coverId: 'wall-a' }, { name: 'attack', targetId: 'raider-02' }, { name: 'holdPosition', locationId: 'relay' } ]Keep the action vocabulary small at first. The goal is not to encode every button press. The goal is to expose meaningful tactical choices and leave low-level execution to the engine.
Step 3: Call JEV
A request should carry the state projection, the legal actions, the NPC goal, and a decision deadline or request identifier. The response should identify the chosen action and may include parameters, a confidence or rationale field if supported, and the state version it observed.
const decision = await jev.decide({ agent: npc, gameState: projectState(state), legalActions: buildLegalActions(state), objective: 'Protect the relay', stateVersion: state.version });Do not let a late response apply blindly. The world may have changed while the request was in flight. Compare the response's state version with the current version, then revalidate the selected action.
Step 4: Execute and validate
The executor is the final authority. It checks that the action exists in the current legal-action set, that its target still exists, that the NPC is allowed to act, and that the state version is not too old for the action. It then invokes normal movement, ability, or behavior-tree code.
const action = legalActions.find(candidate => candidate.name === decision.name);
if (!action || !matchesParameters(action, decision)) return fallback(state);
return executor.run(action);Validation should happen even if the service is trusted. It protects against stale state, race conditions, schema drift, and accidental model output that does not match the game contract.
Step 5: Set the decision frequency
Choose a cadence based on the decision, not the render loop. A turn-based NPC can decide at the start of its turn. A real-time combatant might decide when its current intent completes, when a threat enters perception, or on a budgeted timer such as every few hundred milliseconds. Avoid overlapping requests for the same agent unless the system explicitly supports cancellation and ordering.
Use a local authored policy for immediate reactions that cannot wait, such as stopping before a collision or respecting a server-side stun. JEV should handle meaningful tactical choices, not every safety check.
Step 6: Handle latency, timeout, and フォールバック
Every request needs a deadline. If the deadline expires, keep the NPC in a safe current action or use a deterministic フォールバック. A フォールバック can be as simple as hold position, move to cover, follow the last valid intent, or run an authored behavior tree. Choose it per role and situation.
- Timeout: cancel or ignore the request and use the フォールバック.
- Invalid action: log the contract failure, rebuild state, and use a safe policy.
- Stale state: discard the result or revalidate only actions that remain safe.
- Service failure: degrade to local behavior without blocking the game loop.
- Repeated failure: apply backoff and surface telemetry rather than retrying every frame.
Step 7: Test the decision layer
Record the state projection, legal actions, response, validation result, execution outcome, latency, and フォールバック reason. Build replay cases for low health, no ammunition, multiple threats, lost targets, interrupted actions, and unavailable navigation. A decision system becomes much easier to balance when a designer can replay the exact situation that produced an unexpected choice.
For Unity and Unreal integrations, keep the engine adapter thin. The adapter should translate engine state into the JEV contract and translate a validated action back into an existing command or ability system. This makes the core decision tests runnable without loading a full level.
Production checklist
- Game State contains only relevant and permitted information.
- Every Legal Action has preconditions and an owner that can execute it.
- Responses are validated against current authoritative state.
- Requests have deadlines, cancellation or staleness rules, and backoff.
- Fallback behavior is designed for each NPC role.
- Replay logs make poor decisions reproducible.
- Latency, validity, action quality, and フォールバック rate are monitored separately.
For the underlying concept, read What Is JEV?. For the game-loop and NPC design context, see JEV Game AI.
