JEV game demos turn an abstract question into an observable one: can a decision model receive a changing game state, choose among legal actions, and return a useful answer before the game needs to continue? JEV is not a replacement for the engine. It is a bounded decision step inside a larger game loop.
For concrete references, compare the JEV Doom experiment, the Jev Pong implementation, the NPC architecture guide, and the Jev Lab board-game and local-NPC example. These are examples to study, not a guarantee that every game shares the same latency or integration contract.
What JEV game demos prove
A useful demo makes the boundary visible. Game code owns world state and rules, produces the actions currently possible, asks JEV to evaluate a typed decision, and validates the answer before execution. Public examples include arcade-style games, board-game positions, and real-time control experiments such as Doom or Pong. Their details differ, but the pattern is state in, bounded decision out.
Where JEV sits in the game loop
- Observe authoritative facts.
- Filter impossible actions.
- Ask JEV a typed question.
- Validate the response against the current state.
- Execute through a command, behavior tree, ability system, or controller.
- Reconsider after an event, completed intent, or bounded timer.
Rendering and physics may run every frame, while a tactical decision runs more slowly. Calling a decision service every rendered frame adds latency and jitter. JEV should handle meaningful choices; steering, collision, animation, replication, and multiplayer authority stay in deterministic systems.
What game code owns
- World state, physics, navigation, collision, hit detection, and authority.
- Perception and the information an NPC is allowed to know.
- Legal actions, parameters, preconditions, and execution handlers.
- Timeouts, stale-response checks, rate limits, and fallback behavior.
What JEV contributes
JEV can choose one candidate, score candidates, or answer a bounded yes-or-no question. It contributes context-sensitive judgment over choices the game has presented; it should not invent a complete action sequence. Start with three to six meaningful options and keep execution inside existing game code.
Latency, frequency, and fallback
There is no universal cadence. A turn-based game may decide once per turn; a tactics game may decide after a threat appears or every few hundred milliseconds; an exploration companion may decide when its goal changes. Measure the complete path from state capture to validated execution. Every request needs a deadline. If it is late, keep the current intent, move to cover, run an authored behavior tree, or hold position.
How to evaluate a demo
Check whether the state projection and legal actions are visible, whether an invalid response is rejected safely, whether decision cadence is separate from rendering, and whether a deterministic fallback is shown. A strong demo logs the selected action, latency, validity, and fallback reason.
Four demo patterns worth comparing
Arcade demos test rapid action selection over a small state. A Doom-like experiment tests whether the agent can keep acting while the visual state changes quickly. Pong and similar games make the action space obvious and expose missed deadlines immediately. NPC or board-game demos test a slower but richer question: can the model weigh goals, threats, and legal moves without taking ownership of the rules?
These demos should not be compared by a single headline latency. They differ in observation cost, action count, network path, rendering loop, and fallback policy. A fair comparison records the same fields for each run: state size, candidate count, decision deadline, median and tail latency, valid-result rate, fallback rate, and task outcome.
A practical demo scorecard
| Dimension | What to record | Why it matters |
|---|---|---|
| Decision cadence | Event-driven, turn-based, or timed | Shows whether the model is used at the right layer |
| Action space | Candidate count and parameter types | Reveals whether the result is bounded and testable |
| Freshness | State version and stale-result rate | Measures race conditions in live play |
| Fallback | Behavior after timeout or invalid output | Separates a demo from a resilient game system |
| Outcome | Win rate, survival, objective progress, or designer rating | Measures useful behavior rather than model activity |
Turning a demo into a production slice
- Record a deterministic baseline policy.
- Choose one decision with a clear owner and three to six legal actions.
- Replay recorded states offline before adding network calls to a live level.
- Introduce deadlines and fallbacks before expanding the action space.
- Compare quality, latency, cost, and fallback rate separately.
The strongest JEV game page is therefore not just a gallery. It explains what the demo proves, what it does not prove, and which engineering evidence a team should collect before shipping.
For NPC architecture, read JEV NPC. For the API contract, see JEV API usage. For Unity integration, continue to the JEV Unity tutorial.
