Game

The game-wide surface of the Gamehoster library: booting the client, the front-end persistent bag, the frame clock, the connection, and the three bodies that run for the whole game rather than one object. The world you read each frame lives on the Instance, Players and Entities pages.

The game surface

Member	Description
`Gamehoster.start(root, join, opts)`	Boot the client on a root element or its id. `join` carries the player name; `opts` are optional client options. This is the whole boot.
`Gamehoster.Root()`	The root element you passed to `start`, the canvas the renderer draws into.
`Gamehoster.Persistent.Set(key, value)`	Store into the game's own front-end bag: the context, image caches, seed state. Set it in setup.
`Gamehoster.Persistent.Get(key)`	Read the bag back from any body.
`Gamehoster.Frame`	The frame clock for the current frame: `{ number, time, dt, tick, lead }`.
`Gamehoster.tickRate`	The game's server tick rate, in ticks per second.
`Gamehoster.connected`	True while the socket is up.
`Gamehoster.Reconnect()`	Tear down and start over after a drop, the click-to-reconnect path.

The persistent bag

The game's persistent bag is the client-side store the render loop carries between frames. Fill it once in gamehoster-frontend-setup.js, which runs a single time on connect once the root is known, and read it back with Gamehoster.Persistent.Get from every body.

var canvas = Gamehoster.Root()
Gamehoster.Persistent.Set('ctx', canvas.getContext('2d'))
Gamehoster.Persistent.Set('stars', makeStars(200))
Gamehoster.Persistent.Set('shapeCache', {})

The asteroids setup body: cache the context and the renderer's between-frame state.

The frame clock

Gamehoster.Frame carries the timing for the frame being drawn. The render clock runs a fixed buffer behind the server's leading edge, so tick is a fraction behind the newest sample and the world reads already smoothed.

Field	Holds
`number`	the frame count since boot
`time`	seconds since boot
`dt`	seconds since the previous frame
`tick`	the render clock's tick, the point the world is interpolated to
`lead`	how many ticks the server's leading edge sits ahead of the render point

The game-wide bodies

Three bodies run for the whole game rather than one object. Each is optional.

Body	When it runs	For
`gamehoster-frontend-setup.js`	once, on connect	Reach the root and cache what the renderer needs into the persistent bag.
`gamehoster-frontend-update.js`	once per server update, after the per-object handlers	Game-wide state that must follow the authoritative frame: a leaderboard sort, a score memory, read from each object's `.current`.
`gamehoster-frontend-tick.js`	each client tick	Logic paced to the game's tick rate rather than the display frame rate.

var board = Gamehoster.Persistent.Get('board')
board.length = 0
for (var p of Gamehoster.Players.values()) board.push({ id: p.id, score: p.current.score })
board.sort(function (a, b) { return b.score - a.score })

An update body: rebuild the leaderboard from each player's authoritative score.

The lifecycle order

The library runs the bodies in a fixed order at each cadence, so a body always sees a settled world.

Cadence	Order
once, on connect	setup
per server update	each object's enter, then each object's exit, then update
per client tick	predict, then tick
per animation frame	smooth, then render