Functions

The generated client library attaches one global, Gamehoster, built for your exact game. There are two ways in. Most games use the abstraction: call Gamehoster.start(root, join), and the library owns the frame loop, the input and the per-object lifecycle, calling the game's own gamehoster-frontend/ snippets each frame with a Gamehoster that reads the whole interpolated world. A game that wants its own loop uses the low-level Gamehoster.connect(game, join) instead. This section lists every call on both paths, grouped below. The asteroids example is the abstraction end to end.

Groups

World →

Reading the interpolated world each frame: Instance, Players and Entities as views, the per-frame Frame, plus start, Root, Persistent and Reconnect.

Input →

Reading the pointer and keys (Mouse, Keys) and acting: sending the game's Commands, feeding prediction Input, and the declarative input map.

Connect →

The low-level path for a game that runs its own loop: connect and the conn it returns (frame, send, input, latest).

Bot →

Server-side, inside a bot body: the bot's own id and private memory, the other bots, and the one call that acts — sending the game's own commands.

The view object

Under the abstraction you never touch a socket, a snapshot or a tick number. The library folds the server's per-viewer deltas into a store and hands each frame an interpolated view of every object you can see. Gamehoster.Instance is one view; Gamehoster.Players and Gamehoster.Entities are Maps of them. Every view carries the same shape.

On a view	What it is
its schema fields (`x`, `y`, `angle`, `score`, …)	at the top level, already interpolated for this frame (numeric fields eased between snapshots, others as received).
`.current`	the newest authoritative sample, un-interpolated — the exact server value.
`.prev`	the previous authoritative sample (equal to `.current` on first appear).
`.data`	the object's front-end persistent bag, seeded by its `-enter.js` body and kept for its whole visible life.
`.id`	a stable local id, assigned once on appear and surviving a netId renumber.
`.type` (entities) · `.self` (players)	an entity's type string; whether a player view is your own.

`Gamehoster.Bot`

Server-side, and unlike the namespaces above not part of the client library: this one appears only inside a bot body — the join and update bodies of a server-side player. A bot has the whole read surface the tick has (Instance, Player, Entity, Tick(), Entropy(), …), read-only for game state; what is unique to it lives under Gamehoster.Bot. Its id is its player id, so it reads its own ship with Player.All().get(Gamehoster.Bot.id), and it acts only through Bot.Send — its bodies are firewalled to no game-state writes.

Member	What it does
`Gamehoster.Bot.id`	This bot's id — which is also its player id. Same as `Gamehoster.Context.botId` and `Gamehoster.Context.playerId`.
`Gamehoster.Bot.Persistent.Get()`	This bot's live private memory (server-only, never sent, never firewalled). `undefined` until set. Mirrors `Instance.Persistent`.
`Gamehoster.Bot.Persistent.Set(value)`	Replace this bot's private memory. Mutable in place and never serialised, so it may hold a `Map` or any structure.
`Gamehoster.Bot.All()`	Read-only `Map(botId → { id, type, persistent })` of every bot in this instance — the bot analogue of `Player.All()` / `Entity.All()`, for coordinating between bots.
`Gamehoster.Bot.Send(type, params)`	The one way a bot acts: queue a command as this bot into the normal per-tick flow. It runs through the game's own unmodified handler next tick, exactly as a human's input would.