Une intégration JEV API utile est un petit service de décision autour d'un grand système de jeu. Le jeu possède le monde faisant autorité, le traduit en un état compact et crée les actions désormais légales. JEV évalue cette question limitée ; l'exécuteur testamentaire valide la réponse et exécute l'action.
Le pipeline d'intégration
Game State -> Legal Actions -> Typed Question -> JEV -> Validate -> Execute or Fallback1. Conception compacte Game State
Envoyez des faits qui pourraient changer la prochaine décision : rôle, santé, menaces visibles, objectif, ressources, temps de recharge, couverture, intention actuelle et version d'état monotone. N'envoyez pas l'intégralité du graphique d'objet du moteur et ne divulguez pas d'informations cachées que NPC ne pourrait pas percevoir.
{ agentId: 'guard-07', healthRatio: 0.42, visibleThreats: 1, ammo: 3, stateVersion: 1842 }2. Définir Legal Actions
Chaque candidat a besoin d'un nom stable, de paramètres explicites, de conditions préalables et d'un propriétaire d'exécution. Par exemple : takeCover(coverId), attack(targetId) ou holdPosition(locationId). Construisez la liste à partir d’un État faisant autorité ; ne demandez pas à JEV d'inventer des identifiants, des itinéraires, des capacités ou des paramètres.
3. Choisissez la primitive
Utilisez Choice lorsqu'un candidat doit être sélectionné, Score lorsque les candidats ont besoin d'un classement et un jugement limité par oui ou par non lorsque la question est une porte d'entrée, comme s'il faut abandonner un objectif. Utilisez la plus petite primitive qui correspond à la question.
4. Appelez et validez
const result = await jev.decide({ state, legalActions, question: 'Protect the relay' }); const current = buildLegalActions(world, npc); if (!current.some(action => sameAction(action, result))) return fallback(); return executor.run(result);La méthode exacte SDK peut varier. Les invariants ne comparent pas les versions d'état, ne revalident pas les paramètres et ne rejettent pas les résultats qui ne sont plus légaux. Une réponse peut devenir obsolète pendant qu'une demande est en cours de traitement.
5. Gérer la confiance
Si la réponse inclut une probabilité ou une confiance, utilisez-la comme un signal politique, et non comme une autorisation pour contourner la validation. Une faible confiance peut déclencher une politique locale conservatrice ou préserver l’intention actuelle.
6. Définir la cadence et fallback
Faites appel à des événements significatifs ou à un minuteur tactique limité, pas à chaque image de rendu. Donnez à chaque demande une date limite. En cas d'expiration, conservez une action sûre ou utilisez un fallback spécifique au rôle, comme se mettre à couvert, maintenir la position, suivre ou un arbre de comportement créé. Limite d'une décision en vol par agent, sauf si l'annulation et la commande sont explicites.
7. Tester le contrat
Enregistrer l'état projeté, Legal Actions, la réponse, la latence, la version de l'état, le résultat de la validation, le résultat de l'exécution et la raison fallback. Rejouez une santé faible, pas de munitions, des menaces multiples, des cibles perdues, des actions interrompues et une panne de service. Mesurez séparément la qualité des décisions, la latence, le taux de résultats invalides et le taux fallback.
Concevoir le contrat de demande
Une demande de production doit contenir une version de schéma, une identité d'agent, une version d'état, une projection d'état autorisée, Legal Actions, une primitive de décision, un objectif, une date limite et un ID de corrélation. Gardez l’objectif court et stable. Mettez des contraintes strictes dans le code et les données plutôt que de vous fier à un paragraphe d'instructions.
{ schemaVersion: 'npc-decision-v1', agentId, stateVersion, state, legalActions, primitive: 'choice', deadlineMs, requestId }Concevoir le contrat de réponse
La réponse doit identifier le candidat sélectionné ou Score, la version de l'état observé, la confiance ou la probabilité lorsqu'elle est disponible, et le statut de fournisseur. Traitez l'explication comme une télémétrie facultative, et non comme un champ d'exécution. L'exécuteur doit être capable de valider l'action sans analyser la prose.
Gestion des erreurs qui maintient le jeu en vie
| Condition | Action _ |
|---|---|
| Timeout | Ignorer la réponse et utilisez le fallback |
| Invalid schéma | Enregistrez l'erreur du contrat et échouez fermé |
| Stale version | Rejeter ou revalider par rapport à l'action en cours set |
| Fournisseur échec | Déclenchez une courte pause et continuez localement |
| Répété échec | Désactiver les décisions à distance pour l'agent et la surface télémétrie |
Relecture et observabilité
Conserver suffisamment d'informations pour reproduire une décision : état projeté, Legal Actions, schéma de question, réponse du modèle, horodatages, versions d'état, résultat de validation, commande exécutée, résultat et raison fallback. Rédigez les données et les secrets des joueurs. Un harnais de relecture permet aux concepteurs de comparer une nouvelle invite ou un nouveau fournisseur aux mêmes scénarios sans charger l'intégralité du jeu.
Où le API doit s'arrêter
Le API devrait rendre une décision, pas faire muter le monde. Conservez les écritures d'inventaire, les dégâts, l'autorité de mouvement et les changements d'état multijoueur derrière le serveur ou le moteur de jeu. Cette limite rend les tentatives plus sûres et empêche qu'une requête dupliquée applique un effet de jeu deux fois.
Pour un flux complet de NPC, voir JEV tutoriel. Pour la conception de l’espace d’action, lisez JEV Legal Actions. Pour Unity, passez au JEV Unity tutoriel.
