Tips for Writing a Highly Scalable, Server-Authoritative Game – Part 1

Using the GameSparks platform when writing your next chart-topping game offers plenty of advantages – off-the-shelf functionality such as social network integration, leaderboards, virtual goods, in-game currencies, matchmaking, challenges, etc.

Apart from being able to leverage all this off-the-shelf functionality, GameSparks offers you the opportunity to write a “server-authoritative” game. There are many definitions of “server-authoritative” depending on the specific use-case, but all of them offer compelling advantages when compared with traditional “client-authoritative” designs. Quick and easy control over in-game functionality, fraud and cheat detection/prevention, and providing reliability and consistency between connected peers, are just some of the benefits of an authoritative server.

In a classic FPS for example, player positions are ultimately determined by the server, not the client, to ensure every client sees all the other players at the correct position.

Authoritative servers can also help to prevent players cheating, by validating the data sent from the client, and ensuring it follows plausible patterns – for example, if a client suddenly claims that a player’s position has changed drastically, and you know that there is no concept of “teleportation” in your game, you can reject that data, or even kick the player out of the game since you know they must be cheating.

Undoubtedly, using a server in your game is hugely beneficial, even if it is for a single player game. You can store player and game data on the server, so if the game is uninstalled then reinstalled on a client device, the player‘s progress is not lost – it is safely stored on the server, protected from client problems.

However, this brings with it its own challenges. Writing a client-only game, the performance of your game is only dependent on that specific client. What other players across the world are doing cannot affect the performance of my personal gaming experience, since each client is operating in isolation.

Introduce a server, and everything changes. Moving from a world of client code to server code can be a daunting experience. Inefficiencies which didn’t matter on a client can suddenly become a major performance bottleneck on a server – not because the server is any less computationally powerful than a client device (it isn’t), but because it is being asked to work for thousands, or hundreds of thousands, of clients simultaneously.

This is a situation familiar to the enterprise software world, but less so to the changing world of game development. However in reality, following some simple best practice guidelines can help to ensure that when your game goes live, and (hopefully) gains several million players, you won’t have any problems caused by the performance of your code on the server.

This is the first part of a series of articles to help you leverage a server authority to best effect. Here, we start by looking at a simple technique that allows you to increase player engagement, and deal with potential problems whilst minimizing impact to your player base.

Always Be Prepared

Like every good scout, hope for the best, but plan for the worst.

You’ve written your game, it’s been through your QA process, and everything works just fine. Like most games, you have some core game mechanics that are absolutely fundamental to the game being playable. Most likely, you then have “added value” features – all those things that make the game totally awesome for players, but aren’t strictly required for basic gameplay. Push notifications to alert players to new levels, random rewards to those who return, the ability to chat to friends in-play, uploading ghost data so other players can watch how others have completed a level… Whatever they may be, your game will almost certainly have features that aren’t absolutely necessary for your core gaming loop, but are essential to creating a deeply engaging experience that keeps your players coming back for more. If these features use the server in any way (and if they don’t, they probably should) make the server “authoritative” about them.

Imagine one of these features is causing a problem of some kind – any kind. Maybe a bug has slipped through and some clients keep crashing. Maybe this feature is being used much more heavily than anticipated and is generating problematic levels of load on the server. Either way, you want to be able to turn this feature off to prevent your players from growing frustrated and simply uninstalling the game.

One option is to quickly fix the problem, and release a new client build. This can take significant time – if you’re releasing through an app store, you will have to submit the new build, and wait for approval, before your fixes hit the app store. Even then, you have no real way of forcing players to install the update.

A much better option is to design your game from the ground up to allow features to be switched on and off by a simple configuration change made on the server. This avoids any delays waiting for your new client build to be signed off – because there is no new client build. Every client will download the new configuration from the server and disable the problematic feature. Once the problem is fixed, the feature can then be re-enabled just as quickly.

A simple pattern to implement this would be to define an Event (e.g. “GetFeatureConfig”). This has some cloud code which simply returns the enabled/disabled features:

By calling this event at appropriate points in you game (e.g. initial login, or the start of each level) your client can tell exactly which features should be disabled – in the example above, the “FreeGifts” feature should be disabled.

Enabling this feature is then as simple as editing the cloud code for this event, switching on/off the required features, and publishing that as a new snapshot to your live game.

Even if you think a feature is definitely never going to have a problem, why take the risk? A design pattern like the one above is trivial to implement.

Another good reason to implement this design is to support a gradual rollout of features, helping to keep players engaged. Maybe you write your game with 10 “bonus” features built in, but release it with all of these switched off. As time passes, your player base will inevitably start to decrease. Once you observe this occurring (using, for example, GameSparks’ analytics tools) you can switch on one of these features. This helps to prevent haemorrhaging of further players, since they now have a shiny new toy to play with. Additionally, you can tempt previous players back – by advertising the new feature, maybe with the aid of a push message campaign to inform all the players that haven’t logged on for a while about the new functionality.

Today we have discussed how implementing a server authority can help to deal with unexpected issues after launch, as well as improve player retention and engagement. In the second instalment of this series, we will look at some techniques to help you deal with performance issues, and poor network connectivity.

Read more from this series:

1. An introduction: Always be prepared
2. Don’t get chatty!
3. Be Specific
4. Test under load