jev.directory
Systems
noulscorechoiceDomain OpsLoops

TypeSafe Mario — Jev picks NES controller inputs from telemetry, not pixels

An experimental controller that lets Jev choose the next NES input for the original Super Mario Bros.

The interesting constraint is what the model is not given: no screenshots. The harness reads emulator telemetry and RAM and renders it as compact, object-centric JSON — Mario's motion, his jump trajectory, upcoming enemies, terrain, measured response delay, recent control results and episode progress. The raw tile grid stays in the debug logs and the UI rather than being duplicated into the model's state.

NES emulator -> telemetry/RAM parser -> structured JSON -> Jev -> controller input

Three judgments go out together over that one state:

  • Choice next_action — which controller macro to commit to, from a deliberately small legal set: noop, right, right_jump, right_run, right_run_jump, jump, left.
  • Noul jump_needed.
  • Score danger — how dangerous the immediate situation is.

The action set is macros rather than button states because the emulator advances several frames per decision, so a choice has to survive the gap between being made and taking effect. Measured response delay is in the state for the same reason.

Source (7 files)

src/typesafe_mario/__init__.py
src/typesafe_mario/cli.py
src/typesafe_mario/dashboard.py
src/typesafe_mario/policy.py
src/typesafe_mario/runner.py
tests/test_dashboard.py
tests/test_state.py