Still moving… Steam Direct maybe?

This is going to be a short devlog. I’m really hoping to put this on Steam Direct, but I have a lot of concern regarding what quality of game is required to get published on Steam.

Will the game need to be fully completed? Is early access still an option?
How much can I charge for {Soul}Ascension to keep the servers running?
How will I advertise this game?

There are far too many questions for me but I do hope I can get on Steam especially early access.

I haven’t released any updates in a long while, but I really look forward to putting out something players enjoy playing. Hitting a 100 concurrent players would be a dream for me!

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.

Localhost

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

0.0.0.0

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.

Post-Morten

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.