Jev Games: Decision Models for Game Agents | AutoJev

Jev games use a decision model to choose from legal actions generated by game code. The game engine owns physics, rules and state transitions; Jev evaluates structured state and selects a move, target or tactical mode from a bounded candidate set.

Games are useful Jev experiments because outcomes can be replayed and scored. They also expose an important limit: a model can produce a valid move with high confidence and still play badly.

The Jev game loop

A robust game agent separates five responsibilities:

1. Observe: extract compact state such as position, velocity, hazards, legal moves and objective progress.
2. Enumerate: let code generate only actions that are legal in the current state.
3. Decide: ask Jev one or more Choice, Noul or Score questions over those candidates.
4. Execute: pass the selected action to the emulator or game engine.
5. Evaluate: record the state, distribution, action and outcome for replay and comparison.

This is not the same as asking a language model to write a walkthrough. The decision output must map directly to an action the controller understands.

Public Jev game examples

• typesafe-snake runs one System One Choice per tick while code generates legal moves and game facts.
• typesafe-mario uses structured emulator state for a Super Mario Bros. agent.
• NanoJev includes independent maze and Snake experiments with local typed decision heads and browser replays.
• TypeSafe's launch material also discusses game demonstrations; use the official TypeSafe site for current first-party examples.

These projects have different providers, controllers and evaluation methods. A successful replay is evidence for that recorded run, not proof that the architecture generalizes to every level or game.

Example bounded game decision

{
  "state": {
    "game": "grid navigation",
    "position": [4, 7],
    "goal": [9, 2],
    "blocked": ["north"],
    "visited_recently": [
      [4, 6],
      [4, 7]
    ],
    "steps_remaining": 18
  },
  "questions": {
    "move": {
      "type": "choice",
      "instructions": "Choose the legal move most likely to reach the goal without looping.",
      "criteria": {
        "south": "Move to [4, 8].",
        "east": "Move to [5, 7].",
        "west": "Move to [3, 7]."
      }
    },
    "stuck": {
      "type": "noul",
      "instructions": "Is the controller repeating a loop that requires replanning?"
    },
    "progress": {
      "type": "score",
      "instructions": "Score progress toward the goal.",
      "criteria": ["Regressing", "No progress", "Some progress", "Near goal"]
    }
  }
}

The controller should omit north because the engine reports it as blocked. If stuck crosses a calibrated threshold, deterministic code can reset history, invoke a planner or end the run rather than repeatedly sending the same move question.

Good Jev game candidates

Jev fits a game or simulation when:

• The engine can provide compact, relevant state.
• Legal actions can be generated before the decision.
• Many similar decisions repeat during an episode.
• The outcome can be measured and replayed.
• A controller can handle invalidated state, timeouts and uncertainty.

Turn-based strategy, grid navigation, tactical mode selection and simulation control are easier fits than tasks that require generating long, precise action sequences from raw pixels.

What belongs in code, not the model

• Collision detection, physics and legal-move generation.
• Hard safety limits and forbidden actions.
• Resource accounting and win/loss rules.
• Input timing that must meet real-time deadlines.
• Replay capture and outcome measurement.

The decision model should choose among valid meanings; it should not become an unverified replacement for the game engine.

How to evaluate a Jev game agent

Measure more than a highlight video:

• Completion or win rate across fixed seeds and unseen levels.
• Illegal-action rate before and after deterministic filtering.
• Calibration: whether 80% decisions succeed about 80% of the time.
• Loop and stall frequency.
• Decision latency, total episode time and provider cost.
• Performance when state fields are removed, reordered or made noisy.
• Comparisons against random, heuristic and generative-model baselines.

Publish the candidate actions and complete probability distribution with each replay when possible. That makes it easier to distinguish a poor decision from a controller or state-extraction bug.

Build a game decision through AutoJev

Use the generic Jev API when the game's action set changes by state. Put observations in state, legal moves in Choice criteria, and monitoring questions beside the move in the same request. AutoJev returns the decision data but does not run the game or grant the model authority over the machine.

For related control-loop patterns, read Jev computer use. For independent model experiments and project directories, use the Jev ecosystem guide.