Connecting Together

As you already know {Soul}Ascension is a server based multiplayer game. As such, I gave a lot of thought on how to approach player connectivity. I did some prototyping on P2P model but I eventually stuck with a client-server model instead. This meant I had to decide between whether or not I should delegate the hosting responsibility to the players or myself.


Of course there are pros and cons to both choices. Delegating the hosting to a player’s machine meant that all players can play the game at anytime as well as have good latency between themselves and others within the same region. But using that approach introduces a few questions to address. What are the system requirements for the hosting player? How can I keep all the players to the same version of the game? What if the host radically changes the game settings? What’s an inexpensive way to prevent cheating?

Screen Shot 2017-03-17 at 10.19.41 AM
Running server console

If I were to be hosting, I could maintain all control and consistency for the game between all players. You would have to be on the latest version of the game if you wish to play with others on the server. I could alter the game experience however I wanted and the changes would be propagated to everyone. This approach sounded great for keeping a consistent game but it did have a few draw backs. I would have to pay for a server to host the game. I would need a way for players to discover the servers I’m hosting. Should I still allow players to host their own servers? Which regions should I host the game?

Screen Shot 2017-03-17 at 10.06.32 AM
Cost of running the game server

In the end, I decided to be responsible for hosting the game server.  I decided to host in 2 regions at the time, Australia and US West, as I expected only a few people to give the game a try. This also meant I had to address the server discovery problem, which I used a simple central hub design to solve. However, by hosting only in these regions it excluded a lot of potential players due to latency and poor experience. This didn’t mean I abandoned the idea of letting player’s to host entirely. Players are able to host their own using a few launch options, although not officially supported. I gained a few a bonuses from implementing the ability to also let players host. It introduced ways to alter many settings for the game server without needing a release and encouraged me to come up with a few primitive ways to combat cheating.


Now, after a few months of maintaining the game server in production, I gained some insight I didn’t expect I would have. By running the servers myself, I collected statistics about the server’s health, the game server’s stability and performance, and more importantly the cost of running it. It also taught me how to maximize my the machines’ resources since I was trying minimize cost without hindering the game’s overall experience. What I really didn’t expect was gaining confidence in my server code. After seeing it had ran well and good in the last few months of production, I was hugely confident in it’s stability! Any hiccups or issues that did occur I had already implemented self-recovery and they worked, which was great! Even though hosting my own servers costed me some money, I have to say it was an excellent experience. For the future, I’m looking to use more Cloud engineering techs to potentially scaling servers to meet demand rather than have them on all the time to save costs.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s