Any resources regarding hack prevention?

[ghost]

From Unite LA 2018 talk, the developers of FPSSample claim that they tried to remove hacks.

Could you elaborate more on this?

I want to know whether there are some references that describes your design choices for cheat prevention.

[AnthonyB28]

It's designed to be server authoritative and "semi" deterministic in the sense that the client only predicts what will happen for him/herself in the world. If the server decides something different happened, the client will receive the corrected world state and snap back to it. The client is always rolling back even when it predicts correctly too.

The player is only ever sending commands to the server (I pressed this button, moving in this direction). The client is never telling the server "this is my ammo or health". So if the player tries to cheat by modifying their ammo count or health or something in memory, the server's world state will override it on the next snapshot received and client rollback to it.

[ghost]

Thanks for your information. It seems that the genuine world state is stored in the server and the clients are receiving snapshots (or delta) to reconstruct their own copy of the world. Plus , in case of discrepancy, the server will always win.

I think this is some what similar to quite old games such as quake2, especially with a dedicated server. Are there some notable advances compared to old games that also run on dedicated servers?

[ArnaudValensi]

I cannot speak for Quake 2 but I know the Quake 3 code base which is kind of an improvement of the Quake 2 code base. Quake 3 and FPSSample all have client prediction for the character you control, client side interpolation for the players you do not control and client side extrapolation for things like rockets. What FPSSample does that Quake 3 don’t is the lag compensation which is allowed by the way how frames and packets are synchronized using ticks.

One of the biggest issues with the Quake 3 netcode model is that you had to shoot forward the player you want to aim. Higher was the enemy ping, more you had to lead the shot. Players with the worst ping were advantaged, because it was harder to predict their position as the server view it.

The netcode model in FPSSample fix that, so if you aim the head, you'll get it, but the drawback is that you can receive damage while you were not in view of anybody.

If you want some precision about the concepts of interpolation, extrapolation and lag compensation you can find it here :

• https://www.gabrielgambetta.com/entity-interpolation.html
• https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
• https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
• https://www.youtube.com/watch?v=k6JTaFE7SYI
• https://www.youtube.com/watch?v=W3aieHjyNvw

And if you are interested in the Quake 3 source code, a good introduction is the following link https://fabiensanglard.net/quake3/

[ghost]

Thanks, @ArnaudValensi for your detailed explanation and providing me with additional resources!

Is there any issues with wallhacks? Like how FPSSample defeats it?

For example, does it perform kinda precise visibility testing on the server-side to restrict the information being sent to the client? (e.g. enemy’s location)

[ArnaudValensi]

Snapshots for entities are generated here ReplicatedEntityCollection.cs#L245

All entities seems to be sent to the client, so no, I don't think any mechanism to avoid wallhack is implemented here.