Create separate Unity project for headless server

Question

I want to create a headless server that handles my multiplayer game. This will be more a proof-of-concept project, but basically I just want to have multiple players (lets say 3) to move a box around. So every player can move the box at the same time (imagine a football being moved around by multiple players).

Now I'm wondering how I should structure my code. I was thinking to have a separate project for the server, which I can run headless on a linux server, and another project for the game itself. All the server does is pass messages around where the box currently is and who moved it.

I'm new to Unity, so not sure if this is wise. Or should I put the server as a separate scene in the same project? Or a different approach altogether?

Answer 1

Note, Unity mmp "MLAPI" in the 2020s:

Recently Unity have (yet again) completely changed their approach to realtime multiplayer, it's the "MLAPI" system now for a few years until they totally change it again.

https://docs-multiplayer.unity3d.com

This very old article deals only with the abstract concept of the "three ways" to have server/clients, so, here's the old article:

You've hit on a great question.

Here are the three possibilities:

(A) Some prefer to have both sides in the one script. (IE, there is only the one project. And indeed each script literally "does both things".)

(B) Some prefer to have two scripts, but in the one project. So the app launches, and then, the app then decides whether it is a server or client.

(C) Some prefer to have two utterly separate projects. So, one project is the client and one is the server.

So you have to decide between the three approaches.

Regarding "A":

1. Unfortunately most of the ancient code samples on the web, from the the early days of Unity, are of form "A". Some of these samples are extremely bad.

2. I find approach "A" confusing and pointless. I cannot see any purpose in combining the two concepts in to one.

Regarding "B":

1. This is maybe the way to go for medium-size projects. However, the app has to fundamentally know how to "split itself" in to two distinct apps.

2. B is easier than C for the people deploying the app. They just launch the app. The app figures out how to behave. But, B is harder for the developers.

Regarding "C":

1. If the system is something to do with security or transactions, you'll want C. Everything is KISS and there is less chance of confusion. If the two parts of the system are naturally more different, C makes sense.

2. If the project is very large C is easier since the project is more broken-up. It will make you more naturally formalize the communications protocol between the two, etc etc.

C is "always correct". B can be useful for "deployment convenience". And sure, if you're just making a "hello world" test, you can do "A", but it is very confusing.

---

To get a further opinion on this difficult question, one would have to clearly present the deployment case; i.e. is it an app store game, is it a one-off kiosk installation, factory-wide software, or whatever the case may be. Cheers