Hacker News Reader

Comment by trjordan | Hacker News Reader

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.

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!

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.

View on HN

I think you might be misunderstanding the scope of an "input". It's something like "the player pressed the key/button that maps to move forward", not "move to position X". Teleport hacks wouldn't be possible in the former case because the player has to actually move their avatar to the desired position by traversing the game world through a series of inputs. The server would then process the movement inputs, and the avatar would say, bump into a wall, preventing it's movement. There would be no input for "my position is now X".

Is an input always valid? "Firing once" is an input: you have to validate that it's been long enough since last firing that you should act on it (limit the rate). "Moving left" is an input, but by how much? Can I send "Left, 9999999" and replicate a teleport hack by pre-calculating these inputs?

You could bound the inputs to a simple stream of enums (FIRE, LEFT, RIGHT, etc.), but it wouldn't be crazy to batch it up a little bit and send some magnitude data as well (FIRE 2, LEFT 50, etc.). It's a little harder to validate, but depending on the specifics of implementation, that could be a win.

"Moving left" is NOT an input. An input is "The controller is pushed to the left" (with perhaps a numeric value of how far it is pushed to the left). "Firing once" is similarly NOT an input. "The fire button is down" and "The fire button is up" are inputs. That is how well implemented first person shooters have worked since the Quake days (I think Quake 2 actually).

The point of the article is actually that the server doesn't validate anything. There's nothing to validate. The only data it gets from the client is the state of the controls. Then it runs the real simulation. The client only ran a prediction of what it thought the server would do. Sometimes, it's wrong and corrects itself when it gets new values from the server.

No, it's more like "move left" and you move left at your velocity (95, let's say) for that one frame. Next frame you can send any move, but it will only move you 95 spaces in that direction, no more.

It's the same as just holding down a button on your keyboard - the game engine moves you according to the rules. Now you're just transmitting the fact that the player is facing NW and sent a move left command. You're just running the game on the server like you would on the user's machine.

Conceptually it's actually simpler - you're just running the same thing on the server and sometimes backtrack in the client when the connection is laggy.

Another way to look at it: the game simulation runs in a certain number of frames per second. Each frame you send to the server the state of your input devices (holding left arrow key, left mouse button is clicked, etc) and this is translated to moving, firing weapons, etc according to the rules of the game.

You can't teleport hack by sending "left 9999" because your inputs only serve to tell the server what direction you want to move towards. Your maximum movement speed depends on the game rules and should not be under your control.

Reply on news.ycombinator.com