我想创建一个无头服务器来处理我的多人游戏。这将更像是一个概念验证项目，但基本上我只想让多个玩家（比如说 3 个）来移动一个盒子。所以每个玩家都可以同时移动盒子（想象一个足球被多个玩家移动）。
现在我想知道我应该如何构建我的代码。我正在考虑为服务器创建一个单独的项目，我可以在 linux 服务器上无头运行，并为游戏本身创建另一个项目。服务器所做的只是将消息传递给盒子当前所在的位置以及是谁移动了它。
我是 Unity 新手，所以不确定这是否明智。或者我应该把服务器作为一个单独的场景放在同一个项目中？还是完全不同的方法？
【问题讨论】：
标签： networking unity3d server unity5
最近，Unity（再次）彻底改变了他们的实时多人游戏方法，它现在是“MLAPI”系统几年，直到他们再次完全改变它。
https://docs-multiplayer.unity3d.com
这篇非常老的文章只涉及拥有服务器/客户端的“三种方式”的抽象概念，所以，这是旧文章：
您提出了一个很好的问题。
(A) 有些人更喜欢在一个脚本中拥有两面。 （IE，只有一个项目。实际上每个 script 字面意思是“两件事都做”。）
(B) 有些人更喜欢两个脚本，但在一个项目中。因此应用程序启动，然后应用程序决定它是服务器还是客户端。
(C) 有些人更喜欢两个完全独立的项目。所以，一个项目是客户端，一个是服务器。
所以你必须在这三种方法之间做出选择。
关于“A”：
不幸的是，从 Unity 早期开始，网络上的大多数古老代码示例都是“A”形式。其中一些样本非常糟糕。
我发现方法“A”令人困惑且毫无意义。我看不出将这两个概念合二为一的任何目的。
关于“B”：
这也许是中型项目的必经之路。但是，应用程序必须从根本上知道如何将自己“拆分”为两个不同的应用程序。
B 比 C 更容易。他们只是启动应用程序。该应用程序会弄清楚如何表现。但是，B 对开发人员来说更难。
关于“C”：
如果系统与安全或交易有关，你会想要 C。一切都是 KISS，混淆的可能性较小。如果系统的两个部分自然更加不同，那么 C 是有意义的。
如果项目非常大，C 语言更容易，因为项目更加分散。它会让你更自然地形式化两者之间的通信协议等等。
C 是“永远正确的”。 B 可用于“部署便利”。当然，如果你只是做一个“hello world”测试，你可以做“A”，但它很混乱。
要对这个难题有进一步的看法，必须清楚地展示部署案例；即它是一款应用商店游戏，是一次性信息亭安装，工厂范围内的软件，还是其他任何情况。干杯
【讨论】：
跟进@Fattie 的回答，我确实遇到了第三个选项的问题。也就是说，为服务器和客户端创建单独的项目。
主要是，RPC 调用可能不起作用，因为新项目中的 rpc 方法签名会因程序集名称不同而不同（如在compatibility documentation)。
解决方法是复制您当前的项目以保持所有程序集名称不变，并重新设计您的项目以满足您的需求。
【讨论】：