Design and safety tips for leaderboard

Leaderboards play a crucial role in many online competitive games. Used properly, they can provide an incentive for players to get more involved with your game. Given this we wanted to see how we could use leaderboard properly for our cross platform mobile game - Platform Wars (available on Android, iOS and Windows Phone 8).

First a bit about the game itself. Platform Wars is a one on one PvP game with a sort of a realm vs realm metagame added on top of it. Each player is part of her or his “Platform”(based on mobile OS) and they fight against players of the other 2 opposing platforms. The results of these matches affect the relative positions of the platforms themselves.
 

In terms of leaderboard design we decided to go for 5 sets of rankings. First of all there are three leaderboards for ranking players within their Platforms. Then there is a global leaderboard for ranking players across the Platform divide. Finally we have a leaderboard (or rather a leaderboard view) that just displays the ranking of the player relative to their facebook friends, across all platforms.
 

Now to the reason for the article. It doesn’t matter if you have good leaderboard design if people can easily “hack” into the leaderboard and mess around with the values. Seeing unattainable ranks is not exactly a very good incentive for most players. So we wanted to design the game bottom-up in a manner that would minimize the chances of that happening, influencing the game design. The game design; being a multiplayer game; also influenced what we could do for the leaderboard. What follows is a brief summary of the effects of game design on leaderboards and the effects of our leaderboard choices on our game. Emphasis is on the decisions we took to make our leaderboards more secure  -
 

Logic on the Cloud :

Early on in the design phase we had decided to have the multiplayer component of our game on the cloud, as opposed to hosting a dedicated server. We went with Photon cloud for this. But this meant that we did not have an authoritative server so we be aware of the usual security problems with leaderboards (and frankly, everything else). If you have an authoritative server most of these problems go away since it is the server that decides who won, who lost and by how much.
 

We decided to use Shephertz’ App42 Cloud API for managing user profiles, leaderboards, etc. App42 also allows you to write custom backend code which opened up a number of security options for us.
 

Mandatory Login :

Platform Wars is a multiplayer experience. The single-player practice mode exists simply for practising. So we already knew that we would have people login via some means to access the game. Logging in means that we could maintain the user’s profile and have it synced across devices, and perhaps more importantly have the profile maintained even when the user does a clean install of the game. We used Facebook login since it is hassle free both for us and for the users. Since now all leaderboard values are linked to specific accounts it makes it easier for us to respond to hacking attempts. This should hopefully be a deterrent to some would-be hackers.
 

Limiting Client Access to Critical APIs :

One possible security concern with this system would be that a malicious user could find out the keys used to connect to App42 and then misuse them. Thankfully App42 allows us to create limited versions of the keys that only allow the client to call selected functions in the API. So we limited our client keys to calling the Custom Code API only. This means that the worst that a hacker can do is to call the limited functionality provided by our custom code.
 

Securing the Custom Code :

With all these decisions the weak point in our architecture would definitely be the server logic. First we made sure that we validate all client data. NoSQL is not prone to injection attacks in the way that standard SQL is but validating stuff can still help. One should not just make sure that the data is in the correct format but also that the values are as expected. Also, important decisions should not be left to the client-side code.
 

Calculate Ranks Server-Side :

We realize that this is not always possible as you might not have an authoritative server or your game might have a different scoring system. But when possible, these calculations should be carried out server-side. Many hacks happen because the client is dictating the user score to the server. That can allow users to get away with uploading unrealistic scores. We limited this in two ways. First, we don’t rank according to a “score”. Users are ranked according to how well they do in multiplayer on average, which is calculated from the number of wins and losses. Since there are two players in every match it allows us to compare the match-end report given by both, allowing us to validate every claim. The matches also cost currency, so even if a user is somehow able to generate a legitimate looking series of match requests they can only go so far.

Keeping all these things in mind, we were able to use available technology and services (Photon Realtime and App42) to implement a rather secure leaderboard.

To see our leaderboard in action you can download and play our game (available on Android, iOS and Windows Phone 8).