to learn some more and new techniques I've started building a little game. The idea is to keep expanding it and adding new things. It is a nice way for me to experiment and try out new techniques whilst also having something to play with.
Right now I have a base standing that works quite well. It is fully build in Vue.js. However right now everything is being handled client side. In the future I would like to use websockets to turn this into a multiplayer game. I get that it would be less than ideal to have the clients handle everything because cheating would be very easy to do. I was wondering what the best way to counter this would be. My game is somewhat like space invaders. A lot of enemies spawn and you have to shoot them.
Initially I thought of having all the game logic on a server and just have the client render things as the server dictates it to do. But how would this turn out with a high load? If 10000 players are playing at the same time this would mean an enormous amount of requests per second to the server. This would heavily impact the performance of the game I think.
What are the best practices when it comes to this? I would like to keep things as cheat proof as possible whilst also keeping a high load and well functioning game in mind. I have read that some games just use some form of obfuscation as to how a score is calculated but since mine is quite simple it seems that obfuscating it would not really work. I have included a screenshot of the current game to give you an idea of what I'm talking about.
You are the ship, the enemies are the yellow dots and spawn at the top. When they hit the bottom row you lose a life. When you lose 3 it is game over. My problem is that with many of these games running at the same time keeping track of all these enemies would become extremely difficult as there will be lots.
With kind regards.
First, TCP is not the way to go if you plan to have thousands of user to keep in sync, you have to go with UDP that is a far better protocol than TCP when dealing with multiplayer.
Second, you are right, the game engine must run also on the server and the server engine clock has to be ahead of players engine clock (maybe 200/500ms) in order to validate and forecast user input.
Then when you receive an input you can validate both the input at the time it was fired (your engine has already passed that gametime) and check the condition on the next 200/500ms making possible to reconcile the client state as needed.
Multiplayer data prevision and sync is hard take a look at the already available implementations like this or articles about this particular topic as this
Note: you'll find more help posting in https://gamedev.stackexchange.com/
I have used this html5 Snake game on my website , but problem is that it can be hacked so easily .
http://cssdeck.com/labs/classic-snake-game-with-html5-canvas
Hackers can inject scores and submit their own scores.
Is there anyway to protect score variable inside the script not to be injected by clients ?
Not as long as the game is implemented entirely on the client side. The "solution" is to implement the game rules and storage on the server side, and have the client be mostly UI, but this might be overkill for such a simple browser game.
You could make it harder by obfuscating the code, but that would only stop people who don't actually care.
If the game is deterministic you could keep a log of all game "events" and send that to the server, where the score would be calculated. This would make it more work to fake a score, but it would still be possible to fake, and it would also be a lot of work to build such a system.
I'm currently developing a game using JavaScript/JQuery. It's a simple brick breaker type of game keeping score, levels etc. I'm planning on implementing a leader board that users can submit their final score to. The only problem I see with this is users manipulating the score using developer tools on most browsers. I understand that keeping things server side will resolve most of these issues, however if there is a high volume of users, it will hit my server hard with requests. Cookies - Easily changed client side. I'm honestly out of logical ideas to promote fair game play because there is ALWAYS people who seek to cheat/become top of the leader board. With that said, what's an efficient and effective way to keep track of the user's score without giving them access to changing it?
Make the page submit a complete replay of the game rather than just the final score. Given the random seed and a frame by frame record of user inputs, your server should be able to simulate and reconstruct the game and verify the score.
Obviously the replay can be faked too, but it would amount to so much work (actually playing the game and actually getting a good score, albeit with the unfair advantage of AI assistance, slowing down and other client hacks) that tool-assisted scores should deserve to be in the leaderboard.
Obfuscate their score by creating an equation that can only be calculated on the server side.
Edit: RobG is correct in that it will need to be calculated on the client side.
I hacked the Angry Birds game when it launched on chrome:
http://wesbos.com/all-levels-html5-angry-birds/
However, they have since obfuscated the code so much that its impossible to figure out which function calculates the hash..
You can't guarantee no cheating, it's impossible. The server responds to requests, that's it. It has no idea what code is running on the client, what type of user agent or environment it's in or even whether it's running your code or a facsimile.
You can take various steps to make spoofing more difficult, but you can't make it impossible. The cost of such measures (usually seen as "security") is usually balanced with the value of the asset being protected.
An idea I had was to use a game-timer. If the user changes the score to an amount that is obviously not possible given the amount of time that has passed, refuse to log the information. You could start the timer and check the timer in your server-side script.
Now of course if they change the score only by a few points this checking may fail, but, if they only add a less than impacting amount then maybe it won't matter to you as much?
Never put anything on the client. The client is in the hands of the
enemy. Never ever ever forget this.
-- The Laws of Online World Design
You could also make the leaderboard less important, by only sharing scores with 'trusted' friends. Or simply allowing people to share their score on any social networking site.
Maybe this removes the primary motivation to cheat in the first place.
You could then always compare the score implicitly with statistics you gathered, to tell if somebody is doing good or not.
Base64 encode your javascript page. That should stop people some people.
Link: http://www.opinionatedgeek.com/dotnet/tools/base64encode/
Imagine a space shooter with a scrolling level. What methods are there for preventing a malicious player from modifying the game to their benefit? Things he could do that are hard to limit server-side is auto-aiming, peeking outside the visible area, speed hacking and other things.
What ways are there of preventing this? Assume that the server is any language and that the clients are connected via WebSocket.
Always assume that the code is 100% hackable. Think of ways to prevent a client completely rewritten (for the purposes of cheating) from cheating. These can be things such as methods for writing a secure game protocol, server-side detection, etc.
The server is king. Clients are hackable.
What you want to do is two things with your websocket.
Send game actions to the server and receive game state from the server.
You render the game state. and you send input to the server.
auto aiming - this one is hard to solve. You have to go for realism. If a user hits 10 headshots in 10ms then you kick him. Write a clever cheat detection algorithm.
peeking outside the visibile area - solved by only sending the visible area to each client
speeding hacking - solved by handling input correctly. You receive an event that user a moved forward and you control how fast he goes.
You can NOT solve these problems by minifying code. Code on the client is ONLY there to handle input and display output. ALL logic has to be done on the server.
You simply need to write server side validation . The only thing is that a game input is significantly harder to validate then form input due to complexity. It's the exact same thing you would do to make forms secure.
You need to be really careful with your "input is valid" detection though. You do not want to kick/ban highly skilled players from your game. It's very hard to hit the balance of too lax on bot detection and too strict on bot detection. The whole realm of bot detection is very hard overall. For example Quake had an auto aim detection that kicked legitedly skilled players back in the day.
As for stopping a bots from connecting to your websocket directly set up a seperate HTTP or HTTPS verification channel on your multiplayer game for added security. Use multiple Http/https/ws channels to validate a client as being "official", acting as some form of handshake. This will make connecting to the ws directly harder.
Example:
Think of a simple multiplayer game. A 2D room based racing game. Upto n users go on a flat 2D platformer map and race to get from A to B.
Let's say for arguments sake that you have a foolsafe system where there's a complex authetication going over a HTTPS channel so that users can not access your websocket channel directly and are forced to go through the browser. You might have a chrome extension that deals with the authentication and you force users to use that. This reduces the problem domain.
Your server is going to send all the visual data that the client needs to render the screen. You can not obscure this data away. No matter what you try a silled hacker can take your code and slow it down in the debugger editing it as he goes along until all he's left with is a primitive wrapper around your websocket. He let's you run the entire authentication but there is nothing you can do to stop him from stripping out any JavaScript you write from stopping him doing that. All you can achieve with that is limit the amount of hackers skilled enough of accessing your websocket.
So the hacker now has your websocket in a chrome sandbox. He sees the input. Of course your race course is dynamically and uniquely generated. If you had a set amount of them then the hacker could pre engineer the optimum race route. The data you send to visualise this map can be rendered faster then human interaction with your game and the optimum moves to win your racing game can be calculated and send to your server.
If you were to try and ban players who reacted too fast to your map data and call them bots then the hacker adjusts this and adds a delay. If you try and ban players who play too perfectly then the hacker adjusts this and plays less then perfect using random numbers. If you place traps in your map that only algorithmic bots fall into then they can be avoided by learning about them, through trial and error or a machine learning algorithm. There is nothing you can do to be absolutely secure.
You have only ONE option to absolutely avoid hackers. That is to build your own browser which cannot be hacked. Build the security mechanisms into the browser. Do not allow users to edit javascript at runtime in realtime.
At the server-side, there are 2 options:
1) Full server-side game
Each client sends their "actions" to the server. The server executes them and sends relevant data back. e.g. a ship wants to move north, the server calculates its new position and sends it back. The server also sends a list of visible ships (solving maphacks), etcetera.
2) Full client-side game
Each client still sends their actions to the server. But to reduce workload on the server, the server doesn't execute the actions but forwards them to all other clients. The clients then resolve all actions simultaneously. As a result, each client should end up with an identical game. Periodically, each client sends their absolute data (ship positions, etc.) to the server and the server checks if all client data is identical. Otherwise, the games are out of sync and someone must be hacking.
Disadvantage of the second method is that some hacks remain undetected: A maphack for example. A cheater could inject code so he sees everything, but still only sends the data he should normally be able to see to the server.
--
At the client-side, there is 1 option:
A javascript component that scans the game code to see if anything has been modified (e.g. code modified to render objects that aren't visible but send different validation data to the server).
Obviously, a hacker could easily disable this component. To fix that, you could force the client to periodically reload the component from the server (The server can check if the script file was requested by the user periodically). This introduces a new problem: the hacker simply periodically requests the component via AJAX but prevents it from running. To avoid that: have the component redownload itself, but a slightly modified version of itself.
For example: have the component be located at yoursite/cheatdetect.js?control=5.
The server will generate a slightly modified cheatdetect.js so that in the next iteration, cheatdetect.js?control=22 (for example) must be downloaded. If the control mechanism is sufficiently complicated, the hacker won't be able to predict which control number to request next, and cheatdetect.js must be executed in order to continue the game.
There's nothing you can really do to prevent anyone from modifying your JS or writing a GreaseMonkey script. However you can make it hard for them by minifying your script as well as making your code as cryptic as possible. Maybe even throwing in some fake methods or variables that do nothing but are used to throw an attacker off. But given enough time, none of these methods are completely foolproof, as once your code goes to the client, it is no longer yours.
The only way I can even think of implementing this is by modifying your Javascript to function as a client and then designing a central server mechanism to validate data sent from that client. This is probably a big change to implement and will most likely make your project more complex. However, as was said earlier, if the application runs entirely on the client, the client can pretty much do whatever they want with your script. The only way to secure it to use a trusted machine to handle validation.
They don't have to touch your client-side code -- they could just sniff and implement your Websocket protocol and write a tiny agent that pretends to be a human player.
Update: The problem has a few parts, and I don't have answers off the top of my head, but the various options could be evaluated with these questions in mind:
How far are you willing to go to prevent cheating? If you only care about casual cheating, how many barriers are enough to discourage the casual cheater? The intermediate Javascript programmer? A serious expert? Weighing this against the benefits of cheating, is there anything of real value at stake, like cash and prizes, or just reputation?
How do you get a high confidence that a human is providing inputs to your game? For example, with a good enough computer vision library I could model your game on a separate machine feed inputs to the computer pretending to be the mouse, but this has a high relative cost (not worth my time).
How can you create a chain of trust in your protocol such that knowledge of (2) can be passed to the server, and that your server is relatively confident your client code is sending the messages?
Sure many of the roadblocks you throw up can be side-stepped, but what is the cost to the player and you? See "Attrition warfare".
Some other methods that can be implemented:
Make the target elements difficult for a script to distinguish from other elements. Avoid divs with predictable class and id names if possible. Inject styling using JavaScript instead of using classes. Think like a hacker and make it hard on yourself.
Use decoys that a script will fire on. For instance, if the threat vector is a screen scraping algorithm using pixel colors, throw some common pixel colors in non-target elements. Hits on these non-targets could seem inconsequential to the cheater, but would be detectable. You don't want the cheater to know why you know.
Limit the minimum time between actions to slightly below the best human levels. The best players will hit that plateau, and it won't matter as much who's cheating, and immediately be able to detect anyone scripting faster than that by side-calling method calls.
Random number generators are typically uniform. Human nature is not. Likely a random number generator will have values within a set limit and even distribution. Natural distribution is a Gaussian curve. If you sampled the distribution and it looks like a square wave in the x and y axis, 100% it's a cheater. This will be fairly difficult for the cheater to detect the threshold for the algorithm because it's a derivative of the random, and not the random distribution itself. You're also using aggregate data and not individual plays to detect it, so reverse engineering the algorithm would be extremely difficult without knowing your detection algorithm.
Utilize entropy whenever possible. Avoid predictable game plays. Imagine a racing game on a set collection of race tracks. Each game play could have slightly differing levels of traction, horsepower, and momentum. The script would have to be extremely good to beat it. In a scrolling game, you can alter factors that are instinctual to humans, but difficult for computers, such as wind force, changes in gravity, etc. It would also make it more fun as a side benefit.
Server generated tokens can be used to validate UI elements were used and not calls to the code itself. Validation can be handled in one call at the end of the game comparing events to hashed codes of UI elements. The token should be a hash with a server private key and some value of the UI element.
Decoy the cheater with data they think you're using to detect cheats. Such as calls to a DetectCheat method with dummy calls to a fake backend. It's the old magician's trick. Wave your hand over here, while you slip a card into the deck with the other hand. Let them waste days on end in a maze that has no exit, with lot's of hair pulling.
I'd use a combination of minification and AJAX. If all of the functions and data aren't loaded into the page, it'd be more difficult to cheat.
On the other hand, modding turned out to be a very profitable tool for companies like Id Software. Perhaps allowing the system to be modded might make the game that much more enjoyable to the community at large.
Obfuscate your client exposed code as much as possible. Additionally, use some magic.
You can edit the javascript on the browser and make it work.
Some people suggest that make a call to check with the server. So after making a call to the server, it will be validated in the server. Once validated, it will come to client side and do actions. But I think even this is not foolproof.
For eg.,. for a Basic login action : in angular while making a call to server, the backend validates username & pwd and if validated, it will come back to the client and let the user login using angular.
When I say login using angular, it is going to store things in cookies, like user objects and other things. But still the user can remove the JS code which is making the call to backend, and return TRUE(wherever needed) and insert user object(dummy) to cookies and other objects(whatever needed) and login. It is a very difficult thing to do, but it is doable. In many scenarios, this is not desirable even if it takes hours to edit/hack the code.
This is possible in single page applications, where JS files dont get reloaded for each page. To mitigate the possibility of getting hacked we can use minified codes. And I guess if actions like this is done in backend(like login in Django) it is much safer.
Please correct me if I am wrong.
I'm finding lately how unsecure Javascript is when programming a game (I'm trying to do a turn based RPG and currently the battle calculations are done through Javascript which any player can cheat with of course giving themselves as much XP as they want), so I'm wondering if I were to move my battle screen to flash if this would be any more secure, or is there just as easy of a way to cheat this?
Come on. It's the same question really. Answer remains the same too:
No matter what the game, whether JS Flash or native binary, if the scoring system is vulnerable, people will tamper if the game is good enough. Stick to clever serverside every time.
This is not a problem that can be solved by obfuscation at the client end. There's plenty of prior art concerning keeping high-score tables/game data secure. Sharpen your google-fu and have a look.
Although the title of this post would suggest it's not applicable, I'd consider the difference between a browser/non-browser game to be irrelevant in this regard. As such, take a look:
Secure Online Highscore Lists for Non-Web Games
This is very slightly safer as flash source is harder to read then js source. However neither is particularly safe.
As I said in a previous answer, a secure system can not trust client score input. It doesn't matter whether the intended program is Flash or JavaScript. Once you send the program to the client they have any required key. So you can't rely on the client giving you accurate scores. The only reliable way to do it is to move score calculation to the server. Then, for a bot to play it still would have to calculate every movement manually.