I am currently investigating my options for hosting a real time multiplayer game. From what it sounds like, this service strikes two big things for me:
Automatic scaling
Regional hosting (to address latency)
So I am very interested.
Per title, I am simply interested in knowing if it’d be possible for me to write some code in, say Golang, that would could connect servers on the network together as they pop in and out of existence. Basically, I just want a way to communicate some state between servers while they’re up and running. Is this possible? If so - what would be an ideal way?
Also - say I wanted two apps hosted. One being a basic http server and the other being a game server. First - would this be reasonable/possible to do or should I just let them exist as one? Secondly, if I was to host the game server as a second app would it be possible or make sense to have it auto scale or use the machine api?
We provide VMs. What you run on them is entirely up to you. Place everything on one machine. Or not - spin up new machines as you need them. Be as creative as you want!
I host my gaming app (chipsoffury.com) on fly. I hope to do a longer writeup soon, but on a high level here’s what I do:
I have two apps - admin_servers and game_servers:
admin_servers:
admin_servers app is responsible APIs for user management, and for orchestration of game servers. Orchestration here means, assigning the closest game server to the requested game, and creating new game server machines if needed.
admin_servers is running as a typical fly.toml orchestrated app, in a single region.
Hosting it in multiple regions for me doesn’t make sense as I use a traditional postgres database for the backend datastore. So requests will have to go to database server’s region anyway.
I run multiple instances of the admin servers for redundancy. I use the blue-green deployment strategy to do new releases, and it works quite well.
game_servers:
game_servers app is the one where game servers are running. game_servers are relatively independent and do not require a central datastore. I use sqlite with litestream based backups for game data persistence.
instances in game_servers are created / destroyed using the machines API (by the orchestration logic in admin_servers).
game_server instances can communicate with the admin server instances using internal networking.
clients connect to the game servers using websockets. the websocket connection is made via the admin server using the fly-replay header.
I do not have any need for communication between game servers though. You seem to imply your game servers need to talk to each other. I am not sure about the use-case, but it might be easier to model your game servers to be stateful and all users of a particular game to connect to the specific machine that is hosting that game. the fly-replay header is quite useful for that.
@Cay The one caveat I would say here is while there is some scaling, they do not spin up new machines past what you allocate, and machines do not auto scale to higher spec machines. Just keep that in mind