Suggestion for optionally separating client and server code

Unity Engine
1

Hi,

currently, if using the new networking API we are mixing server code and client code in the same classes. It can be ok for simple scenarios, it can be even nice sometimes if you want to perform the same things on client and server, but when your code base grows it can become a mess. You can end up with some member variables/methods only being used on the client, some only on the server and so on.

What if we could optionally write the NetworkBehaviours as one client class and one server class even though they are the same behaviour?

They could be connected by an attribute on the server class [ServerBehaviour(ClientBehaviour = ClientClass)]. Cmd:s would be routed to the server class and RPCs to the client class. Or in the Editor there could be one client script and one serverscript chosen for the same component, although personally I think this could be hidden from the editor and just done in code.

SyncVars could be connected by attribute parameter [SyncVar(ClientVariable = “xxx”)] or just by using the same name in both classes.

There are partial classes in C# but I feel that is not good enough because it doesn’t completely separate the code, you could then accidently set a client only variable in the server code etc.

Also, with separate classes you could have the option not to include the server classes in client builds if you don’t want to distribute your server code to clients.

Of course this topic needs more thinking, this is just the base idea :slight_smile:

2

You could do this by relying solely on UNet messages for your communication, as you declare handlers specifically for the client or server. Then perhaps instead of using commands, your player object actions could fire off a message to be handled by whichever object on your server.

Alternatively you could stick with commands and syncvar hooks, but then on the server those methods actually fire events which your server-only scripts can latch on to.

Interesting to think about for sure.

2 Likes
3

Yes, that is correct l3fty, but then you are more on your own completely. I’m talking about something that is built in and easy to use.