Have you ever ran game-server instances on a “dedicated server” 24/7 ?
If you ever made an online game with some fluctuation in traffic
(some gamers sleep, yes) you probably had the game-server instances on a so called “dedicated server”. Like most people i choose a “dedicated server” from non other than OVH because it looked good, 12 cores, 32gb ram is nice for 80$ (hosted in Canada)
The servers are still in a pool and do share resources with other server. This means you still have the same problems as with VPS. And you don’t really have a dedicated server.
Cloud Hosting paired with Automated deployment
There are a lot of different cloud hosters you can use.
Look at your needs and choose accordingly.
- Check hosters paying policy
If you pay daily or by the hour make sure not to kill servers that you have payed for already. When paying by the minute, you get much higher prices, for extra flexibility.
- The API needs to fit your needs
Make sure you can build your server with the provided API and image deployment system
- Have restriction in place if your system goes bonkers
Imagine deploying 1k servers at the lowest rate (5$/month), yeah, you do the math. You could set a dynamic max servers that also helps for calculation of max cost or/and cost by thousand users.
After you know what hoster you are gonna pick, you can start laying out the basic logic, you should ask yourself a few questions:
- When to deploy a new server?
This of course is much more complex than just deploying new servers. The most important thing is to understand the usage and adapt for it. Also something that is important for scaling, is to use relatives to set any value. Whatever the process you have to do (make image, deploy with image, post installation setup) make sure to understand how long this takes so you can account for this time in the Deployment software
- When to delete a server?
What are you gonna do with users that are still using the server you want to kill? If you just delete the server, make sure to have a frontend notification or reconnect them through the frontend. If your game allows this: Connect the user directly to a new server from the old server and transfer progress/points
Something important: Don’t delete a server if it’s payed for already, this may seem like something obvious but actually wasn’t the first thing i considered when building this system.
First things first, you should visualize the process your server deployment is gonna go through.
First we need to get our excising data, whatever your game can give you. Normally you’d have an API endpoint setup on your gameserver to get information from the Server itself.
So getting all data from each server could be as easy as asking each server for its data via an API call.
In this example we have the SQL DB that takes care of tracking what server is online and its DNS with the API endpoint. This is also used when deploying the server so it knows what it’s supposed to be.
In this example our game has different Game-modes so we need to check each server on each game mode, or maybe just checking the last server in the list is gonna be enough for your application. Make this easy for yourself and define global ids for everything. id the region, the gamemode and whatever data you will use again.
This object does not contain id’s for gamemodes or regions, so we have to relay on a string that then has to be split into the parameters so we know what we are working with, this may be ok if you have to push a lot of data into one string, but in our case it would make much more sense to have specific keys.
Other checks should happen before this for example if you know you won’t delete a server that is less than 1 hour old, you also don’t need to run the logic over it.
This could even happen before the initial fetching from the stats API endpoint of the game server. If you have data on how old it is. In this example, because we keep track of the servers in our local database we can check when it was created before attempting to get the realtime data, this just helps keeping things simple.
If you decide to do this, make sure to ping the server at least to make sure it’s online. This depends a bit on what kind of servers you are running, but if you know they can crash/break, make sure to check everything.
Because of time zones 🌎 and more dominat user basis in different parts of the world. You should be able to adjust the max and min values for whatever checks you do.
What you are trying to achieve is a more aggressiv server for when users are more demanding and a less aggressiv server when the users are less demanding, this also helps saving money and make the game better.
Imagine getting the biggest boost of users in your games history for whatever reason. Imagine your “super cool automatic server” to just not deploy new servers because it doesn’t really have any scalability when making decision.
This is when you could implement a number of cool tools to help you keep track of the website without looking at the servers. For example having a real-time active users API endpoint for your server to take into consideration would be a good idea, you could also keep track of this on the local DB, this could help calculate what x users normally need.
This can get complicated if you have different game-modes in different regions
You’d need to break down everything for each region and then for each game mode.
When deploying servers it can get complicated. Here a little overview on what i needed to do:
- Like i said above, first i need to get the id of the game mode.
- Then i’ll need to get a datacenter id to deploy to (this is different for every hoster)
- Choose a cloud server plan for a specific game mode (some game modes hold less users so they don’t need a good server)
- Then we finally can create a linux server from the API
This in itself needed to happen for the server to be created properly-> create a server -> create disk for swap -> create data disk -> create config -> boot
- After making the server we can get the IP of the new box
- Again we now transform the Datacenter id to a continent string
- Then we convert the template back to a gamemode string
Now we have all the data to add a new DNS to cloudflare.
Make sure to make the DNS unique so even if you forget to delete it, it won’t interfere with newly made servers.
And we can also add a new gameserver instance to the Database.
This is also used by the server itself to see what kind of game instances it should deploy
If you’d do all of this with individual sync AJAX calls you would get overwhelmed by callback jungle.
So build yourself modular functions away from the main code so you never have to see em again 👌 So that the 7 steps above can be done with a simple function call. Just wrap up everything you can so you can concentrate on tweaking the server so it saves you money and players.
There are a lot off cool tools that are made for developing automated software that come with existing API wrappers use them!