The idea
Deliver a short, enjoyable arcade race on one recognisable Palmerston North route using the existing HTML5 canvas game. V1 is a single closed course, predictable vehicle handling and a complete attract-to-results loop on the actual cabinet. A geographically extensive map should follow a fun and performant vertical slice.
The connection
Local geography becomes playful level design. Recognition brings a place into the game; handling, routes and timing make people want to play again.
How it could work
Convert map geometry into a deliberate game track rather than using raw road data directly as collision geometry. Maintain separate centreline, drivable surface, barriers, checkpoints and decorative layers. Review intersections for unintentional shortcuts and simplify geometry where it improves play. Preserve the source and attribution of any map data used.
Use a fixed-step simulation with rendering decoupled from physics, so variable frame rate does not change acceleration or collision outcomes. Define steering dead zones and response curves for the actual controls. A wheel, joystick and keyboard have different needs; do not tune for one and assume the others are equivalent.
What would prove it
Invite five people unfamiliar with the build to play three short races each. Observe whether they understand steering, route direction and restarting without coaching. Record collisions, missed turns, lap progression and frame times on the target cabinet. Test deliberate checkpoint skipping, reversing over the line and a disconnected controller.
Proposed gate: at least four of five players finish a race unaided; no invalid checkpoint sequence records a valid lap; the game recovers from control loss; at a 60 fps target, at least 95% of frames fit within 16.7 ms on the test host. These are proposed pilot targets; enjoyment also needs qualitative feedback.
The path to a complete build
- Inspect and preserve the current game; select one route and existing working mechanics.
- Validate geometry, checkpoint order and fixed-step handling.
- Tune the actual cabinet controls and complete the attract/results loop.
- Run the five-player study and fix the most common confusion before adding content.
- Archive build, route, measurements and observed feedback so later changes can be compared.
Open the engineering notebook
Components, interfaces and calculations
The pilot needs the current game source, one versioned route, actual cabinet controls, target host/display and a timing/debug overlay. A race record should include track version, game build, control mode, lap splits, checkpoint order and completion state. Only valid checkpoint sequences should create a leaderboard entry.
Create a restartable race state machine: attract, ready, racing, finished and recovery. An abandoned race returns to attract after a documented timeout. Keep the venue's operator controls separate from player actions and store a local score backup if online services are used.
Scope and development questions
Plan 5–8 sessions for a vertical-slice improvement after source review. Reuse cabinet hardware where possible; budget venue testing time and any art/licensing work separately. Resolve the current control setup, map source, target machine and intended race duration. The plan must be reconciled with the existing implementation before estimating new development effort.