A server side anticheat experiment
Here are a few results from an anticheat experiment I've decided to run. It's a purely server side modification -- absolutely no change to the client is necessary for this functionality.
The server computes a player visibility mask on a per client basis. This visibility mask is used to de-scope (i.e. stop transmitting data about) player objects that the client cannot see. Players obscured by hills, or walls, or the visible distance fog are no longer transmitted.
This effectively neutralizes no-fog, per-IFF, and any related hacks.
I should emphasize that this still needs tuning, and it's just a proof of concept test. At the moment the visibility calculation is too aggressive about hiding things than it should be, but the concept holds pretty well. I also don't know how this will perform on a server the size of Goon Haven, or exactly how it will interact with objective type waypoints generated by the control circuit.
I've attached a few screenshots:
#1 shows the glut of data that the server sends to the client normally.
#2 is a zoomed in portion of the enemy base on Katabatic from the allied base. Positions of players that should definitely not be visible are being transmitted.
#3 shows what happens when this visibility masker is activated. I can only see the ally on the offensive.
#4 and #5 show how the hill obscures an enemy mortar heavy.
#6 and #7 show how flag carriers are placed into scope by nature of carrying a flag (which was specifically programmed).
If all goes well in the scale-up, this could be running on the public servers soon.
The server computes a player visibility mask on a per client basis. This visibility mask is used to de-scope (i.e. stop transmitting data about) player objects that the client cannot see. Players obscured by hills, or walls, or the visible distance fog are no longer transmitted.
This effectively neutralizes no-fog, per-IFF, and any related hacks.
I should emphasize that this still needs tuning, and it's just a proof of concept test. At the moment the visibility calculation is too aggressive about hiding things than it should be, but the concept holds pretty well. I also don't know how this will perform on a server the size of Goon Haven, or exactly how it will interact with objective type waypoints generated by the control circuit.
I've attached a few screenshots:
#1 shows the glut of data that the server sends to the client normally.
#2 is a zoomed in portion of the enemy base on Katabatic from the allied base. Positions of players that should definitely not be visible are being transmitted.
#3 shows what happens when this visibility masker is activated. I can only see the ally on the offensive.
#4 and #5 show how the hill obscures an enemy mortar heavy.
#6 and #7 show how flag carriers are placed into scope by nature of carrying a flag (which was specifically programmed).
If all goes well in the scale-up, this could be running on the public servers soon.
Comments
Sensor net support needs to be added, I wasn't going to try until after the initial tests worked out (which they have). The sensor manager in the game (which draws the circles in the control circuit, and controls the red/yellow/green indicator on the HUD), unfortunately, does not expose a way to see if an object is covered by the sensor net to the script system.
This means that I need to implement a new sensor manager. It won't be quite as drop-in usable as it is right now (since the sensor deploy code and destroy code will need to be modified), but there's no reason it can't be done. It's just an implementation of a standard point location algorithm, which is a well solved problem [persistent red-black trees guarantee O(log n) lookup time for n sensors].
Regarding the aggressive nature of the hiding, I plan to make visibility "sticky" -- only players that have been out of visibility for about 5 (maybe 10) cycles will be hidden. I also have a couple of math tricks that should improve accuracy when players are partially occluded by the terrain.
It all seems very doable. The only unanswered question is performance on a large server like Goons. Once the sensor net code and scope tuning code is in, I'm sure the Goon Haven staff would be happy to give it a spin.
So, bots are no problem.
More pressing matters are at hand. But apparently there are people working it, last i heard.
I need to implement the last handful of tricks to reduce the aggressiveness of the de-scoping code, but an alpha version should be suitable for testing tomorrow.
I also added 3rd person support. The server doesn't seem to get notification of 3rd person view so I'm forced to compute both first and third person visibility.
I had a little bit of difficulty in indoor battles, with enemies suddenly appearing, so I loosened LOS requirement for that case. With the less strict LOS, everything is normal.
I have one problem remaining with the sensor manager that still need to be resolved. It seems to do with the way I use a dummy object and datablock to calculate jamming fields -- after a map cycle players are randomly disconnected. I have a couple of ideas for resolving it; worst case, I remove the jam detection code from the first version while I figure it out.
There's still one minor feature left to add regarding control circuit access.
Other than the two above issues, the only big question left if performance will be acceptable on a large server.
After a bit of analysis, I discovered that the frequency of visibility mask computation was actually recomputing the same results two to three times, due to the fuzzy nature of the task scheduler.
Further, the update rate need not be so frequent. I specifically encoded partial "transparency" to the terrain and interior types knowing that updates are not run on a frame by frame basis. By tweaking these "transparency" parameters, it may be possible to reduce the number of computations to twice per second without affecting perceived quality of the mask.
At two visibility updates per second, I estimate the CPU max-out would occur at around 50 players. A handful of early-out visibility tricks could address another 20-30% of the raycasts, and perhaps bring 64 players into reach with acceptable mask quality.
Too bad T2 doesn't thread the script system.
[/random]