In 2020, I came out with my first ever game which was FROG. It was an online where you could hop around and chat with text. While it worked, god love it, it wouldn't take much to make the whole game fall over. There is only a single server available and once more than a handful of players connected, things would get a bit weird. Frogs would lag and get disconnected all over the place. Luckily enough, its a rare enough occasion that there are more than that amount of players online and for how dodgy it is, it is still up and running 5 years later! That's a win in my book!
So now when approaching our new game, Wee Boats, we wanted to try and tackle some of the main issues to make it a tiny bit more resilient than that beautifully naive setup! The main issues were:
In this post, I will outline some of the parts of the Wee Boats online architecture. It's by no means perfect but for a small game like Wee Boats, I think it will go a long way.
So the server code is made up of separate Bevy application running headless on a server. It uses the bevy_renet crate to handle connections and messaging from and to the clients. It runs at about 120 ticks per second and is constantly polling for new messages. This uses a trickle of CPU on my cheapest 4$/month digitalocean droplet.
This is a completely separate project to the main game but it's neat that both the frontend and backend use the same language and the same game engine. It makes life a simpler.
Multiple Servers!
To start us off, we have created a way to list currently active servers and allow the player to choose the one that appeals to them the most based on location or how many is online. This is crazy technology in comparison to FROG!
When the game starts up, it immediately queries an address that will send back a JSON document which lists the currently active servers. These servers are then listed to the player and they can choose which one they would like to connect to.
Example JSON:
{
"servers": [
{
"name": "Europe",
"location": "Europe",
"ip": "X.X.X.X:XXXX",
"online": "0 / 64"
},
{
"name": "America",
"location": "Europe",
"ip": "X.X.X.X:XXXX",
"online": "0 / 64"
},
{
"name": "Offline",
"location": "Offline",
"ip": "",
"online": "No"
}
]
}
How this looks in the game:
This is going to improve things a whole lot in comparison to the FROG days. With multiple servers I can have players connect to servers that are closer to them for a better experience. It also allows me to introduce new servers on the fly if there happens to be a lot of players online at one time.
Because we are not worrying about cheating in Wee Boats, we can use a networking model called Client Authoritative. What this means is that each game client is in control of its own boat and it will rapidly send updates to the server with new information about the boat. If the boat is moving, the client sends the message with its new position to the server and then the server will broadcast the new information to all the other clients that are connected. Same goes for if the player honks or sends a text message. An update goes to the server and then the server broadcasts the update to the other boats. This has its flaws but for a casual game like Wee Boats, it fits perfectly!
When a client receives position updates for a networked boat, it will smoothly move the boat from the old position to the new position. With updates coming in rapidly, this makes the networked boats feel like they are being controlled nice and smooth!
Well I haven't and I don't really know how with my current resources! The max that I have tested so far is 5 clients online at once and that works great so at the moment I'm crossing my fingers that it works that well at 64 players online! I know that this is a recipe for disaster! :D
Something that is important to me is that Wee Boats can run independent of the servers being online to help it run long into the future. Because of that, we have added an offline option where the player can experience the entire game, just without the online components. Even if the initial server list http request doesn't go through, the offline option will populate.
Currently, adding and removing servers is a manual process. I need to keep an eye on the numbers online, manage the online servers and keep the active server list updated that gets sent to the games.
I am not expecting a lot of players to be coming into the game but if this is something that happens, it would be great to have a script monitor the player numbers and manage this itself. I just want to be careful that I dont create something that racks up crazy bills!
That's all for now! :D