为无头服务器创建单独的Unity项目

Question

我想创建一个无头服务器来处理我的多人游戏。这将是一个更多的概念验证项目，但基本上我只想让多个玩家（比方说3）移动一个盒子。因此，每个玩家都可以同时移动盒子（想象一下足球被多个玩家移动）。

现在我想知道我应该如何构建我的代码。我正在考虑为服务器设置一个单独的项目，我可以在Linux服务器上运行，而另一个项目则用于游戏本身。所有服务器都会在当前框所在的位置传递消息并移动它。

我是Unity的新手，所以不确定这是否明智。或者我应该将服务器作为单独的场景放在同一个项目中？还是一个完全不同的方法？

Answer 1

你遇到了一个很好的问题。

Here are the three possibilities:

（A）有些人喜欢在一个脚本中有双方。 （显然在同一个项目中。）

（B）有些人喜欢有两个脚本，但在一个项目中。所以应用程序启动，然后应用程序决定它是服务器还是客户端。

（C）有些人更喜欢有两个完全独立的项目。因此，一个项目是客户端，一个是服务器。

关于三者的一些重要事实：

所以你必须在三种方法之间做出决定。

关于“A”：

1. 从Unity早期开始，许多代码样本都悬挂在网络上，恰好是“A”形式。随着岁月的流逝，这变得不那么真实了，但总的来说，“在www上铺设旧的Unity代码”一般都是危险的。
2. （实际上，正是出于这个原因，许多初学者程序员学会了使用Unity进行整体编程并在网络上查找Unity片段，认为或认为您“必须使用”方法A.）
3. 请注意，着名的Unity大部分示例代码都非常愚蠢。实际上，您看到的网络样本通常就是一个很好的例子。
4. 我个人认为方法“A”非常混乱，毫无意义。事实上，多年来我一直试图看到它的优势所在。我能想到的唯一优势是：它节省了驱动器空间。因此，您可以拥有一个 - 而不是拥有两个脚本 - 这可以节省驱动器上超过KB的空间。在将这两个概念合二为一时，我自己也看不出任何其他目的。

关于“B”：

1. 这可能是中型项目的方法。这里的缺点是应用程序必须从根本上知道将自己分成两个不同的应用程序。
2. 如果部署很重要，如果它必须是“GI证明”，B比C更容易（对于部署它的人 - 他们只是启动“某个应用程序”并且它自己的工作方式如何，部署者不必须弄清楚要部署哪个应用程序，频率等等）;但那对开发者来说更​​难。

关于“C”：

1. 如果系统（例如）与安全或交易有关，那么你就会想要这样做，所以一切都是KISS，并且通过混淆失败的可能性更小。如果系统的两个部分自然地更加不同，那么无论如何都要这样做是有意义的。 （如果系统的两侧非常相似，那么你将倾向于B.）
2. 如果项目非常大（即许多工程师），当然C更容易，因为它更加分散。它会让你更自然地形成两者之间的通信协议等。

C是“总是正确的”。 B对于“部署方便”可能是有用的。当然，如果您只是进行“hello world”测试，A很有用（如果令人困惑）。

---

要对这个棘手的问题得到进一步的意见，就必须明确提出部署案例;即它是一个应用程序商店游戏，它是一次性的自助服务终端安装，工厂范围的软件，或任何情况。干杯