Internals

This section explains how Gamehoster runs, worked through as one model. It starts on your machine with the client, moves to the server box and the live networking that carries the play, covers the two management APIs the client speaks — sync and tools — and ends deep in the model: the instance and the front end. None of it is needed to ship a game; it is here so the whole picture, and the design, has one place to live.

How it runs: generated ahead of time

A game's definition (JSON schemas and raw JS bodies) is generated into plain static code when you sync it, not interpreted on the server. The build emits two files per game and the sync pushes them; the server loads them directly, so no new Function ever runs at request time:

a server module, the game as an ordinary module: config and schemas inlined as data, every body inlined as a real function (Gamehoster) { … } (compiled by Node when the module loads), with defaults, smooth fields and command writes precomputed.
a front-end library, the client library with this game's config, smooth fields and shared front-end bodies baked in.

The runtime that runs every game is shared: the same code loads each generated module and runs the tick, rather than compiling raw bodies. How that runtime works, and the network layer that serves it, is the Networking and Instance pages; the generation step itself is the Sync page.

definition ──generate (at sync)──▶ static server module + front-end library
 (JSON + raw JS)                     (bodies inlined as real functions,
        │                             pushed to the server, ready to run)
        │
        └── sync ──▶ server ──require──▶ World ──▶ live instances (tick loop)
                       │                              │
   browser ◀── relayed commands + state (send rate) ◀─┘
      └── commands ──▶ Caddy ──▶ localhost (Host→game routing)

The definition is generated to static code at sync time; the server requires it and runs the tick, with no runtime compilation

Each tick runs the tick function, the three-step cycle from Updates: handle the commands, update every actor, run the instance body.

The pages

Client →

Every file the client is built from — the tools command you run, the sync-and-generate pass, and the shared toolkit behind them — each with its exports or its switches.

Server →

Everything on the box: the games mirror the server loads and serves, the server code, and the files laid down under /opt, /srv and /etc.

Networking →

The authoritative half in the large: the static and API web servers, the websocket server, and the worker processes that run each game's instances across CPUs.

Sync →

The private API and the generate–diff–push process that mirrors each game's definition onto the server, pushing only the files that changed.

Tools →

The read-only API behind the local views: the access logs, the server-health stats, and the Game Logs map built from your definitions.

Instance →

The heart of the model: the snapshot, the timeline, the pure tick function and its Gamehoster object, the update that replays and sends, and each player's view.

Frontend →

The same machine run on the client: the ring it keeps, the commands and state it receives, the prediction that reconstructs the present, and the display that shows each thing at the time its information allows.

Model and code

These pages describe both the code as it runs and the model it is built to: the snapshot, the tick function, the timeline and rewind, the view, and prediction. It is the design we are refining and the target the code is being brought in line with. Where a detail is still open, the page says so.