JEV game AI is best understood as a tactical layer for NPC decision-making. It does not try to drive an NPC's transform every frame. Instead, it looks at a meaningful snapshot of the game, chooses a legal intent, and lets the engine execute that intent through navigation, animation, abilities, and rules.
That distinction matters because a game loop contains different kinds of work. Rendering and physics may run every frame. Navigation and animation may update continuously. Tactical decisions can often wait for an event, a timer, or a meaningful change in state. JEV belongs in that slower, higher-value part of the loop.
Where JEV fits in the game loop
Imagine a squad-based encounter. One NPC is low on health, an enemy has moved into view, a nearby wall provides cover, and the squad's healer has an available ability. The game can serialize those facts into a compact state, expose legal actions, and ask JEV to select the next intent. A response such as take cover and request healing is then validated and executed by normal game systems.
- Observe: collect relevant facts from the authoritative world state.
- Filter: remove actions whose preconditions are false.
- Decide: compare the remaining actions against goals, risk, and resources.
- Execute: send the selected intent to movement, ability, and animation systems.
- Re-evaluate: call again when the action completes, becomes invalid, or the situation changes.
What state should an NPC expose?
Good state is decision-relevant rather than exhaustive. It can include health and stamina, known enemies, line of sight, cover candidates, ally needs, current objective, distance to targets, cooldowns, ammunition, inventory, and the status of an active action. It can also include a small amount of memory, such as the last observed threat or the last location where an ally was seen.
Sending every object in the world makes a decision harder to interpret and increases cost and latency. A compact state contract also improves testing: the same snapshot can be replayed to compare choices after a prompt, policy, or game-balance change.
Why legal actions matter
JEV should choose from actions the game has already approved. An action can include a name, parameters, preconditions, expected duration, and a cost. Examples include attack(targetId), moveTo(locationId), heal(targetId), retreat(routeId), and observe(areaId).
The legal-action list is both a safety boundary and a design tool. It prevents a wounded NPC from selecting an unavailable ability, gives designers control over what a character can do, and makes the output easy to validate. If an action is not in the list, it is not an option.
How JEV chooses attack, retreat, heal, or explore
JEV decisions become useful when actions represent real trade-offs. Attacking may remove a threat quickly but expose the NPC. Retreating may preserve the squad but abandon an objective. Healing may improve survival but consume a cooldown. Exploring may reveal a route or resource while increasing exposure. The model should receive the goal and constraints that make these trade-offs meaningful; the game should still define hard rules such as range, ownership, cooldown, and collision.
Designers can also shape behavior with priorities and risk budgets. A boss encounter may favor pressure, while a companion NPC may favor survival and assistance. Those preferences should be visible in the state or policy contract rather than hidden in arbitrary prose.
Why JEV should not control every frame
Frame-by-frame control creates unnecessary latency, cost, and jitter. It also mixes tactical intent with low-level steering, where deterministic systems are usually better. A more stable pattern is to ask for a decision when a goal changes, an action finishes, a threat appears, a target is lost, or a decision timer expires.
The exact cadence depends on the game. A turn-based game may decide once per turn. A real-time tactics game may decide every few hundred milliseconds during active combat, with event-triggered calls for urgent changes. A companion in an exploration game may decide less often. The right frequency is the one that gives the NPC time to act while keeping its behavior responsive.
JEV and traditional NPC AI
A production NPC can combine several systems. Perception gathers facts. JEV selects an intent. A behavior tree or state machine executes the intent. Navigation finds a route. Animation and abilities handle presentation and effects. The game server validates authority. This separation makes each system easier to profile and replace.
When JEV is unavailable or returns an invalid choice, the NPC can fall back to an authored policy. For example, a guard can retreat to the nearest safe point, or a companion can stay behind cover. A fallback is not a sign that the system failed; it is part of a robust game design.
A practical adoption checklist
- Start with one NPC role and three to six meaningful actions.
- Keep the state schema small enough to inspect in a log.
- Validate every response against the current authoritative state.
- Use a decision budget and a clear timeout.
- Record state, legal actions, response, and outcome for replay testing.
- Measure tactical quality separately from latency and infrastructure cost.
For the general definition and comparisons, read What Is JEV?. For a complete implementation path, continue to the JEV tutorial.
