This article is the first in a series covering best practices when implementing live service games in ChilliConnect. In this article we look at the advantages and disadvantages of using a server authoritative approach vs a client authoritative approach.
You might have heard developers mention the terms “server authoritative” and “client authoritative” when discussing their game, but what do they mean exactly and how can this key design decision affect the time, cost and functionality of your game?
Imagine a game that allows players to perform a “wheel of fortune” spin once a day. In a client authoritative game, you could use the ChilliConnect Catalog to store a Metadata object containing a list of items and the players chance of winning each of them. The game would then download this definition from the Catalog and randomly select an item for the player to win. The players account could then be updated directly using the SetCurrencyBalance and AddInventoryItem API methods.
In a server authorative game, rather than trusting the client to make sure the the player has not already completed their spin for the day, you could create a ChilliConnect Cloud Code script to take the place of the game code. The script would load the Metadata item from the Catalog and award the player. You would also disable access to the SetCurrencyBalance and AddInventoryItem API methods and store the last time a player has completed the spin in Player Data – this would prevent the player from changing the local time on their device to get more spins.
This is simple example but outlines the main differences between thinking in server vs client authorative terms.
So why would you want to make your game server authoritative rather than client authorative? One of the main reasons for adopting a server authoritative model is to prevent players cheating. In live service games in particular, monetisation is often linked closely to progression and by using device level exploits to circumvent core game mechanics, players can gain immediate progression, improved performance or unlimited resources – often removing the need to make In App Purchases. In addition to preventing cheating, a server authoritative model can sometimes make it easier to modify game logic without the need to distribute new builds.
Rather than a simple binary choice between server authoritative and client authoritative, there are different levels of server authority that can be considered when designing and developing your game. Each have their own benefits and tradeoffs. Some common approaches are outlined below:
- Fully online server authorative. A fully server authorative game will enforce that every action taken by the player is validated by the server as it is taken. Fully server authoritative games like this usually force the player to be online to play.
- Delayed server authorative. Delayed server authoritative games also enforce that player actions are validated by the server but typically allows players to play offline then reconcile the changes to the player account when the player goes back online. This removes the need for the player to be online, but is more complex to implement and has the potential to generate errors.
- Partially server authorative games will enforce that one or two key mechanics (such as levelling up or unlocking content) are validated by the server. Some partially server authoritative games will also allow the player to play for a limited amount of time offline before requiring they reconnect.
- Passive server authoritative games implement server authoritative style checks in a way that does not obviously impact the player experience. For example, for games that use timers to generate currency might periodically fetch the time from a remote server and use that rather than trust the local device time.
- Fully client authoritative games perform no server checking and trust the players device.
So should you make your game server authorative or client authorative? In recent years, there has been a shift in attitudes towards how server authorative mobile games should be. Mobile games especially tend to target a much more casual audience than traditional online games on console and PC. The majority of players in casual mobile games do not have the time or inclination to attempt exploits – many players are happy to pick up their favourite game during downtime when commuting or watching TV for example. There is a school of thought that believes if such a small percentage of players are cheating in your game, and are unlikely to pay anyway, then it’s not worth the extra development time, cost and complexity to try and prevent those players from cheating. Is it also worth compromising the player experience (by enforcing your game to be always be online for example) for all players to try and prevent a small minority from cheating?
One notable counterpoint to these arguments are midcore games that use multiplayer as their primary retention mechanic. These types of games are generally marketed towards a technically more sophisticated audience, and widely available exploits have the potential to harm the integrity of the core multiplayer game. If players feel that they are losing games due to other players cheating it’s unlikely that they will return to play again, far less convert to paying customers.
It’s not an easy decision and there is no one size fits all solution. Our advice is to lean towards simplicity and a mostly client authoritative model if possible. The shorter development time and lower costs provide immediate benefits, whereas reduced complexity will make ongoing development easier in the live phase, but do bear in mind the following specific advice:
- Regardless of your genre of game, don’t get bogged down in technical details of making a game heavily server authorative too soon. Once you have soft launched your game and proven your KPIs, there will be time and justification to implement that functionality later, if you need it.
- Record metrics. If you have specific mechanics or features you are worried players might try to cheat or exploit, you can record metric events to capture when you think a player might be cheating – this will allow you to monitor general trends and decide if cheating is a problem for your game. General purpose metrics such as recording the total currency of a player at various points will also help you gauge whether cheating is a widespread issue in your game.
- Consider implementing passive server authorative checks in multiplayer games. For example, in a multiplayer game, whenever the data points to cheating player, you could mark that player by setting a flag using Player Data. You can then use this flag when matchmaking so that player is only matched with other marked players so the cheats don’t affect the vast majority of honest players.