edgegap-server-design

Topics in the source

• Designing a server for Edgegap
• Authority
• The deployment lifecycle contract
• Statelessness and logs
• Single-player and always-online sessions
• Persistent worlds
• Next

On Edgegap, one deployment is usually one match. The server is started for a specific group of players, lives as long as their match, and stops when it ends. Servers built that way get scaling, placement near players, crash isolation and per-minute billing for free. Servers built as long-lived daemons that rotate lobbies internally fight the platform (cloud deployments are stopped after 24 hours anyway). The server owns the truth. Clients send intents (inputs, actions); the server simulates, validates and broadcasts the resulting state. Never trust a client-reported outcome (position, hits, score, currency): any client can be modified. Give that up and you have built an expensive relay. Apply as the game needs: Client prediction and reconciliation for the local player, so input feels instant. The server stays authoritative; the client replays unacknowledged inputs on top of server state. Interpolation for remote entities: render about 100 ms in the past between known snapshots. Tick rate is a budget: 60 Hz for fast shooters, 20 to 30 Hz for most action games, 10 Hz for slow sims. Tick rate × entities × players is the CPU bill, and it must fit the vCPU on the app version (minimum 0.

This is an excerpt. Refer to the complete source and its current requirements.