
A JEV NPC is not a character whose entire brain has been outsourced to a model. It is a game character whose tactical decision layer evaluates changing state and selects among actions the game has already made legal. Perception, movement, animation, abilities, and world rules remain in the game.
From perception to action
A robust NPC pipeline has distinct stages: perception determines what the character knows; state projection summarizes relevant facts; an action builder creates legal choices; JEV evaluates the decision; an executor runs the selected intent; and a fallback policy handles timeouts or invalid responses.
What should NPC state contain?
Include role, health, stamina, visible threats, target distance, cover candidates, ally needs, objective status, cooldowns, ammunition, inventory constraints, current action, and relevant memory. Exclude hidden information and raw engine objects. The state should describe what could change the next meaningful choice, not every object in the level.
Attack, retreat, heal, or explore?
These choices expose real trade-offs. Attack may remove a threat but expose the NPC. Retreat may preserve the character but abandon an objective. Heal may help an ally while consuming a cooldown. Explore may reveal a route while increasing risk. The game defines hard preconditions; JEV helps compare legal options in context.
JEV and behavior trees
Behavior trees are strong at transparent sequences such as moving, waiting, retrying navigation, and playing an ability. JEV can select the intent that activates a branch while the tree executes the details. This keeps the model's contribution narrow enough to test and the execution path familiar.
JEV and finite-state machines
An FSM can keep explicit modes such as patrol, alert, combat, and flee. JEV can help choose a transition or high-level action inside a mode, but it should not silently create an unbounded state graph. Keep transitions observable and let deterministic code handle safety-critical changes.
How often should an NPC ask?
Use events and a bounded tactical timer. Reconsider when a threat appears, an action finishes, the objective changes, a target is lost, or a cooldown becomes available. Avoid per-frame calls. Low-level motion continues on the last validated intent while a late request falls back safely.
Fallbacks are part of NPC design
Choose fallbacks by role and risk. A wounded companion can move to cover; a guard can hold the objective; a civilian can flee along an authored route; a boss can continue its current phase. Record the reason for every fallback so designers can distinguish a poor decision from a timeout or stale target.
How to evaluate a JEV NPC
- Does it receive only information it could perceive?
- Are the choices meaningful in the current situation?
- Can every returned action be validated and executed?
- Does it continue safely when the model is unavailable?
- Can the team replay the same state and inspect the outcome?
Role-specific decision contracts
Different NPC roles need different state and action vocabularies. A guard may choose patrol, investigate, call backup, pursue, or hold. A healer may choose heal, take cover, retreat, or assist. A civilian may choose hide, flee, seek help, or continue a routine. Reusing one universal prompt often makes the behavior vague; role-specific contracts make both testing and balancing clearer.
Short-term memory without hidden omniscience
An NPC can remember the last seen threat, an interrupted action, a recent ally request, or a known unsafe route. Store memory as explicit state with expiration and confidence. Do not turn memory into an unrestricted transcript that reveals facts the character could not know. The memory projection should explain why it can influence the next decision.
Measure behavior quality separately from validity
A valid action is not necessarily a good action. Track contract validity, tactical outcome, objective progress, survival, team support, player perception, latency, and fallback rate as separate metrics. A guard that always chooses a legal action but abandons the objective has a balance problem, not an API problem.
When JEV is not the right tool
Use authored logic for a fixed animation, a safety interlock, an exact tutorial beat, a server authority check, or a decision with only one possible answer. Use navigation for pathfinding and a behavior tree for multi-step execution. JEV adds value when several meaningful actions are legal and the best one changes with context.
NPC review checklist
- Can a designer explain the current state and candidate actions?
- Does the NPC act only on permitted perception?
- Are action transitions observable?
- Is the fallback believable for this role?
- Can a player understand the character's intent?
- Can QA replay the exact encounter?
For broader architecture, read JEV Game AI. For API details, see JEV API usage. For Unity, continue to JEV Unity tutorial.


