JEV Unity Tutoriel : Créer une tactique en temps réel NPC

Ce didacticiel Unity utilise JEV comme couche de décision tactique limitée tandis que Unity reste responsable de l'état de la scène, de la physique, de la navigation, de l'animation et de l'autorité du gameplay. Il s'agit d'un modèle d'adaptateur et non d'une affirmation selon laquelle un appel SDK peut remplacer un contrôleur NPC.

L'architecture Unity

Séparez cinq composants : un projecteur d'état lit la scène, un générateur d'action crée Legal Actions, un client JEV envoie la requête, un exécuteur mappe une action validée aux systèmes Unity et un La stratégie fallback maintient le NPC en mouvement lorsque la réponse est en retard ou invalide.

NpcController -> StateProjector -> LegalActionBuilder -> JevClient -> Validator -> Executor or Fallback

1. Projetez la scène dans Game State

Projetez uniquement les faits pertinents pour la décision : rôle, santé, ennemis visibles, statut de l'objectif, couverture à proximité, munitions, temps de recharge, intention actuelle et version de l'état. Utilisez la couche de perception de NPC afin que les informations cachées ne s'infiltrent pas dans la décision.

state = { agentId, role, healthRatio, visibleThreatIds, objectiveUnderThreat, ammo, stateVersion }

2. Construire Legal Actions

Le générateur d'action crée des commandes telles que se mettre à couvert, attaquer une cible visible, aider un allié ou maintenir une position. Chaque action porte l'identifiant de cible ou d'emplacement nécessaire à l'exécuteur. La navigation reste une préoccupation Unity : JEV choisit les candidats d'intention ou de destination tandis que NavMesh calcule le chemin.

3. Appel en dehors de la boucle de rendu

Déclenchez une décision lorsque l'intention actuelle se termine, qu'une menace entre en perception, que l'objectif change ou qu'un chronomètre tactique expire. Utilisez une coroutine, une tâche asynchrone ou un service de jeu avec une requête en cours par NPC. Ne bloquez jamais le thread principal de Unity en attendant la réponse du réseau.

if (!requestInFlight) { requestInFlight = true; result = await client.Decide(snapshot, actions); ApplyIfStillValid(result); }

4. Valider et exécuter

Comparez la version de l'état de la réponse avec le monde actuel, reconstruisez l'ensemble des actions en justice et vérifiez les paramètres. Une cible peut être morte ou un point de couverture peut être inaccessible pendant que la demande était en vol. Si la validation réussit, mappez l'intention à une commande, un arbre de comportement, une destination NavMesh ou un système de capacités existant.

5. Définir la cadence, le délai d'attente et fallback

Séparez la boucle de rendu de la boucle tactique. Fixez un délai qui laisse au NPC le temps d'agir. Lors du temps mort, conservez l'intention de sécurité actuelle ou utilisez une politique locale telle que se mettre à couvert en cas de blessure, conserver l'objectif ou battre en retraite lorsqu'il ne reste aucune attaque légale.

6. Rendre les décisions visibles

Dans les versions de développement, exposez l'état projeté, Legal Actions, l'action sélectionnée, la version de l'état, la latence de la demande, le résultat de la validation et la raison fallback dans une fenêtre de débogage ou un gadget. Les concepteurs doivent comprendre une décision sans lire une trace réseau.

Unity liste de contrôle

• Perception est propriétaire de la projection d'état.
• Ne bloquez pas le principal thread.
• Revalider avant l'exécution.
• Gardez le mouvement, la physique, l'animation et l'autorité dans Unity.
• Déterministe du navire fallback et télémétrie dès le premier prototype.

Une configuration de scène minimale Unity

Commencez avec un NPC, un objectif, deux menaces, quelques points de couverture et un contrôleur local fallback. Ajoutez un composant de perception, un projecteur d'état, un générateur d'action, un client de décision et un exécuteur en tant que MonoBehaviour ou services distincts. Gardez l'adaptateur JEV indépendant des détails de NavMeshAgent et Animator afin qu'il puisse être testé sans scène complète.

La limite de l'adaptateur

L'adaptateur traduit les types Unity en une requête indépendante du fournisseur et traduit une intention validée en une commande existante. Il ne doit pas appeler SetDestination, jouer une animation ou appliquer des dégâts avant validation. Ces effets appartiennent à l'exécuteur et aux systèmes de jeu.

Testez les scénarios avant de régler les invites

• Faible santé avec couverture disponible.
• Pas de munitions mais une retraite accessible route.
• Une cible détruite alors que la demande est en vol.
• Deux points de couverture également valables avec des distances.
• JEV délai d'attente pendant un état de combat actif.
• Déchargement de scène ou NPC disparaît avant la réponse.

Pour chaque scénario, affirmez que l'action sélectionnée est légale, que l'exécuteur est appelé au plus une fois, que la réponse obsolète est ignorée et que le fallback laisse le NPC dans un état valide.

Que mesurer dans le Unity Profiler

Suivez le temps de projection de l'état, le temps de sérialisation, l'attente du réseau, le temps de validation, le démarrage de l'exécuteur, l'achèvement de l'action et le nombre fallback. Un modèle peut être rapide tandis que l'adaptateur est lent car il sérialise trop d'état ou planifie le travail sur le thread principal. Mesurez l'impact de la trame séparément de la latence de décision de bout en bout.

Un plan d'expédition par étapes

1. Prototype avec un client de fausse décision local.
2. État d'enregistrement et de relecture instantanés.
3. Ajouter le client distant derrière un indicateur de fonctionnalité.
4. Expédier fallback-first comportement et télémétrie.
5. Exécutez une cohorte NPC limitée avant de prendre la couche de décision universel.

Pour le contrat indépendant du fournisseur, lisez JEV API utilisation. Pour la conception de l'espace d'action, voir JEV Legal Actions. Le tutoriel général se trouve à JEV tutoriel.