Hacker News Reader

Comment by waterhouse | Hacker News Reader

Couldn't you synchronize the beginning states of the game on all computers (including their pseudo-random number generator states), and then the only data you'd need to pass around is user input (keypresses, mouse movements, and the exact times--at least down to the frame--at which they occurred)? Given the initial state, the PRNG data, and the user input, games are completely deterministic, aren't they?

It seems that could pose a security risk to extremely savvy users (as the game state includes things they shouldn't be able to see, like the opponent's units in Starcraft, and one might be able to make a program to inspect the state of the running game client), but I can imagine encryption and obfuscation dealing with that sort of problem with very little overhead.

View on HN

The problem with your scheme is that to update frame X correctly, I have to have all input for frame X, which is now 200ms ago. Meanwhile, I need to be presenting something to the user now. Prediction is basically a way to deal with the fact that you can't do what you're describing.

Also, don't underestimate your users. Encryption is irrelevant, they'll hack into your program's process space and read the stuff after you decrypt it, and obfuscation is at best problematic for the same reason. For a AAA-class game, assume all users have access to all data on the client at all times and you'll not be far wrong. Sort of how like in the encryption world we just assume that the attacker knows the algorithm already.

never trust the client. but let it do its thing and set it straight if it tries to stray.

Wrong perspective. If you ship too much information down to the client the user will use it to know things they shouldn't. Google "wallhack". The stream up to the server will bear no overt traces of cheating.

wallhack is something you can't get around, a user can always control how their graphics are displayed, hence you can't trust them. You either accept this or change the game.

You can make it harder to do (Blizzard's Warden, Valve's VAC) but people will get around any technical barrier you put up.

Fog of War (maphack) would be a more apt example, you only send the client what it is possible for them to see. Speed hacks are another that can be stopped, the client asks the server if it can move X units, the server responds with how many units the client moved.

I guess this is one of those "in theory, theory and practice are the same, in practice, they are not" kind of things. I don't know of any triple-A game engine that works that way, and it's not for a lack of smart people working on it. I'm sure that could work for a sufficiently simple game engine, however.

RTS often use that approach combined with check sums. They then resend world state when they don't match. However, FPS that use a little state prediction become much more complicated.

Ideally, FPS would run two versions of the game world, what happened, and what the players see, with more information being sent about what happened close to the player helping the version that players see be more accurate. And continuous updating of the version players see based on predictions from the "real" version of the game world. But, getting that working would be extremely demanding and reduce the games ability to do physics in real time etc.

PS: Game developers may be smart, but as a rule they have less experience than you might think. Short burn out cycles keep the industry from evolving.

Reply on news.ycombinator.com