Never trust the client
gafferongames.com
Never trust the client
1–10 of 155 posts
Re: Never trust the client
#2They 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 client.
Simple Newtonian physics based games(Subspace, etc) are famous for being latency tolerant since the simulation is incredibly deterministic and are based on the players extrapolating where things will be in X time rather than twitch responses(which is also why fighting games are so hard without using a solution like Counter-Strike). You could play SubSpace on a 500ms dial-up connection and still be competitive without needing to lead for lag.
Re: Never trust the client
#3Does anyone have a mirror for the "this is super bad" video?
Re: Never trust the client
#4I would think that in 2016 this should be something everybody knows....
Re: Never trust the client
#5The Division is an interesting game from a QA perspective. While client-side architecture is one thing, blocking bugs are present in the game and have been a strong deterrent to community stability.
Case in point, it was recently discovered by the community that gear with the "Protection from Elites" bonus actually increased damage taken from Elites: https://reddit.com/r/thedivision/comments/4g6lnk/tested_conf...
And that's not even getting into the loot quality issues and the complete lack of a carrot-on-a-stick that has been codified in many, many games. (Massive actually made the game grindier because people were hitting end-game content too fast. Which only punished people who did not hit the content yet.)
Re: Never trust the client
#6I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it, allowing for common and popular speed/pos hacks.
Re: Never trust the client
#7Since 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 the key.
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.
Do you try and rely on subtle math tricks that mean that certain score numbers are de-facto invalid because no combination of scores could end up with that as a final total?
Is there any way to handle the issue other than deleting scores that seem likely fake (large round numbers, for example, or those orders and orders of magnitude higher than other scores)?
Re: Never trust the client
#8I would think that in 2016 this should be something everybody knows....
Yeah, isn't this basically the first thing you learn in game networking?
Re: Never trust the client
#9If you don't know this you should not be working on software. It's a latent risk to customers.
Re: Never trust the client
#10Obviously, this applies to all networked applications—not just games.
It's embarrassing how often I see web apps which use something like Firebase with absolutely no validation or access control. Often the developers behind them don't even realize they have a problem. Their excuse is that "most users wouldn't have any reason to hack it, so why does it matter?"
Developers need to realize their clients are inherently in the hands of hackers. Any security needs to be done on the server if it is going to succeed at all.