The fact is that you can't do networking 100% safely.
However you can do some tricks to make it more safe.
The most secure way, which is also used by desktop games, is too let the server simulate. So the client only handles inputs and rendering. Unfortunately, this technique would require a lot of CPU power from the server, so that you can handle the amount of clients.
The second approach is to have some factors which are hard to find/hack, and which also determines if you have succeeded or not. Like in your example it is the position when the heart hits the princess. So you send the position of the heart, and lets the server validate it. This can easily be hacked, so to make this even better, you may create a random coordinate space to use when sending the position, and only use the local space to render the scene.
So, in other words you can't be safe, but you can try to prevent the most obvious attacks.
The fact is that you can't do networking 100% safely.
However you can do some tricks to make it more safe.
The most secure way, which is also used by desktop games, is too let the server simulate. So the client only handles inputs and rendering. Unfortunately, this technique would require a lot of CPU power from the server, so that you can handle the amount of clients.
The second approach is to have some factors which are hard to find/hack, and which also determines if you have succeeded or not. Like in your example it is the position when the heart hits the princess. So you send the position of the heart, and lets the server validate it. This can easily be hacked, so to make this even better, you may create a random coordinate space to use when sending the position, and only use the local space to render the scene.
So, in other words you can't be safe, but you can try to prevent the most obvious attacks.
Tanks for reply.
I thought about server simulation, but it's cost too much cpu for physics simulation as you‘v said.
the second approach is a good idea. I'll try it. thank you.
You should look into javascript minification and obfuscation. It will not completely remove the ability for people to cheat by looking at your source code, but it should deter the majority of hackers.
@metsfan - I don't think that Javascript minification or obfuscation will do much to prevent cheating (maybe make cheating a bit more fun and appealing to those who might do it anyway)
In general you can't, and you should probably focus your effort in making a compelling game rather than preventing cheating. People can cheat in many types of games, and mostly they don't (particularly if it's single-player).
It is not really any easier to cheat in a HTML5 / Javascript game than one written in C++ and distributed as a binary (or NaCl, for example). This is particularly true if some or most of it is compiled e.g. with Emscripten.
@metsfan - I don't think that Javascript minification or obfuscation will do much to prevent cheating (maybe make cheating a bit more fun and appealing to those who might do it anyway)
In general you can't, and you should probably focus your effort in making a compelling game rather than preventing cheating. People can cheat in many types of games, and mostly they don't (particularly if it's single-player).
It is not really any easier to cheat in a HTML5 / Javascript game than one written in C++ and distributed as a binary (or NaCl, for example). This is particularly true if some or most of it is compiled e.g. with Emscripten.
I respectfully disagree. I agree that some hackers will see the challenge as appealing, but obfuscation as a security technique has been proven a successful deterrent It will remove an entire class of hackers from wanting to hack your game. It's the same reason encryption algorithms use a cypher. Sure, a talented hacker with a lot of time on their hands could discover the cypher and crack the algorithm, but it will deter lower level hackers who dont have the skills to crack the cypher, and the hackers who dont feel like putting in the time to crack it. You cannot prevent 100% of all hacking, it's about staying 1 step ahead, and putting hurdles in their way.
In general you can't, and you should probably focus your effort in making a compelling game rather than preventing cheating. People can cheat in many types of games, and mostly they don't (particularly if it's single-player).
I'm often amazed over how willing some players are to "cheat", even if it just means getting a top position on some highscore list, and gives them no benefit at all, except possibly bragging rights to their friends. (who probably mostly will think he just is a douche anyway)
The problem is that if cheating is too rampant, it can also seriously hurt how enjoyable the game is for the rest of the players.
Of course it is significantly easier to crack a program where you get the full source code (as in html5), instead of just a compiled binary, even though the latter ofcourse do not stop the dedicated "cracker".
So I think putting at least some hurdles in the way is a good idea, specially if "cracking" otherwise would just mean to figure out what http-request to put in your browsers adress bar. It will significantly lower the number of successful attempts, hopefully to a level where it does not destroy the enjoyability for the people who are interested in actually playing the game.
One example of a way, is to send a bigger portion of the final game state to the server for validation, instead of just the achieved score.
Send some key data (like positions and velocities, simulation time spent, mouse clicks done, etc), and validate if they are within reasonable limits, maybe even compare them to previous validated highscores.
Bigger blocks of data is also a bit trickier to figure out.
Then add some obfuscation too
