4 ms·

At some point you have to trust the client. Invincibility cheats can be as simple as the client updating its position the moment it knows there is a projectile

At some point you have to trust the client. Invincibility cheats can be as simple as the client updating its position the moment it knows there is a projectile traveling towards it, or the moment another player is turned to face them they duck. For Counter Strike: Source for example the server sends the location, and way that a user is pointing to the client. With some calculations you can then draw a line from the other players to where their bullets would go if they fired. Using that knowledge you can find where your hitboxes are and simply make sure that you are never in the path of their line of sight! That is how wallhacks work as well, the client knows where the other players are so that sound can be properly calculated (so if they are further away and they fire their gun you hear less of a shooting sound and you hear a louder sound when they are closer). Healthpoints are generally stored server side (at least for the games I've been RE'ing for fun lately), but even then you can cheat, if you have portable med kits you can take at any time, as soon as you drop below a certain percentage you take one, now hack the client to have unlimited health kits and you are set. 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). The faster internet connections become the more feasible it is to have a client that just renders the result and have all of the computations done on a remote server somewhere. Kinda like RDP for games. But until the game companies then also put the servers close enough by the user and build the game experience to equalise between different ping times (something CS:S attempts to do but fails at quite well, thus allowing people with AWP's to kill people that are not even near where they were scoping due to timing delays) it is going to be a huge mess and gamers will hate it.

jiggy2011 14y ago
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?
- chousho 14y ago
  >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.
- pyre 14y ago
  > 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.
  - petepete 14y ago
    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.
bri3d 14y ago
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).
- icebraining 14y ago
  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.
  - Retric 14y ago
    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.
    - icebraining 14y ago
      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.
arohner 14y ago
> 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.
- deleted 14y ago
  [deleted]
- jiggy2011 14y ago
  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.
  - Hemospectrum 14y ago
    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.
feral 14y ago
>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 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/games/bernier.pdf http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...
- jiggy2011 14y ago
  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.
  - gms7777 14y ago
    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.
biot 14y ago
> 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://www.onlive.com/ http://en.wikipedia.org/wiki/OnLive http://en.wikipedia.org/wiki/OnLive
- X-Istence 14y ago
  Yes, and I have used it, and the user experience for fast/twitchy games is absolutely shit.

jiggy2011 14y ago

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?

chousho 14y ago
>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.
pyre 14y ago
> 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.
- petepete 14y ago
  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.

bri3d 14y ago

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).

icebraining 14y ago
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.
- Retric 14y ago
  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.
  - icebraining 14y ago
    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.

arohner 14y ago

> 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.

deleted 14y ago
[deleted]
jiggy2011 14y ago
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.
- Hemospectrum 14y ago
  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.

feral 14y ago

>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 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/games/bernier.pdf http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...

jiggy2011 14y ago
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.
- gms7777 14y ago
  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.

biot 14y ago

> 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://www.onlive.com/ http://en.wikipedia.org/wiki/OnLive http://en.wikipedia.org/wiki/OnLive

X-Istence 14y ago
Yes, and I have used it, and the user experience for fast/twitchy games is absolutely shit.