The idea
Make the existing Windows/Electron arcade front end operate reliably on a real cabinet without a keyboard. V1 covers boot, game selection, launch, return, volume and operator recovery for a small verified game list. Preserve the user's existing emulator and legitimately supplied content; the front end should not bundle unknown ROMs.
The connection
The project joins interface design, local culture and cabinet hardware. The front end has to behave like part of a machine: immediate, legible and recoverable without a keyboard.
How it could work
Treat game launch as a supervised process with explicit states: browsing, launching, running, returning and error. A game crash must return to a useful menu rather than leave a black screen. Store input mappings and per-game launch settings in a versioned configuration, and keep last-known-good settings available.
Separate the privileged launch service from the Electron display. Follow Electron's security guidance, expose only narrowly scoped IPC calls and validate paths and arguments. Downloaded artwork and remote content must not gain the ability to run arbitrary local commands. The attract loop should continue offline from local assets.
What would prove it
Use five representative installed games and run 50 launch/exit cycles. Include forced game termination, missing artwork, missing executable, controller unplug/reconnect and a network outage. Perform ten cold starts and confirm the cabinet reaches a playable menu without operator input.
Proposed gate: every test either launches correctly or shows a useful error; exit always restores working menu controls; no privileged desktop action is reachable through normal player buttons; the selected display mode survives relaunch. Set a boot-time target only after measuring the actual host, then log its distribution rather than its fastest run.
The path to a complete build
- Back up the existing configuration and document the hardware.
- Validate input mapping and a five-title catalogue before changing the theme.
- Implement process supervision, launch errors and keyboard-free recovery.
- Add local artwork fallbacks and an operator diagnostics page.
- Run a two-hour public-use simulation, then package a restorable release with a short operator guide.
Open the engineering notebook
Components, interfaces and calculations
Inventory the actual display resolution, host specifications, encoder model/firmware, audio controls and supported games. Record the exact button mapping for both players, including deliberate exit and operator-menu combinations. Test simultaneous button presses and held inputs. Use a serviceable harness and preserve access to the computer's recovery controls.
For each title, record executable, validated arguments, working directory, controls, exit method, display mode and artwork location. Keep the game catalogue independent of visual themes. Generated art is presentation material, not evidence that a game is installed or launchable.
Scope and development questions
Plan 4–7 integration sessions after inspecting the existing source. Reuse working controls and display; budget replacements only for demonstrated problems. The main unknowns are the current code revision, emulator configuration and whether the present build already handles recovery. This page is a proposed validation plan, not a claim that the existing Cabinet software has failed those tests.