What would it take to eliminate cheating in FPS?

[gorobei]

FPS games have well documented examples of aimbots, invulnerable, and weapons hacks. For each update to gamespy and VAC the coders can always find a new workaround.

but I would think defeating the xray, "see thru walls" hacks would be easier to solve since you have more control over the info sent from the server. The game client depends on the server to provide the locations of the other players. why not limit what they see to some z buffer or raycast of the first polygon hit by the camera?

Wiki indicates that it is easier/faster to send the entire world state of all the other players to the client than to limit the world state to the clients view or local zone. If you don't have to send all the values of the other players and all their projectiles not in the player's view to the client, wouldn't that reduce the amount of info/lag?

 

[AeroEngy]

Originally posted by: gorobei
...
Wiki indicates that it is easier/faster to send the entire world state of all the other players to the client than to limit the world state to the clients view or local zone. If you don't have to send all the values of the other players and all their projectiles not in the player's view to the client, wouldn't that reduce the amount of info/lag?

I am no expert in how online games work but my guess is that it would take more overhead for the host server to calculate each individuals "partial" world state.

So in your proposed method the server would have to calulate X-number(maybe 16 or more) of players unique world states depending on each users location and field of view. Then send all of those unique states to every person individually.

I think it is probably faster for the server to determine one global state and then send the same message/packet to everyone than calculating say 16 different states and route them to the appropriate user.

 

[CycloWizard]

The computation required by the server to implement your suggestion would be absolutely enormous. It could probably be achieved for a 1v1 game, but not 8v8 or more certainly.

If I were going to code something like this, I would have the client send the server two pieces of information: a position vector and a heading vector. The server would have access to such data for each player. These completely define the translation and facing of the person with only six pieces of data. Then, based on this data, the server could determine the field of view (since the viewing angle is known). It shouldn't be too difficult then (depending on the engine) to find obstacles within this field of view. Then, to find which one is the closest, simply calculate the distance. Then you send the position/heading vectors of any players within this FOV and in front of the nearest obstacle.

In practice, I think there would be considerable difficulties however. It would easily work in the old Counter-Strike, where obstacles and such are very well defined, but the computation requirements would still be very expensive. However, if you've ever played Delta Force (or similar game) with huge outdoor maps, this approach would be totally impractical.

 

[NanoStuff]

Even if or when such an idea could be implemented, it still doesn't exclude cheats such as lambert/colored models, no recoil hacks and various other client side exploits. Perhaps something like a continuous video stream and really intelligent server side heuristics would solve the problem.

 

[jagec]

It is worth noting that even if the entire GAME was server-side, modern computers are fast enough that a cheater could run some sort of image-recognition program coupled to the mouse driver for foolproof headshots. Basically, let the computer take over the hand-eye coordination task that the player ordinarily handles.

Right now the only way they do it is just by kicking those people who do suspiciously well, which isn't fair to the players who are just really good. My roommate used to get kicked all the time for "cheating". He wasn't...he was just very, very, very good. He would laugh when he killed you, too...the bastard.

 

[hellokeith]

I suspect within the next 3-5 years it will be commonplace for game servers to utilize add-in cards, such as GPU, Physics, AI, GPGPU, etc. An add-in card could achieve what you are asking.

I would like to see a PCI-Express X16 "game server" card, which handled all of the above tasks.

Client side hacks are more difficult to detect. You will basically need hardware level encryption on peripherals, and the game would only allow authorized devices' input. I think this is a good idea also and is needed, but most gamers have an uneducated negative knee-jerk reaction to any kind of encryption (copy protection, drm, etc).

 

[CycloWizard]

Originally posted by: jagec
It is worth noting that even if the entire GAME was server-side, modern computers are fast enough that a cheater could run some sort of image-recognition program coupled to the mouse driver for foolproof headshots. Basically, let the computer take over the hand-eye coordination task that the player ordinarily handles.

Running the sort of object recognition you're suggesting in real time is still not feasible. Object recognition is generally achieved by grouping edges based on some expected shape. To find the edges, intensity gradients need to be calculated for each pixel in the image. On my lab computer (which is very fast and has lots of RAM ), it takes about 3-5 seconds to find the edges from one still image and fit it with a simple curve (such as a circle or parabola) using MATLAB. MATLAB may not be the fastest option, but it is certainly not two orders of magnitude slower than the same thing running in C. At least, I hope it's not.

 

[gorobei]

Originally posted by: CycloWizard

Originally posted by: jagec
It is worth noting that even if the entire GAME was server-side, modern computers are fast enough that a cheater could run some sort of image-recognition program coupled to the mouse driver for foolproof headshots. Basically, let the computer take over the hand-eye coordination task that the player ordinarily handles.

Running the sort of object recognition you're suggesting in real time is still not feasible. Object recognition is generally achieved by grouping edges based on some expected shape. To find the edges, intensity gradients need to be calculated for each pixel in the image. On my lab computer (which is very fast and has lots of RAM ), it takes about 3-5 seconds to find the edges from one still image and fit it with a simple curve (such as a circle or parabola) using MATLAB. MATLAB may not be the fastest option, but it is certainly not two orders of magnitude slower than the same thing running in C. At least, I hope it's not.

