diff --git a/_notes/game-server-orchestration.md b/_notes/game-server-orchestration.md index cb1f32f..b9f9813 100644 --- a/_notes/game-server-orchestration.md +++ b/_notes/game-server-orchestration.md @@ -2,21 +2,20 @@ title: Game server orchestration --- -To me, *game server orchestration* is solving the problem of provisioning dedicated game servers in a scalable manner for a multiplayer game. +Game server orchestration is solving the problem of provisioning dedicated game servers in a scalable manner for a multiplayer game. -When I added dedicated server builds through [[PurrNet]] for [[Resonance]], a cyberpunk-themed first person shooter, I did not realize the work I was giving myself later when it came to launching the game. Pre-rewrite, the [vibe-coded prototype](https://github.com/brendan-ch/ResonanceServerOrchestrator/tree/2d71f0491830dfa91d7887c208c14c52d6513202) I created comes nowhere close to being production ready. +When I added dedicated server builds for [[Resonance]], a cyberpunk-themed first person shooter, I did not realize the work I was giving myself later. I created a [vibe-coded prototype](https://github.com/brendan-ch/ResonanceServerOrchestrator/tree/2d71f0491830dfa91d7887c208c14c52d6513202) of a server orchestrator that was nowhere close to being production ready. -Previously the game used [PurrLay](https://github.com/PurrNet/PurrLay), a peer-to-peer relay that clients connect to, where one of the clients becomes the *host* for a match. With the *dedicated server* architecture, all clients connect directly to the game server which can run game logic.[^1][^2] Adding the game server orchestrator means knowing when to start and stop a server, and how to point players to the server with the correct match. +Previously the game used [PurrLay](https://github.com/PurrNet/PurrLay), a peer-to-peer relay that clients connect to, where one of the clients becomes the *host* for a match. With the dedicated server architecture, all clients connect directly to the game server which can run game logic.[^1] Adding the game server orchestrator means knowing when to start and stop a server, and how to point players to the server with the correct match. I decided to try and turn the aforementioned prototype into a [custom backend](https://github.com/brendan-ch/ResonanceServerOrchestrator/tree/2d71f0491830dfa91d7887c208c14c52d6513202) for the orchestration. The basic flows look something like this: -- Players *join* a match in the orchestrator after having been in the same lobby, so the orchestrator doesn't depend on the lobby backend -- When all players have joined, the orchestrator provisions the dedicated server, and players *connect to the dedicated server* to play the game -- When the game ends, players *leave* the match in the orchestrator, and the server exits +- Players join a match in the orchestrator after having been in the same lobby, so the orchestrator doesn't depend on the lobby backend +- When all players have joined, the orchestrator provisions the dedicated server, and players connect to the dedicated server to play the game +- When the game ends, players leave the match in the orchestrator, and the server exits -[Edgegap](https://edgegap.com) is currently planned as the dedicated server platform. But, hopefully, with the custom orchestrator, we retain some ability to switch to other providers. +[Edgegap](https://edgegap.com) is currently planned as the dedicated server platform. But, hopefully, with the custom orchestrator, there is some ability to switch to other providers. -Right now this system works fine in development when conditions are predictable, but there is still much work to be done. I am *not* a backend engineer by trade. +Right now this system works fine in development when conditions are predictable, but there is still much work to be done. [^1]: I didn't realize that I could drop [PurrLay](https://github.com/PurrNet/PurrLay) when adding the dedicated server until later. -[^2]: With Unity, a dedicated server build generates a Linux executable that can be put into a Docker container.