We get asked a lot by clients if we can incorporate a competition into a branded online game. This isn’t a problem in itself and obviously many clients want to use a competition as a way of increasing interest. What is a problem however is running competitions where prizes are given based on the highest scores (or other game outcomes) and this is usually what they want to do. It doesn’t help that clearly inexperienced developers are doing just that for their clients, so other people assume it’s ok.
Only yesterday I discovered another Facebook game that included a competition based on players’ scores. And as expected the scoreboard was full of scores that were impossible to attain in normal gameplay. This is the fundamental problem with doing this, players can cheat to win prizes and any experienced developer, quite frankly, should have known better.
I’m not going to go into too much of the technical side but I am going to explain the two main methods players use to cheat in order to win prizes.
It’s unfortunately unavoidable, although there are some limited precautions we can take to help prevent cheating, if players are determined enough they will get around them. And it goes without saying that the more worthwhile you make it for them (the bigger and better the prizes they can win), the more likely you are to attract some serious hacking attempts. For this reason we always strongly recommend to our clients not to base in-game competitions on high scores.
This is one of the most common method used to cheat, in order to win competition prizes. Global scoreboards have to be implemented by using a remote server-side script to send the score data to a data file or database.
If the player knows where this server side script resides (and it’s fairly easy to find out by checking the calls from the browser) they can fake the act of sending a new high score. So they can effectively add whatever score they want to the scoreboard, without having to even play at all.
Another method involves changing the score as it’s stored in memory, during runtime. There are freely available programs written specifically to do this. These types of hacks are generally how you end up with scoreboards full of impossibly high scores into tens or hundreds of millions.
There are limited methods to combat this. In the case of hacking the script call, verifying scores as they’re submitted and discarding impossibly high ones is one solution. This won’t stop people finding the limits of that range though and filling up the scoreboard with equal, highest possible scores in a attempt to win.
It’s also possible to use something called a cryptographic hash to send the data. This adds a basic level of security to the data you send, which means in order to cheat you’d need to crack the code first.
To help combat memory hacks, it’s also possible to apply some encryption to the score data in memory. These types of methods can make it much more difficult, but not impossible to hack and as I said before, make it worth their while and they will hack it.
It’s also worth mentioning that this isn’t something that’s technology specific whether your online game is Flash, HTML5 or something else, the risk of cheating to win competition prizes applies to all web based technologies. However, HTML5 is potentially the easiest to hack because the code is viewable by anyone with a web browser.
Cheating on Timed Games by Altering Frame Rate
This will involve a bit of techy explanation, so I’ll try to keep it as simple as possible.
Game timers can be implemented in one of two ways:
Tie It Into the Main Game Loop
This has the disadvantage of only having accuracy based on the frame rate. A game running at 30 frames per second (which is the frame rate we usually use) will be able to count the timer in steps of 1/30th second. This is usually fine (and preferable) for games where the timer just counts down a limited gameplay time, such as in a timed puzzle. Although this can cause it’s own problems (which I won’t go into here), the timer is not independent of frame rate. If the game slows down or speeds up, the timer slows down and speeds up with it.
Tie It Into the Computer Clock
This has the advantage of much greater accuracy, allowing timers accurate to thousandths of a second. If the player’s score is directly tied to the timer, e.g. a racing game where the quickest time is the highest score, this is usually essential. Without this sort of accuracy, there’s just not enough to separate the scores of players and you’d end up with too many players getting the exact same time. The problem with this though is the timer is independent of the frame rate, so regardless of whether the game runs at 30 frames per second or 60 frames per second the timer will run in the same “real” time.
This opens the opportunity to cheat to win prizes, if your competition is based on high scores. Programs are freely available that enable the player to change the frame rate of a game as they see fit. So, if for instance you have a timed race game, the player could potentially double the frame rate, which would make the race happen twice as fast, but the timer would still run the same as it would at the normal frame rate. This could allow the player to halve their time and get a much better score and was likely the exact method used to cheat on the Facebook competition I mentioned earlier.
Again verifying the times and throwing out impossibly fast ones before sending to the scoreboard is a partial solution, but not a particularly great one and certainly won’t prevent cheating altogether. Another possible solution (which I won’t go into too much) is using something called delta time in the main loop. This is used in lots of commercial games to get around variable frame rates (usually caused by hardware performance, or lack of it) but has a number of disadvantages for small scale retro/2D games.
Obviously none of these hacking issues are too much of a problem if there aren’t competition prizes at stake. With no incentive to “hack” to win a competition, players are far less likely to try and even if they do, there’s no harm done. Plus, any good developer should be aware of these issues (although in practice it seems very few are) and take appropriate, limited security steps to make it harder to cheat, as we always do.
The problem comes when prizes are at stake. But this doesn’t mean you have to ditch the idea of including a competition in your game altogether, there’s a simple solution. Don’t tie the awarding of prizes to scores achieved, or other game outcomes. Instead, run a free entry prize draw competition.
This gives you complete control over the awarding of competition prizes and removes the incentive to cheat, because the reward is only a chance to win a prize, not a guarantee they’ll win. You can also help combat obvious cheating through your terms and conditions, enabling you to put a limit on number of entries per person and exclude entirely players who might hack to gain many entries.
Overall, it’s a much safer solution and allows you to incorporate a competition in your game, without risking the whole thing being rendered null and void by casual hackers.