JEV Tutoriel : Créez votre première prise de décision en temps réel NPC

Ce didacticiel présente une petite intégration JEV : un NPC reçoit un Game State compact, choisit une action autorisée et exécute cette action via un code de jeu ordinaire. L’exemple est volontairement modeste. Un NPC fiable à trois actions enseigne plus qu'un grand agent dont l'état, l'autorité et le fallback comportement ne sont pas clairs.

Les noms API et les détails SDK peuvent varier selon l'intégration. Le contrat architectural reste le même : le jeu possède la vérité, JEV sélectionne parmi les options légales et l'exécuteur valide le Choice avant de changer le monde.

La plus petite intégration utile

Utilisez cinq éléments : un Game State faisant autorité, une projection d'état, un générateur d'action en justice, un client JEV et un exécuteur d'action. La projection d'état supprime les détails non pertinents. Le générateur d'actions attache les conditions préalables actuelles. Le client envoie une demande de décision. L'exécuteur vérifie que la réponse est toujours valide et la traduit en commandes de mouvement, de capacité ou d'animation.

game state -> state projection -> JEV decision -> validation -> executor -> game state

Dans Unity, ces éléments peuvent résider dans un MonoBehaviour, un service de jeu et un composant de commande. Dans Unreal, ils peuvent correspondre à un processeur d'acteur ou de masse, à un sous-système et à une capacité de jeu ou à des tâches d'arbre de comportement. Les noms diffèrent, mais la limite de propriété doit rester explicite.

Étape 1 : Concevoir un Game State

Commencez par des faits qui peuvent changer la prochaine décision. Pour un combat NPC, cela peut être le rôle, le ratio de santé, les ennemis visibles, la couverture la plus proche, la santé des alliés, le statut de l'objectif, les munitions, les temps de recharge, l'action en cours et une version d'état monotone. Évitez d'envoyer des objets moteur bruts ou le monde entier. Un schéma compact est plus facile à inspecter, à transmettre et à rejouer.

{ agentId: 'guard-07', role: 'defender', healthRatio: 0.42, objectiveUnderThreat: true, visibleThreats: 1, ammo: 3, healReady: true, stateVersion: 1842 }

Inclure uniquement les informations que NPC est autorisé à connaître. Ceci est particulièrement important pour les jeux furtifs et compétitifs : un modèle de décision ne doit pas recevoir des positions ennemies cachées simplement parce que le serveur les possède.

Étape 2 : Définir Legal Actions

Une action doit avoir un nom stable, des paramètres explicites, des conditions préalables et un chemin d'exécution. Pour l'exemple NPC, l'ensemble pourrait être holdPosition, takeCover, attack et retraite. Si les munitions sont nulles, attack ne doit pas être envoyé. S'il n'existe aucune couverture sécurisée, takeCover ne doit pas être envoyé.

[ { name: 'takeCover', coverId: 'wall-a' }, { name: 'attack', targetId: 'raider-02' }, { name: 'holdPosition', locationId: 'relay' } ]

Gardez le vocabulaire d'action petit au début. Le but n’est pas d’encoder chaque pression sur un bouton. L'objectif est d'exposer des Choice tactiques significatives et de laisser l'exécution de bas niveau au moteur.

Étape 3 : Appelez JEV

Une demande doit contenir la projection d'état, le Legal Actions, l'objectif NPC et une date limite de décision ou un identifiant de demande. La réponse doit identifier l'action choisie et peut inclure des paramètres, un champ de confiance ou de justification si pris en charge, et la version de l'état observée.

const decision = await jev.decide({ agent: npc, gameState: projectState(state), legalActions: buildLegalActions(state), objective: 'Protect the relay', stateVersion: state.version });

Ne laissez pas une réponse tardive s'appliquer aveuglément. Le monde a peut-être changé pendant que la demande était en cours. Comparez la version d'état de la réponse avec la version actuelle, puis revalidez l'action sélectionnée.

