Want to know how to reduce the operational costs of your multiplayer game or just to start one by planning ahead for ultra low costs? In this article we’re going to talk about the major things that influence the cost of our whole operation in a multiplayer game. Things like: cloud services, regional servers, Content Delivery Networks (CDN), server performance, and a few others. We will approach many possible ways to reduce the costs of these, and hopefully help you come up with a good plan for your network architecture and a great system design.
This one is a no-brainer when we talk about online games. While it is cheaper to develop and test your game in a LAN, if you want to release your game to the masses, you will need an infrastructure to put all of the databases, service applications, and game servers.
Using the cloud for hosting our game is without a doubt the way to go. It will provide a very reliable and redundant service that will guarantee that your game is up all the time. Moreover, it will also be cheaper than buying your own hardware and hiring redundant power and internet sources to try to keep up with the same options.
Services like Amazon Web Services (AWS) and Google Cloud Platform (GCP) are great for general use cloud operations, including game. We also have some cloud services that specialize in games like AMPD Games services; which focus on delivering a lower latency in cloud services with specialized hardware for gaming operations while keeping the costs even lower than some of these big companies.
Another big advantage of using cloud services is how easily you can have servers in many locations around the world, a.k.a Regional Servers. And while having more regional servers may help you provide a faster experience that will make your game feel very crisp, each of these servers incurs some costs. The more regional servers you have the pricier it will get.
When you’re first launching your game, it is a good idea to filter down to the fewest amount of Server regions to work with. This is for a few good reasons that are not related to costs.
Depending on how you have planned to update the game servers with the latest builds the time can vary from a few minutes to several hours. The fewer servers to update the easier and faster you’ll be able to fix, patch, and update your servers.
Another reason that is highly overlooked when deciding on how many regions to go for is… The users! Well, having more regions means a better experience for the users right? Not exactly, and here’s why. Yes, many regions = faster response time for the game all around, but what about how many users connect to a single region? This affects the game in a very different way that most people would just not expect.
Having several regions means that users will now divide into all the available regions, which means fewer players per region, which ultimately leads into users playing against the same users all the time or worse… Not having enough users in their region to play with/against.
Think about it, if you put a server in each country of Europe for example, you will most likely have players from that country connecting to their respective server. German players will play against players connected only to the German region server, and the same applies for every other regional server.
It is better to have one server in the center of Europe (i.e Frankfurt) which will host for all of the European players, and another one in the center of North America that will host for North American players, you could also have one in Brazil to serve the Latin American countries, so on. This slightly higher latency will not affect your game as much as not having enough players could.
It is very important to define which countries you think will be playing your game the most and work around these countries. Surveys, or any kind of poll are always a good way to assess your user-base.
ContenT Delivery Network (CDN)
This is what helps you get your game to the masses. When the users buy your game, they have to download it. If you don’t have a CDN, and host the file from a single source, not only will the download speed will be very slow, but it will also be very expensive for you.
A simple solution and the recommended one is to go with Steam or any of these Game Distribution Services. It is just too much of a hassle to have to deal with distributing your game on top of how your game is doing. Yes, steam takes a cut, but trust me, it is well worth it since they also take care of hosting a page for your game and even some marketing. If you ask me, for all you get, this one is also a no-brainer.
Design for Scalability
This simply means, architect your whole network to be small at first and to be easy to increase in size, in other words to be very elastic.
Never assume the size of your user-base. One mistake I made while I was working on one of my previous projects was to assume that thousands of players will be playing the game from day 1. Big mistake! This did not hurt the game in any sense, but it really hurt our expenses. I planned to have several Databases per region, and separate every service into their own cloud server. Man this was a headache to “Fix”.
I had to migrate tables and data between databases, change some of the code that was relying on having several DBs, join services into a single instance of a server, and restructure how my system was going to dynamically grow. All of this in a separate testing environment to make sure everything was working properly, and then I had to roll out this environment to “Live”. This might not sound so complicated, but it was a handful to work with and very stressful since I was running against the clock, you know… Costs!
In the end, everything worked perfectly with 2 global DBs, 1 regional DB, 1 global instance, and 2 regional instances running the services and the actual game servers. Only 2 of these instances would grow dynamically. The cost reduction was massive, we ended up spending about 28% of what we were spending before.
Don’t make the same mistake. I had to learn the hard way. Start small, design and architect everything to grow dynamically from a low cost operation. Most importantly Never assume things. This goes hand in hand with our philosophy: Make educated decisions.
Branching out of the Server oriented path we encounter a system that can get rid of most of our server costs, this is called P2P.
A drawback of doing this is that we will be giving away the entirety of our game. This means that the users will have direct access to the Server and the Client. The reason for this is that instead of hosting game servers we will allow the users to host their own server, either deliberately or unknowingly.
This is a way how P2P gaming works, The client connects to a special server that holds records to all other clients and which ones are running a server, then the server redirects the users to one of these servers being run by a user. In this case the entire game loop will be managed by the users and just the connection will be managed by a server and DB.
We will be playing the game directly user to user, hence the name Peer2Peer. Now there are some major flaws around this method and you can imagine that now our game is completely vulnerable to being hacked and cheated. Another major big concern is the latency and performance of our game, since we cant control what kind of computer the user is using (a potato), the ISP that the users are using, if the user is throttling his connection, or simply using a lot of bandwidth in other applications.
This lack of control will hurt the performance of our game. It will be a more appropriate approach for games that do not require many resources to run. Clearly we need to be OK with the users having full access to our technology.
There might be some cases that this is a good approach for a very specific type of game, but in general it is not recommended to go with a P2P game.
Reducing the CPU and Bandwidth load on the servers will allow you to run more games per instance, hence reducing your overall hosting costs.
Some ways that can help you reduce the bandwidth load and the CPU load of your servers are the following: Separate your server and client code, Do not use State Synchronization, Use a specialized communications library (RakNet), use your own Communication Library (Scokets), Bitwise Optimizations, Object Pooling, and so on.
In a future article I will go in depth into the details of some good optimization techniques for servers and networking in games.