I am currently making a game with randomly made levels, but I have an interest in making everyone play the same level in a daily challenge section, like Spelunky.

At first I thought about letting the clients decide the seed based on their date, but dates can be locally spoofed.

I have access to a parse.com free account, so I can execute code in the cloud and expect results back. So then I considered asking cloud code for a hash based on the current date, but this could be spoofed to play a different level while sending the server the score for THAT level instead of the daily one.

Then I thought of encrypting the date in the server and decrypting it on the client, but then this might be problematic if I used symmetrical encryption. So... maybe use assymetrical encryption?

Am I missing a simpler solution here? This feels like I'm overcomplicating myself, but I'm not sure. Is there a generally accepted solution for this kind of problem? I haven't found anything after googling for a good while.

  • \$\begingroup\$ Just to be clear: can your clients generate the daily level using a seed alone? \$\endgroup\$ Commented Jul 18, 2014 at 5:47
  • \$\begingroup\$ @congusbongus Yes, a seed is all they need. \$\endgroup\$
    – Kenji Kina
    Commented Jul 18, 2014 at 5:49

2 Answers 2


As long as the client can't be trusted, nothing will be secure short of a server-side solution. Following your example, even if you managed to transfer the seed securely, all the client has to do is to spoof the score being sent to the server.

If the client is secure, then strong symmetrical encryption should do the trick just fine. Asymmetrical is not necessary, as the server is assumed secure, so both passwords are safe.

If the client is not secure, then you're going to have to do cheat detection on the server. Hopefully you don't have to recreate the whole simulation to validate the score sent, and you can distill it to a few key areas that will be hard for a hacker to recreate if they played a different level. This will depend highly on your design. And note that if you're not using parse.com already, you can always have it serve as a middleman with the score server.

The good news is that you could add this cheat-detection step down the road if you find your client has been compromised. The key with cheat prevention is to put as much effort as necessary, but not more. If you expect rampant cheating, go all in, but if not, start with something simple, just send the key down from the server in plaintext, and see what happens. If that fails, then encrypt it. If that fails, then add server-side validation.


You could use a simpler approach using a hash and a validation algorithm.

Instead of encrypting and decrypting the date use the hash directly and apply a mechanism to make sure this hash is valid.
For instance the last 5 bits of the hash could be the sum of the bits of the rest of the hash. All hashes which don't oblige to this rule are generated by someone else. This way you can avoid brute force attacks to some extend.

Unless it is really needed though try not to complicate this.
Building the actual game should be your first priority.
Of course as Sergio said in his answer, if you can't trust the client nothing is safe in the long run.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .