Antegods Code Update: Setting up the database architecture for our multiplayer game

Until now, Antegods did not provide the functionality for persistent player data. As with most online multiplayer games there is some form of persistent data management. Supporting persistent data opens up various possibilities, such as:

As an example of one of these features, this is how the player statistics are shown at the end of the match :

These will be uploaded to the database server and added to your global stats.

In order to support the aforementioned features we had to decide what kind of implementation to go with; one that would require internal resources to manage the servers and backend or a cloud-based system where the player information is stored on a secure server somewhere else. We decided to go with a cloud-based user management system as this enables us to focus on developing our game instead of worrying about the server setup and its continued maintenance. 

With this decision made, our first step was to build a prototype that supported most of the functionality we want to evaluate and how these features should be implemented. It also allowed me to get familiar with the topic so the learnings from this prototype could be used as the foundation for the final implementation. This first implementation took a couple of weeks of work.

Because we wanted to use a cloud-based solution for the final implementation we had to look into the best cloud provider and its accompanying SDK. Based on criteria such as scalability, security, price, migratability, active support and feature support we decided to go with XtraLife. A snippet of the comparison sheet that we used for this decision is shown below.

XtraLife was also the SDK we chose for the initial prototype which meant a direct comparison could be made between the final implementation and the initial prototype.

During the first implementation a few imperfections were discovered and they needed to be improved. For example, sequencing should be better enhanced in the final version as it will provide cleaner and better maintainable code. Also, UI code and code having to do with data presentation should be split from the other code. These are however fairly minor changes.

One of the bigger changes between the two implementations is the design. First of all, the code for the original implementation resided in the main Antegods project and the code for the final implementation resides in a separate dll project. Also, all third party code has been moved in the same fashion. The reason for this is that when it resides in a separate DLL it is very modular and abstract. This ensures that we can use this code very easily for other projects. Another advantage is that all code in the third party folder in the main Antegods projects will be rebuilt every time the project itself is rebuilt, which significantly increases build times.

The structure of the code itself has also been changed a lot, the new structure is displayed in the UML above. The structure of the UML is the outcome of all the abovementioned design changes as well as the choice to combine the pre-existing stats class with the stats class used for the database, namely “OnlineStats”. We also decided let “OnlinePlatform” manage the “XtraLifeCloud” and move the login functionality to “XtraLifeCloud”. This way all database related functionality is centralized and XtraLife did not need to be a static class, which it was before.

“OnlineGamer” holds all the gamer related classes. This way we can easily and intuitively access these properties as shown below.

MultiplayerContext.Instance.Me.OnlineLeaderboard.PostScore(SocialService, “TopScores”, 100);

All in all, this structure is a lot cleaner and more compact than the structure from the prototype.

Another big change over the prototype is the server-side scripting that is now in use. Before, data would be retrieved from the server, altered and then stored back on the server. Currently, all the calculations are done on the server, this is done in JavaScript hooks that can be accessed by the code in the DLL. Doing all these calculations on the server is a lot more secure than doing them on the client. For example, after a game, the player’s scores are incremented on the client side. This way the player could easily alter the code so that it would upload better scores than they actually achieved during a game. The player could also try to manipulate his in-game currency balance or his leaderboard position which would have a negative impact on the online community. All of these risks are reduced by doing calculations on the server.

Now you know a bit more about the database part of Antegods and what to expect when it comes to persistent data and user management. I hope you enjoyed reading the explanation and if you have any questions on any of the items covered drop us a message on Discord, Twitter or in the comments.

Social media

If you enjoyed this blog post, and are interested in chatting with us more or participating on Twitch.tv then don’t hesitate to jump on Discord and chat to us.

To follow our development updates, please check us out on Tumblr, Twitter or Facebook. And don’t forget to subscribe to our newsletter for info on events and sales.

Antegods is supported by the Dutch Cultural Media Fund, Cultural Industries Fund NL and the MEDIA Programme of the European Union.