Arcade: any game on any display

The idea: the core in the middle#

The game never talks to the display. Neither does the display talk to the game. The Core is the only one that knows both, and it passes messages between them.

Three kinds of messages flow around:

• Event: what the user did (key pressed, mouse click). Produced by the display, consumed by the game.
• AnyInstruction: a drawable primitive, "draw this here". Produced by the game, consumed by the display.
• GameEvent: a request from the game to the core, such as quit or switch to another game.

Because a game only emits abstract instructions, it works the same in a terminal and in a window.

What a game must implement#

A game is a class with five methods. The core gives it input, and asks what to draw.

What a display must implement#

The display side is the mirror image: it draws instructions and reports input.

Each frame, the core runs the same loop. It never mentions Snake or SDL2.

1. Poll

   The core calls pollEvents() on the display.

2. Update

   It passes those events to the game with update().

3. Collect

   It reads getGfxInstructions() from the game, and getEvent() to handle quit or switch requests.

4. Draw

   It calls clear() then render() on the display with the instructions.

How plugins get loaded#

Each library exports two C functions. The core uses the second one to know whether it just loaded a game or a display.

Try it#

Once running, a few keys control the platform itself.

What I take from it#

The whole design rests on one decision: two small interfaces, and a core that is the only place where they meet. Adding a game or a display never touches existing code, you just drop a new .so.