Resolved Clarifications on Unity Netcode for GameObjects and Server Authoritative Concepts

Hello Unity Community,

I'm currently exploring Unity's netcode for GameObjects along with server authoritative concepts, particularly focusing on anti-cheating mechanisms. I've crafted a conceptual piece of code to illustrate my queries. Here it is for reference:

Code (CSharp):

1. public class UnitExample : NetworkBehaviour
2. {
3.    public event Action<Vector3> OnMove;
4.  
5.    [ServerRpc]
6.    private void MoveServerRPC(Vector3 position)
7.    {
8.        MoveLogic(position);
9.    }
10.  
11.    private void MoveLogic(Vector3 position)
12.    {
13.        _agent.SetDestination(position);
14.        OnMove?.Invoke(position);
15.    }
16. }

Based on this, I have several questions:

1. Compilation of ServerRpc for Client Builds: When building the game for a client, are elements like the internal logic of ServerRpc methods (e.g., the code inside MoveServerRpc) automatically excluded from compilation?
   
   
2. Reverse Engineering and Cheating Concerns: If the answer to the above is negative, does it open possibilities for cheaters to reverse-engineer the game code and execute server-side logic on the client? For instance, if a Unit has a networkTransform component, will any illegitimate movements be automatically reconciled using the server-calculated transform?
   
   
3. Safety of Public Events in ServerRpc Logic: Is it safe to use public event variables within ServerRpc logic? My concern is that public events might be more susceptible to external manipulation (injection).
   
4. Useful Patterns and Anti-Patterns: Are there any specific coding patterns or practices that are highly beneficial, or any common anti-patterns that should be avoided in the context of Unity's netcode for GameObjects?
   
5. Additional Clarifications: If there are any misconceptions in my understanding or explanation, I would greatly appreciate your insights to correct them.

Thank you in advance for your help and guidance!

 

1. Last time I heard: no. You'd have to #if them out, or use Fish-Net which provides this kind of stripping.
2. Yes to reverse-engineering but it may only save the hackers time if they can see the code, and thus do not have to deduce it from server response and changes to game state. Kinda yes to executing server-side logic on the client - it's just that hackers can inject any code they want anyway anywhere. It's entirely up to you and the server to verify client changes to game state, like teleportation.
3. Define "safe". Hackers don't care if a method or property is (used to be) public or private in C#. They work with the IL code respectively assembly if you use IL2CPP. If at all. It's a misconception that cheaters actually modify the executable. Most games simply prevent that by doing a CRC check on the client.exe - so any modifications happen in-memory or within the packets that get sent/received (packet sniffing).
4. Yes. In so far that given the questions you ask I would say you concern yourself too much with something that totally does not matter unless you have a successful game. Do that first, and then see where users cheat, and fix that. That'll save time and any anti-cheat you come up with now is not going to hit the target. Research the common do's and don'ts just to make sure you don't do anything really stupid, like leaving the server's database private key in the client exe.

Btw, we've had this discussion several times before. Having trivial server code in the client is not such a big deal and boils down to "security by obscurity". You only want to focus excluding code that is absolutely security critical, like credentials or critical algorithms that would allow things like exploiting economy loopholes or exposing other user's information or grieving.

All other behaviour clever hackers can deduce simply from the server responses and changes to game state.

Also: don't even think about creating two separate projects. The workflow would be very painful and time consuming.

 

Thanks to you, I now have a better overall understanding. I appreciate your kind response.