Separate server and client code

[Ryan089]

Summary

Currently SS3D allows for hosts (i.e. combined server / clients) and clients. It does not allow for dedicated servers. This is leading to some inefficiencies, bugs and diminished performance.

Goal

• [ ] Add ability to run SS3D in server-only mode.
• [ ] Remove ability to run SS3D in host mode.
• [ ] Refactor code to ensure that servers and clients are only running the code they need.
• [ ] Label all methods within NetworkBehaviours with either a [Client] or [Server] tag to aid identification

Potential Benefits

• Testing of new features will be more comprehensive. Currently different bugs may appear on host and client machines, so testing on a host may not identify client bugs.
• More efficient game loop processing. By removing the ability to host, we can eliminate the burden of any rendering / lighting / FOV on the server. This gives more server processing time to actually managing the game state.

Potential Drawbacks

• Developing code may become somewhat slower, because if you change the code you would need to rebuild the server rather than simply run the game inside Unity. (However, if you only changed client-side code, you shouldn't need to rebuild)

Note

This issue is not intended for implementation yet.

[Birlinha]

Potential Drawbacks

Developing code may become somewhat slower, because if you change the code you would need to rebuild the server rather than simply run the game inside Unity. (However, if you only changed client-side code, you shouldn't need to rebuild)

There could probably be a CI/CD solution created in a tool like CodePipeline, in AWS Or some similar local solution/script that would build the server on itself after updates, and create test units before deploy

[stilnat]

many methods in the project could use the mirrors tag [client] and [server], this would help to identify quickly which methods are running on the server and which are running on clients. It would also prevent contributors to try to call server only code from a client. A clear exception is returned if they try to do so.

[stilnat]

After some discussion, it's obvious that we need to do that at some point, but we're going to keep the current system for now because develloping is faster currently. I'll put it in the version just before pre-alpha.