4 ms·

Your post does nothing to explain why server side cheat detection is in such a poor state. "Don't trust user input" is a fundamental maxim in this industry. Wh

Your post does nothing to explain why server side cheat detection is in such a poor state. "Don't trust user input" is a fundamental maxim in this industry. When you log into your bank's website, does it do action validation on the client side or the server side? Every few weeks there's some security bug that boils down to the server trusting the client when they shouldn't. And hackernews comments correctly boil that down to the devs were lazy and/or incompetent. Games are no different. Sure, your industry has its own quirks and limitations. But trusting unverifiable user input... That's in the ten commandments, man.

dijit 6y ago
If I wasn't clear I apologise. Let me try to explain what I mean as simply as I can so that I can be sure I'm communicating what I want to say: Games are complex and ever more complex and costly each year. Verifying user input is expensive on the CPU of the remote side. Servers are expensive, people have indicated they want to run one: one of our servers costs more than my monthly salary every month. Double if it's in the cloud. So verification of the server side is not done for all things, some ray casting here and there for bullets, some bounds checks, but nothing like a defined absolute "you can _only_ do X,Y,Z" because that would be very very very expensive on CPU, because there's millions and billions of things you can do based on your current situation. And we have to trust that the actions you're sending that change your situation are true. So we start tracking movements every frame, updating your state on the server and then suddenly there's incoming damage. We can see that you got hit, but on your screen you were in cover? who decides? So now we have this exponential increase in "where people are" on the server, what is possible for them to do. Instead of just doing the raycasting on the bullet trajectory. (which is expensive, but not like "take 30s" expensive. Synchronising state amongst all clients 240 times per second is very difficult, in fact, I assume you know computer science so you tell me how easy distributed systems are without trust of anything. It's pretty difficult to have quorum here. Now do it for as many players as possible (say, 1.000), and you have 2 engineers for a year. Btw at the same time you need to make deployable health skills in-game, oh and support level design and also write AI for the NPCs (Civilian and 5 factions of combat). Making games is complex, obscenely so, and everything that's done is a hack on a hack on a hack. Frankly I'm surprised they work. To give context: we are roughly 10% of the engineering force that makes the browser dialog pop-ups on google.com. But we have code that is at least three orders of magnitude more complex and we had 2 years to make it.

dijit 6y ago

If I wasn't clear I apologise. Let me try to explain what I mean as simply as I can so that I can be sure I'm communicating what I want to say: Games are complex and ever more complex and costly each year. Verifying user input is expensive on the CPU of the remote side. Servers are expensive, people have indicated they want to run one: one of our servers costs more than my monthly salary every month. Double if it's in the cloud. So verification of the server side is not done for all things, some ray casting here and there for bullets, some bounds checks, but nothing like a defined absolute "you can _only_ do X,Y,Z" because that would be very very very expensive on CPU, because there's millions and billions of things you can do based on your current situation. And we have to trust that the actions you're sending that change your situation are true. So we start tracking movements every frame, updating your state on the server and then suddenly there's incoming damage. We can see that you got hit, but on your screen you were in cover? who decides? So now we have this exponential increase in "where people are" on the server, what is possible for them to do. Instead of just doing the raycasting on the bullet trajectory. (which is expensive, but not like "take 30s" expensive. Synchronising state amongst all clients 240 times per second is very difficult, in fact, I assume you know computer science so you tell me how easy distributed systems are without trust of anything. It's pretty difficult to have quorum here. Now do it for as many players as possible (say, 1.000), and you have 2 engineers for a year. Btw at the same time you need to make deployable health skills in-game, oh and support level design and also write AI for the NPCs (Civilian and 5 factions of combat). Making games is complex, obscenely so, and everything that's done is a hack on a hack on a hack. Frankly I'm surprised they work. To give context: we are roughly 10% of the engineering force that makes the browser dialog pop-ups on google.com. But we have code that is at least three orders of magnitude more complex and we had 2 years to make it.