I just watched some youtube videos of BF2 hacks. The newer ones don't even use image recognition, they're using the ingame deformation skeletons for the character models. No need to specify the pixels to target, just point at the bone(local matrix pivot) in the head.

Originally posted by: CycloWizard
The computation required by the server to implement your suggestion would be absolutely enormous. It could probably be achieved for a 1v1 game, but not 8v8 or more certainly.

If I were going to code something like this, I would have the client send the server two pieces of information: a position vector and a heading vector. The server would have access to such data for each player. These completely define the translation and facing of the person with only six pieces of data. Then, based on this data, the server could determine the field of view (since the viewing angle is known). It shouldn't be too difficult then (depending on the engine) to find obstacles within this field of view. Then, to find which one is the closest, simply calculate the distance. Then you send the position/heading vectors of any players within this FOV and in front of the nearest obstacle.

In practice, I think there would be considerable difficulties however. It would easily work in the old Counter-Strike, where obstacles and such are very well defined, but the computation requirements would still be very expensive. However, if you've ever played Delta Force (or similar game) with huge outdoor maps, this approach would be totally impractical.

Yes, but the client is all ready sending the two vectors in current games now I assume. So the server knows pos and aim, other than field of view(varies per monitor aspect ratio) wouldn't the server be able to calculate a raycast box at some 40 by 30(4:3) grid sampling and do a really simple test if there are ANY polygons inbetween the other players and the client vectors (I guess distance doesn't really matter). Then the server could prune all other player world states from the packets being sent.(test FOV, anything inbetween then don't send) Meaning some people would need 0 info/updates at times. Also the client now doesn't need to calculate the transforms, rotations, and deforms of all the bones in the other players models that aren't visible and in FOV. [You could then test for cheaters by sending false targets/playermodels to only suspect clients and see if they shoot]

_______________________

I ask this, because the next gen of FPS will likely have full destructibility and high level physics simulation. But since blowing up a building would create unique rubble and cover that would affect everybody, the server would have to handle the SIM instead of the client. Given the amount of secondary stuff flying around in any game with rockets or grenades, wouldn't this mean the real calculation load is going to have to shift to the server side? (At least in multi-player) So why not toss a few more chores to whatever quad/octo(?)core server is running the game?

 

[jagec]

Originally posted by: CycloWizard
Running the sort of object recognition you're suggesting in real time is still not feasible. Object recognition is generally achieved by grouping edges based on some expected shape. To find the edges, intensity gradients need to be calculated for each pixel in the image. On my lab computer (which is very fast and has lots of RAM ), it takes about 3-5 seconds to find the edges from one still image and fit it with a simple curve (such as a circle or parabola) using MATLAB. MATLAB may not be the fastest option, but it is certainly not two orders of magnitude slower than the same thing running in C. At least, I hope it's not.

Actually, I was talking to this code jockey about it, since we use image recognition in our lab too (it's a lot faster than the numbers you quote, but I think our setups are quite a bit different), and I did indeed come away with the impression that matlab was VASTLY slower than optimized, dedicated C++ code would be. I forget the details, but matlab's image recognition plugins in particular were extraordinarily poor compared to anything written in a real programming language. It was never really designed for real-time image recognition, it was just a framework for academics who knew a whole lot more math than programming to run models, and the functionality's just been extended more and more since then without significant changes to the core idea.

 

[Sureshot324]

Valve actually did this in the original counterstrike at one point. Wallhacks were still an advantage, because if you're hiding behind a corner and only one pixel of your body sticks out, the hacker sees your entire body. I'm not sure if they still do this in CS1 and doubt they do it in source. Like someone said before, this is relatively easy to implement in CS1 because of the simple level layouts.

In games with terrain like BF2, I know it is extremely difficult to calculate line-of-sight efficiently. I read an interview with the Ghost Recon developers and they mentioned this. In the single player of GRAW, the enemies will often be able to see you through hills/rocks, while other times they won't see you even through you're staring right into their faces. This would be unacceptable in a multiplayer game.

 

[Kntx]

<div class="FTQUOTE"><begin quote>Originally posted by: CycloWizard
<div class="FTQUOTE"><begin quote>Originally posted by: jagec
It is worth noting that even if the entire GAME was server-side, modern computers are fast enough that a cheater could run some sort of image-recognition program coupled to the mouse driver for foolproof headshots. Basically, let the computer take over the hand-eye coordination task that the player ordinarily handles.</end quote></div>
Running the sort of object recognition you're suggesting in real time is still not feasible. Object recognition is generally achieved by grouping edges based on some expected shape. To find the edges, intensity gradients need to be calculated for each pixel in the image. On my lab computer (which is very fast and has lots of RAM ), it takes about 3-5 seconds to find the edges from one still image and fit it with a simple curve (such as a circle or parabola) using MATLAB. MATLAB may not be the fastest option, but it is certainly not two orders of magnitude slower than the same thing running in C. At least, I hope it's not. </end quote></div>

Interestingly enough... that is exactly how some aimbots work right now. The difference is the method used to find the edges is not nearly as advanced, complete or accurate as the one used in MATLAB.

edit: grammer.

 

[xtknight]

Wallhacks can be prevented by not sending the client *all* data.

Aimbots are generally impossible to block since as said, the bitmap could just be analyzed in real time.