Hacker News Reader

>Keeping everything and all variables on the server is impossible, mainly due to lag the game would become unplayable, and due to having so many variables to calculate there is always something you have to trust the client with (position being the biggest one, you can't take all user input, send it to the server, and then send back where the character should now be).

Why not just take the user input from the client, and send it both to the model of the world on the server, and also to a non-authoritative model of the world on the client? The client is then immediately responsive, as the client model of the world is what is rendered, but if the model of the world on the client diverges from the model of the world on the server, the server overrules it.

This would ensure the client did not violate position rules, while still keeping it responsive, at the cost of an occasional noticable update when models get too far out of synch.

As far as I know many games have done this, since Quakeworld. I might be wrong, my knowledge is a little rusty?

Other issues remain that this doesn't solve (e.g. aimbot).

EDIT - Here's a wiki article this: http://en.wikipedia.org/wiki/Client-side_prediction which links to this article describing client side prediction in Half Life (so you can presume there is something at least as sophisticated in Source): http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...

The approach you have suggested is actually very similar to what is used in the THQ game "Supreme Commander". In this case they use a fairly P2P architecture and have clients exchange hashes of the game graph every so often and check that they match.

The problem with this is that the game needs to be fully deterministic and you'd be surprised how many games use random numbers to help determine outcomes like damage etc.

This can also cause problems when you have complex physics models, many physics engines are not deterministic and small changes between the ways that different CPUs deal with floating point numbers can cause the game to generate a completely different hash.

It seems as though the problem with determinism could be solved with random number seeding. If the server generates seeds, the two could stay synced even with random numbers.

The physics engine is a bit more difficult hurdle I suppose.

As gms7777 points out, for the RNG, surely you can just share seeds?

Your comment about the differences in how CPUs deal with floats is very interesting.

I found the following interesting comment, from a GPG employee, talking about how they take care to ensure their float math is deterministic:

"I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor."

http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p164...

Interesting link, feral.

For anyone else reading, I'd also suggest reading some of the followup posts such as this one: http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&...

> floating point math is deterministic.

This is news? Isn't this the entire point of the IEEE754 standard, to save us from the days when programs that were well-conditioned on a VAX would become numerically unstable on a Cray?

'Cray instability' sounds like a Star Trek episode but it is apparently something that could happen.

http://www.jargon.net/jargonfile/c/crayinstability.html

Depends on compiler options. x86 floating point is 80-bit internally, but 64-bit in memory. Compile the same function with different optimization, for a different CPU, or whatever and get different answers. For gcc, the answer is to use -ffloat-store. But you have to remember to use it.

> At some point you have to trust the client.

I'm not convinced of this, and the general trend of every online game that cares about cheating since at least QuakeWorld (1996) is moving in the direction of not trusting the client for important things.

> Keeping everything and all variables on the server is impossible

True, but you can get quite far by only giving the client the information they're supposed to have. Wallhacks were originally possible in Quake because pre-QW, the client received the position of every player on the map.

The strongest way to prevent wallhacks is to only tell the client about other players they should be able to see. The id and valve engines do this, for the most part. Again, quakeworld in 1996 severely curtailed wallhacking by only showing the users players that were visible, or "almost visible", i.e. near corners.

Your example of infinite health packs is something that could be trivially tracked on the server side and is, even for games as big as WoW. WoW tracks the current inventory of every single player in game. You can tell because sometimes when there are server glitches, you're unable to pick up loot from dead monsters.

The reason that the client may need to know about other players locations when they are not visible is sound.

You can hear somebody moving on the other side of the wall to you and for the sound to be realistic it needs to be played at the correct volume level determined by distance etc.

This isn't a big issue in some games , because you can just make peoples movements silent (of course there is still weapon sounds). However other games (like CS) have a stealth element where you need to make a tradeoff between moving quickly and noisily or slowly and silently so the sound is a big part of that.

Sound sources can be anonymized, though. If the source of a given sound is on the other side of a wall, the player can't see who it is, and the client doesn't need to know.

I'd go so far as to not even notify the client about sounds that are too quiet and far away for the player to be able to hear in the first place. Calculating echoes on the server and having the client treat them as separate "original" sound sources should also help somewhat.

Even if you don't know who it is, knowing that someone is around the other side of the wall is a huge advantage in an FPS game. Also players tend to have their teammates displayed on a map, so the cheat program could take this into account and mark as friend or foe.

Pushing this info to the client early also allows the program to make sure all the required assets are loaded into memory before it has to be rendered.

You could stream sound from the server, but latency might be an issue.

It's an interesting point about updating movement automatically to avoid a bullet. I did consider this possibility before, however I assumed that this would not give you full invincibility because if you are standing in an area and bullets are being fired all around you it may not be possible to move to a position where there is not an incoming bullet in time. Although even with this you could still gain a significant advantage.

Also a lot of older games would mainly use a hitscan model for bullet collision detection. The projectile itself was not modelled, instead there was a ray intersection test done at the time the bullet was fired so there was no "movement" for the bullet so to speak. Do most modern games now use a physics engine to simulate every bullet instead?

>if you are standing in an area and bullets are being fired all around you it may not be possible to move to a position where there is not an incoming bullet in time. A really good program would then be able to recreate Gun Fu from Equilibrium, or Neo and Agent Smith.

  > Do most modern games now use a physics engine to
  > simulate every bullet instead?

It might depend on the game, but as the parent suggested, the cheat could just avoid 'line-of-sight' with the barrels of the opponents guns, though those movements might become more obviously mechanical to other players.

The only 'games' I'm aware of that do are the ArmA series (the first Operation Flashpoint included). As to whether or not they're strictly games (or a set of missions and set pieces set within a military simulator) is another question.

Keep in mind there's another balanced approach: trust the client instantaneously and back-check the game asynchronously. Record replays of every game and re-simulate them using trusted client and server, and note any discrepancies.

Then, one could even have a limited set of extremely beefy full-game simulation machines that run in lockstep against a certain sampling of active game sessions (like 10%), banning a large enough subset of cheaters in real-time to ensure player confidence in the game's anti-cheating system.

I think some recent AAA titles work this way, although I'm not 100% positive as I have no insight into the server end of their systems (and what I observe as automated asynchronous cheating detection could be a vast number of human observers as well).

That only prevents impossible actions, like teleporting or such, but that's already not feasible with most games, since the server double-checks those. The hard thing is knowing whether a certain sequence of actions was done by a player or by an All-Knowing cheat doing it for them.

Another option is to send false information to a client. So someone using a wall hack might see 7 people on the other side of the door and or players only get shown in their correct location when it's possible for someone to actually interact with them.

You can't really do that in many FPSs nowadays because you can interact with others even without seeing them; for example on Call of Duty 4 (2007), you can shoot and hit people through most opaque walls, and you get feedback from hits. So if the server were to put fake players behind walls or doors and a player just happened to shoot it, the game would provide false feedback.

  > Keeping everything and all variables on the server is impossible [...]
  > Kinda like RDP for games.

Are you familiar with OnLive?

http://www.onlive.com/

http://en.wikipedia.org/wiki/OnLive

Yes, and I have used it, and the user experience for fast/twitchy games is absolutely shit.