"Never trust the client" is good advice for <i>every</i> kind of application. Clients are filthy liars.<p>Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you.<p>The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well.<p>Don't blindly slap whatever the client sends into a no-SQL database, then vomit it back out for queries.
Since 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.<p>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.<p>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.<p>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?<p>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)?
They 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.<p>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.<p>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.
another recent example of "never trust the client" is the amazon kindle unlimited debacle.<p>in case you missed it: the client syncs the last page read. so you can buy a book, jump to the last side and amazon marks it as read, without checking for intermediate states.<p>the problem is: amazon pays authors by "pages read". so people publish fake books with 3000 pages, let sweat shops try the book for free and just jump from the first to the last page, sync and it registers with "this customer read all 3k pages".<p>now create 20 fake author accounts and 30 fake reader accounts, publish 20 fake 3k books (one for each fake author account and they're practically filled with 3k pages of randomly scraped web content) and you got 20<i>30</i>3000 = 1.800.000 pages read.<p>if you are an aspiring author and publish a novella with, say, 50 pages and 10.000 readers devour every single page of it, you've got 500.000 pages read.<p>the faker can do this in a week and take about 4 times more than, even though it took you 2 months to write it. payouts are out of a pot shared between all authors. thus, authors lose in the short run (less money now), cheaters win big time (a lot money now), amazon doesn't lose money (now) because the payout is the same.<p>in the long run it's still problematic because small authors are unhappy once they realize what's afoot (and earn 1k instead of 10k). big name authors don't care as much if they earn 1m or 1.1m. customers aren't likely to buy the fake books anyway (cheaters take them offline before the free trial period ends) so they're not really affected.
The 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.<p>Case in point, it was recently discovered by the community that gear with the "Protection from Elites" bonus actually <i>increased damage taken</i> from Elites: <a href="https://reddit.com/r/thedivision/comments/4g6lnk/tested_confirmed_protection_from_elites_increases/" rel="nofollow">https://reddit.com/r/thedivision/comments/4g6lnk/tested_conf...</a><p>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 <i>made the game grindier</i> because people were hitting end-game content too fast. Which only punished people who did not hit the content yet.)
I'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.
I doubt that the developer's didn't know not to trust the client - they likely made a business decision.<p>I (used to a lot more) play Elite: Dangerous. A space sim that has multi-player. They made the decision to use (mostly) p2p/client networking to save money - they wouldn't need nearly as many servers. This has caused other issues in addition to cheating - a low limit on the number of players in the same "instance" of the universe for example.<p>But it was a business decision - imo the wrong one, but what do I matter?
How do we reconcile sentiments like "never trust the client" alongside this community's hope for decentralization, á la "The Internet Has Been Stolen From You. Take it Back Nonviolently"?
Obviously, this applies to all networked applications—not just games.<p>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?"<p>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.
Ubisoft appears to have some institutional problems. Their other recent Tom Clancy title, Rainbow Six Siege, is hands-down one of the most rewarding & intense shooters I've ever played, however it too is yet to realise its full potential due to amateur-hour quality issues and ongoing troubles with hackers.
Trusting the client, in essence, turns a game into one of your childhood: shouting matches of "I hit you!" "No you did!" "I totally did".
I think there's a false dichotomy here. You can't simply ignore the client, so no matter what, you have to have a set of server-side checks that ensure the client's inputs are valid.<p>Part of what this article offers is "you can't fix it by adding server-side checks", guessing that if they haven't done it already, it's impossible to do. I think it's entirely possible that their model is reasonable (takes movement, fire events, etc. instead of position, inventory, etc.), and they simply haven't guarded against malicious inputs. Adding server-side checks is _exactly_ what you need to do to make movement/firing inputs safe!<p>The existence of a certain class of bug doesn't mean the whole architecture is broken. It may simply mean they shipped the game without trying to detect cheaters. That may be a bad idea, but if the design is right, it's certainly fixable.
The server-side network model he describes here is the same architecture Meteor is designed with (see this page: <a href="https://www.meteor.com/why-meteor/features" rel="nofollow">https://www.meteor.com/why-meteor/features</a>). With Meteor, you get client side prediction and latency compensation (they call it "optimistic UI" now) for free. I've always been impressed they decided to build that, because I sure never would have myself. In fact the Meteor team has always said you need this kind of architecture in order to build true real-time applications. But I haven't seen other web-oriented platforms take a similar approach. Did the Meteor team just know something no one else has picked up on (despite it apparently being common practice in the games industry)? What gives?
One can easily observe this "server is the actual game" property in Minecraft when running on an underpowered server.<p>At home, Minecraft runs on my home server (with a small Athlon CPU) and it fails to keep up with the required speed of the game, so the server log will show messages like "server clock running behind, skipping 58 ticks" every so often.<p>An observable effect of this is that you have to hold the right mouse button just a little bit longer than the actual animation when eating stuff. And when you look at the sun, you will see it moving forward continuously (as calculated by the client), but skipping back a tiny bit every few seconds (when the client adjusts for the server's time drift).
I'll bet there was at least one developer who saw they were doing it wrong, and told them, and was overruled. I'd love to hear his/her account.
I thought it was a common sense to treat the client as merely the data representation and nothing else, sad to see that multi million dollar companies make rookie mistakes.
I'm surprised that "never trust the client" isn't among the basic concepts that everyone should know, at least on HN. It's such a basic premise.
now that i think about it - doesn't GTA5 suffer from the exact same problem? cheaters spawing tanks above people practically must be a client game state problem.
I 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!