Your opinion: Separate server-client architecture.

News & General Discussion
1

Greetings!

So just to also get beginners on the same page here:
In Unity networking is usually handled the following way. You make some object (lets say an NPC) and then it contains the code for both server and client side.
Then you can communicate through many different methods: Commands, RPC, SyncVars, and most importantly your own “game messages” (that is, inheriting from MessageBase).

Now it doesn’t really matter what kind of networking solution you use, that principle is pretty standard.
In fact, I was not able to find any networking solution/plugin/library/asset/ whatever you want to call it; that did not rely on this kind of behaviour (same class for client and server objects).

So while I was doing a review of my game and its general architecture recently, I realized that this setup is not really suitable for me, and that I’ll have to drop some concepts / parts that the high-level unity networking API (also known as HLAPI) offers.

To be more specific, I need to have separate classes for each “entity” in my game.
A player-character on the server would be “ServerCharacter : MonoBehaviour”, and on the client the same object would be represented by a “ClientCharacter : MonoBehaviour”.

The reason for this split - from simply “Character” which contains all code, to dedicated Server* and Client* classes - is that I want to have a clean project structure, and making use of the new AssemblyDefinition files in 2017.3.
And this split would make both individual objects more lightweight.
A “ServerCharacter” would not have to have a reference to “UIDisplay” or a “GetHoverCursor()” method.
And on the other side a “ClientCharacter” would not need an “OwningPlayer” property, and tons of other things… Each class would only care about the things it actually needs.

In fact, without this split it would be almost impossible to use AssemblyDefinition files.
How would you make a “Server.dll” and a “Client.dll” ? In which module would your “Character” class even go?

Most bigger games I know have a clear distinction between the server and client objects, and at most they share some common definitions for networking purposes.

Now dear community, do you think splitting up the game into components is worth the effort?
Does the way I think about this make sense to you?
Are there any assets or libraries around that would simplify the creation of a game with this kind of architecture?
What is your opinion on splitting things up like that?

2

The UNet HLAPI which uses Commands, RPCs, Syncvars, etc, is designed to be easy to develop with, easy and fast to learn, and fairly general purpose in that it can be used with a large array of game types. What you give up when using that is leanness and optimization to your specific game.

Instead you can use the UNet LLAPI and build your higher level networking architecture on top of that, purpose built for your game, and it should suit your needs probably better than the HLAPI. It is just more work you’re assigning yourself up front.

Here is an example of using the LLAPI to make a game:

Here is the LLAPI’s limited discussion in the manual:
https://docs.unity3d.com/Manual/UNetUsingTransport.html

I’m currently building a MMO using the HLAPI instead of the LLAPI after having weighed exactly these issues you mention. My game servers will be more bloated than necessary, as well as my game clients, and I’m not going to produce a Linux client because I am using the Linux build target pre-processor directive to keep much of the server code out of the Win/Mac clients. In the end I went with the HLAPI because I’m putting about 2 years into this thing as it is with little outside help, and I need to make hard decisions that allow me to keep that development time from further ballooning or I’ll never be able to get this thing done. Rolling my own high level networking API with all the features I would need would have probably added another 6 months or more in my early estimation. Not worth it for me, but it may be for you.