Speaking on stage at last week's Unite Europe 2015 conference in Amsterdam, Bill Robinson and Simon Watmough of London-based Space Ape Games shared some tips for developers attempting to coordinate and manage games-as-a-service.

The studio has experienced GaaS development twice over with Samurai Siege and Rival Kingdoms, and one of the biggest issues it has encountered is hacking.

Besieged

“We have two main types of hacking, says Watmough.

“We have forged platform receipts, which is where a hacker is sending you a receipt for, say, the App Store and trying to trick your servers into thinking that they've bought something they haven't paid for.”

“These aren't actually that big a deal, so long as you're following the documentation from Apple and Google you can detect them fairly simply... but we do get a massive volume of them, and people just love trying their luck.”

“The second kind, however - memory hacking - is a much bigger problem,” he warns.

“The basic premise is that the hacker loads your game inside their tool, they go search for the number of diamonds they have, and then they can just go and change it to whatever they want - like, 12 million - and now they never have to spend any money.”

“These do require jailbroken and rooted devices,” he adds, “but that's no big deal anymore.”

“Say I start up my hacking tool, I get into a battle, and I hack the health of a samurai from 12 to 12 million - so now my one samurai just cleans up an entire base and I win. The server isn't capable of simulating the entire battle [due to code complications] and so it just has to trust the client.”

This kind of foul play, if not addressed, can lead to frustration and the loss of player immersion.

“So it'll put a loss on the account of the victim, take some rewards away, and when the victim logs on next he'll see that he was defeated,” Watmough goes on.

“But when he checks the replay it'll all be out of sync... and players hate this kind of inconsistency, it undermines the whole of the game.”

“The initial approach we took on Samurai Siege was to essentially hash attack brain data, so we would look at replays and identify which properties were being hacked by players, put in defences for them, and then release those builds into the wild.”

“But the entire thing would rinse and repeat and we'd get into a bit of an arms race, constantly having to be releasing, and that goes against our games-as-a-service intentions.”

Hashing is imperfect in other ways, too - it relies on what Watmough refers to “security through obscurity,” and is weak against more advanced hacking methods.

Fighting back

Moving onto how these issues were addressed in Rival Kingdoms, Bill Robinson takes over.

“With development for Rival Kingdoms this was something else we had a chance to improve on, so really the best way to detect these problems is to fully validate the battle on the server,” he says.

However, the same issue as in Samurai Siege reared its head - unifying the two languages was impractical, rewriting the server architecture in C# deemed “infeasible” while rewriting the battle engine in Scala would be “too expensive.”

“So we thought, how about we just wrap [the battle engine] up in its own little micro-service, in a C# mono runtime, and let's just use that for validating battles.”

This micro-service was described as having “minimal responsibility,” with only three functions to perform: it receives battle input, runs battle, and sends results back.

“The client would generate this [battle validation log]... and then the server that's generating these battles also generates it, and that gives us the ability to just look at it in a file differencing tool whenever we flag up that there's a problem.”

“We can really dig down and analyse what's gone on in the battle, and this has really helped us.”

For a more detailed account of Space Ape's hacking-prevention techniques, along with other tips and insights for GaaS developers, the full talk is available to watch on YouTube.