LÖVE

Plu wrote:Just keep in mind that if you let the client send data to the server and then store it, it's still not safe. They could just fake a message saying they have a million points. The only way to make highscores actually safe is to run the game itself on the server (which is difficult). You can make it semi-safe by making it harder to cheat the scores, but really it's always possible to cheat unless the whole game runs on trusted hardware.

The decision of "running everything on the client, and just sending the highscore at the end" and "running everything on the server, calculating the highscore there" is not binary; it's a spectrum.

For example, you can send the score on each level, not just at the end. This simple measure allows you to do lots of validations on the server. If you know that a level takes at least 1:34 to complete (even with cheating), and your server receives a highscore in less than that, then that highscore is fake. Similarly, you can calculate the maximum score possible in a level. If the higscore is greater than that, then it's fake.

Or you could have a client just send its current score every minute. If you know your game's "opimum play grapth", then you can validate highscores easily.

My post here may be useful (I have no idea, tbh):
viewtopic.php?f=4&t=36952&start=10#p107647

IMHO, the best method would be to record a local replay from the player's input, and then send those input sequences to the server, which then validates the input by playing it back in-game. In order for this to work properly, you need to be sure of two things:

- If you are drawing any random numbers, make sure the random number generator is provided by your game and not something that is system/environment-dependent, that it is using the same random seed every time (or at least providing this seed to the server as part of the replay data), and that it isn't drawing random numbers outside of the game logic itself (i.e. don't draw from the same RNG when doing your drawing functions).
- Avoid variable timestep, and use fixed timestep only. When trying to reproduce game state through input sequence alone, you are extremely likely to get different results if "hold right for four frames" doesn't even place the player character in the same pixel location.

If you can't satisfy both bullet points, you could look at taking state snapshots every X frames, but this would make replays hard to verify (you're going to have to add in a ton of heuristics to determine things like... did this player jump higher than normal? And that stuff is prone to false positives).

Either way, you won't be immune to Tool Assisted Speedruns. At this point why bother trying to figure out if someone is "cheating" or not?

kikito wrote:Or you could have a client just send its current score every minute. If you know your game's "opimum play grapth", then you can validate highscores easily.

This would only prevent really blatant cheating. Not to mention the fact that it would be pretty hard to find the optimum play graph. A dedicated player could probably shave off half a second, and then get accused of cheating, and you don't want that!