Internals
This section explains how Gamehoster runs, worked through as one model. It starts on your machine with the local tool, moves to the server box, the infrastructure that serves the play and the protocol it speaks, covers the two management APIs the local tool 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 and commandwritesprecomputed. - a front-end library, the client generated for this game: the snapshot runtime and
connectwith this game's config, schema tables and binary codec baked in, plus its optional predict body. That predict body, run for your own object, is the only game logic the client runs; everything else it shows is interpolated.
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 the box serves it is the Infrastructure page, the binary it speaks is the Protocol page, and how the runtime works is the Instance page; the generation step itself is the Sync page.
Each tick runs the tick function, the three-step cycle from the tick: handle the commands, update every actor, run the instance body.
The pages
The parts shared by every hoster, the local tool, the server, sync and the tools, live in Hoster. What is unique to gamehoster is here.
Infrastructure →
The authoritative half in the large: Caddy out front, and the one backend process that runs the API web server, seats players, and runs every game's tick and send loops.
Protocol →
The binary wire protocol: the four message types, the exact bit layout of each, and how every value is packed to the fewest bits from its schema range.
Instance →
The heart of the model: the state it holds, the pure tick function and its Gamehoster
object, and the update that sends each player a delta of just what they can see.
Frontend →
The browser half: the snapshot store it keeps, the smoothed clock and interpolation, the ballistic entities it draws from their parameters, and the optimistic prediction of your own actions.
Model and code
These pages describe the model as the code runs it: authoritative server, the tick function, the per-viewer delta each player receives, the view, and the client that interpolates it and predicts your own actions. The prediction add-ons are still being refined; where a detail is still open, the page says so.