Publish: Game server orchestration

_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
+- 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 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
+- 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.