Étape 4 : Exécuter et valider

L'exécuteur testamentaire est l'autorité finale. Il vérifie que l'action existe dans l'ensemble d'actions en justice actuel, que sa cible existe toujours, que le NPC est autorisé à agir et que la version d'état n'est pas trop ancienne pour l'action. Il invoque ensuite un code de mouvement, de capacité ou d'arbre de comportement normal.

const action = legalActions.find(candidate => candidate.name === decision.name);
if (!action || !matchesParameters(action, decision)) return fallback(state);
return executor.run(action);

La validation doit avoir lieu même si le service est fiable. Il protège contre les états obsolètes, les conditions de concurrence, les dérives de schéma et les sorties accidentelles de modèles qui ne correspondent pas au contrat du jeu.

Étape 5 : Définir la fréquence de décision

Choisissez une cadence basée sur la décision, pas sur la boucle de rendu. Un NPC au tour par tour peut décider au début de son tour. Un combattant en temps réel peut décider du moment où son intention actuelle se termine, du moment où une menace entre en perception ou selon une minuterie budgétisée, par exemple toutes les quelques centaines de millisecondes. Évitez les demandes qui se chevauchent pour le même agent, sauf si le système prend explicitement en charge l'annulation et la commande.

Utilisez une politique rédigée localement pour des réactions immédiates qui ne peuvent pas attendre, comme s'arrêter avant une collision ou respecter un étourdissement côté serveur. JEV devrait gérer des Choice tactiques significatives, pas tous les contrôles de sécurité.

Étape 6 : Gérer la latence, le délai d'attente et fallback

Chaque demande nécessite une date limite. Si le délai expire, conservez le NPC dans une action actuelle sûre ou utilisez un fallback déterministe. Un fallback peut être aussi simple que maintenir la position, se déplacer pour se couvrir, suivre la dernière intention valide ou exécuter un arbre de comportement créé. Choisissez-le par rôle et par situation.

• Timeout : annuler ou ignorer la demande et utiliser le fallback.
• Action invalide : enregistrer l'échec du contrat, reconstruire l'état et utiliser un politique de sécurité.
• État obsolète : rejeter le résultat ou revalider uniquement les actions restantes Safe.
• Échec du service : se dégrade en comportement local sans bloquer le jeu boucle.
• Échec répété : appliquer le recul et la télémétrie de surface plutôt que de réessayer chaque cadre.

Étape 7 : tester la couche de décision

Enregistrez la projection d'état, Legal Actions, la réponse, le résultat de la validation, le résultat de l'exécution, la latence et la raison fallback. Créez des cas de relecture pour une santé faible, pas de munitions, des menaces multiples, des cibles perdues, des actions interrompues et une navigation indisponible. Un système de décision devient beaucoup plus facile à équilibrer lorsqu'un concepteur peut rejouer la situation exacte qui a produit un Choice.

inattendu.

Pour les intégrations Unity et Unreal, gardez l'adaptateur moteur mince. L'adaptateur doit traduire l'état du moteur dans le contrat JEV et traduire une action validée en un système de commande ou de capacité existant. Cela rend les tests de décision de base exécutables sans charger un niveau complet.

• Liste de contrôle de production
• Game State contient uniquement des informations pertinentes et autorisées.
• Chaque action en justice comporte des conditions préalables et un propriétaire qui peut l'exécuter.
• Les réponses sont validées par rapport à l'état faisant autorité actuel.
• Les demandes ont des délais, annulation ou les règles d'obsolescence, et l'interruption.
• fallback le comportement est conçu pour chaque NPC role.
• Les journaux de relecture rendent les mauvaises décisions reproductibles.

Latence, validité, qualité de l'action et Les taux fallback sont surveillés séparément.Pour le concept sous-jacent, lisez Qu'est-ce que JEV ?. Pour la boucle de jeu et le contexte de conception NPC, voir JEV Game AI