Although there’s nothing wrong with common practice of using web based games to run competitions via the internet, the practice of using branded games to run competitions based on highest score is increasingly popular. What seems like a great idea is in fact anything but, here’s why.
The problem with doing this is the ease with which players can hack scoreboards in order to win prizes on offer. And obviously, the better the prizes the more likely you are inviting hackers. This applies to all web based games, irrespective of technology used to implement them. Whether it’s a Flash game, HTML5 game or Unity game, it’s possible to use some or all of the following methods to cheat and win prizes.
High Score Script Send Hacking
All web based games use server side storage to store global scoreboards that are common to all players. This is accomplished by having the game call a remote server-side script. The game sends the player’s score data to the server-side script, which then processes and stores qualifying scores into a server-side data file or database.
The problem with doing this is it’s easy for a player to intercept and change the data sent to the script. Or if they have the location of the scoreboard script they can fake the score submission, entirely independent of the game. This enables a player to add whatever score they want to the scoreboard.
Another extremely common method of cheating on web based games is to hack the score values in memory as the game is running. There are freely available programs designed to specifically do this. This makes it relatively easy for any player to locate and change current score values in memory as they play the game.
Hacking Timed Flash Games
This one is more specific to Flash games and means that it’s possible to manipulate games that score based on time achieved (e.g. fastest time wins) in order to win prizes. In order to explain how this works we need a bit of technical explanation.
There are two main ways that a developer may implement a game timer, which they choose will depend on the accuracy they need:
Tied into the main game loop
This is the least accurate method, with accuracy dependent on the game frame rate. E.g. a game running at 30 frames per second will allow a timer to be accurate to 1/30th of a second. This is fine for many types of games. Because the timer is locked into the game loop, if the game speeds up or slows down, the timer automatically speeds up or slows down accordingly. This method is preferable as it doesn’t allow for this method of cheating. However, where greater accuracy is required in a timed game (say you need accuracy to 100th of a second to differentiate player scores), another method is needed.
Tied into the computer’s internal clock
By using the internal clock of the player’s computer to power the game timer, a much greater degree of accuracy can be achieved. This can be necessary in fast paced racing games, for instance, where without this degree of accuracy there would be nothing to separate player’s scores.
The downside of doing it the second way is it makes the game timer independent of the main game loop and frame rate. So regardless of the speed the game runs at, the time is still locked to the same “real” time. This can open a game up to the possibility of cheating by manipulating the game frame rate. Software is readily available that allows the player to change the frame rate of a Flash game running on their computer. By using this, they can speed up a game, whilst having the game timer run at the same rate. This allows them to achieve any given game task much quicker relative to the game timer, hence being able to achieve a much better score than they would otherwise.
Combating Score Hacking
There are a number of ways experienced developers can help eliminate the chance of cheating to win prizes. In the case of script send hacking these can include checking submitted scores against a possible range (and throwing out impossible scores) and also using something called a cryptographic hash to verify that the score send came from the game itself. In the case of memory hacking, sensitive values, such as player scores, can be encrypted in memory to make it more difficult to locate the value to manipulate. None of these methods will make hacking impossible though, just deter casual hackers. If an experienced hacker wants to hack a game bad enough, they will.
When no prizes are at stake, hacking scoreboards really isn’t a problem. With no incentive to hack the game, players are far less likely to do so. Plus, there are limited security steps that can be taken to make it much more difficult for players to hack the scoreboard.
The problem comes when there are prizes at stake. The perception that it’s OK to run competitions in this way isn’t helped by the fact that clearly inexperienced developers are setting up these sorts of competitions on websites such as Facebook, only to have scoreboards hacked with unrealistic scores, in order to win the prizes. This doesn’t however mean you have to ditch the idea of a competition altogether.
There’s a simple solution. Run a free entry prize draw instead.
This gives you complete control of awarding prizes and entirely removes the incentive to hack, because the reward is no longer a guaranteed prize win. Overall, it’s a much safer solution that allows you to implement your competition without risking rendering it null and void by casual hackers.