For FarmVille we sent the actions back to the server and then validated against game state there. It's the only real way to protect against cheating. However, if I were building the game again today, I'd just do what King does and have the client manage the state. It turns out that the set of people that would do this and the set of users that would convert into paying users has very little overlap. The overhead of managing state on the server is that you'd have to write your game logic twice (once in your client-side language and once server-side, though with a scripting language you may be able to avoid this). Second, we benchmarked this approach and found that you can handle 10x the number of players with the same hardware by not doing any server-side logic/validation and just having the server be a dumb pipe to store player state.

Here's a talk I gave on the FarmVille approach: http://www.slideshare.net/amittmahajan/rapidly-building-farm...

and one on the king approach that we're using at my current company: http://www.slideshare.net/amittmahajan/gdc-2013-ditching-the...

I guess the first question is: why prevent people from doing this?

In my opinion, with games like this the ultimate goal of the server is to make sure one person doesn't ruin someone else's fun. Seems fine to let them ruin their own fun.

For one, sanity checks (this level can't really be solved in two seconds, that score is too large, etc). For two, probably more signing of requests, but that's pretty easy to bypass too. You really shouldn't be able to get ten thousand of something when the most the game gives you is two or three per day, though.

I guess they did it this way because they don't care about people cheating, since pretty much only one person (me) will bother to do it, and it will have no benefit other than their friends being puzzled.

The best thing to do is basically to simulate the entire game for each player on the server side and verify every action the player does but this involves a lot more code and is also server intensive for many games.

There also things like signing each request and such but ultimately, the client can't be trusted and will always be able to cheat in some way (like automating clicks and actions via GUI scripting).

In one puzzle game I worked on, we recorded all the user's moves and sent them back to the server. Not too big for something like Candy Crush, and allows you to check the user actually played the game.

Of course, that doesn't stop the next obvious steps (implementing a full simulation, or controlling the game through the GUI), but neither of those can be stopped.

I'd think you'd want to make a signed hash of each request, so the server can verify it came untampered from the client.