I would think that in 2016 this should be something everybody knows....
Yeah, isn't this basically the first thing you learn in game networking?
Or in any sort of networking work where you don't control both ends of a connection.
Never trust the client
41–50 of 155 posts
Re: Never trust the client
#42Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…
There are basically two low cost solutions that work well. A rolling window so your score is in the top X% out of the last 1,000 scores. People may still cheat, but doing so get's boring in the long term so most scores are real. Second validating some chunk of the game. So, for example with chess if you validate every move was valid, and then pick a few random moves and validate that's what your engine would pick. No…
> Another option is to more heavily validate higher scores, keep the top 0.5% honest and cheating to get a lower high score has less value.
That's one kind of thing I've thought about in the past. I'm thinking things like Game Center's global scoreboard, so if you only every check scores that are supposed to break the top 1000 then you don't have to bother checking everyone's games. If you fake a score of 270 points, well there isn't a huge benefit in stoping you.
Re: Never trust the client
#43Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…
> You could use this model of recording inputs and playing them back on the server but that seems like it would be a ton of work if your game is popular and an extraordinary cost for keeping a simple score board clean.
You only need to validate scores that would actually make it onto the leaderboard, which would be a tiny fraction of all plays. To avoid being overwhelmed by bad submissions, you flag users who send them as "don't even bother checking, just log and reject".
The real problem is RNG manipulation and TAS-ing in general. How do you to ensure a malicious user automatically can't brute force the whole tree of possible plays?
Re: Never trust the client
#44Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…
> You could use this model of recording inputs and playing them back on the server but that seems like it would be a ton of work if your game is popular
The main costs would be setting up servers / network serialization code, and isolating the game logic enough that you can reuse the same code on the client and server.
The latter is potentially useful for replay systems as well (so you can see how other top players are playing the game.)
> and an extraordinary cost for keeping a simple score board clean.
Some ways to keep costs down:
- Offload validation onto other clients (this is better suited for matchmaking based multiplayer games where you're communicating anyways, where it can be as simple as having both clients upload the score or result for a given match id - flag both clients when they disagree, whoever racks up flags consistently is cheating / has bad ram / ???)
- Only validate N% of the games from the event stream at random
- Only validate the top N% of scores from the event stream (who cares if people are cheating to give themselves terrible scores?)
Re: Never trust the client
#45Trusting the client, in essence, turns a game into one of your childhood: shouting matches of "I hit you!" "No you did!" "I totally did".
Re: Never trust the client
#46I was not interested in this game, but now knowing that it can be hacked in cool ways makes me interested. I only care about playing with friends, and this would allow for some super cool custom game modes. It's not a bug it's a feature!
Re: Never trust the client
#47The Division also uses TCP instead of UDP so they're clearly totally incompetent when it comes to networking.
Re: Never trust the client
#48Earlier quoted context omitted.
With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.
I think that is misinterpreting what the person you are replying to is saying. They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back" If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done. The idea of trust only comes into play if there is a…
Well, a bank website would want to use this to make sure nobody MITMs them, or that the client does not have malware, etc - which would affect the user.
Re: Never trust the client
#49Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…
If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify. This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step". It's also very common way to implement repl…
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
Re: Never trust the client
#50They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could have a latency of 200ms+ and have a reasonable experience. Also the common term for resolving these types of things on the client is called "dead-reckoning". You've always got a diverging states from latency so you're continuously trying to reconcile this on the…
There's something I always wondered about the gamestate rewind thing:
Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, which does not seem right...