unity 删除服务器项目,为无头服务器创建单独的Unity项目

小智..

12

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

以下是三种可能性:

(A)有些人喜欢在一个脚本中有双方.(显然在同一个项目中.)

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

(C)有些人更喜欢有两个完全独立的项目.因此,一个项目是客户端,一个是服务器.

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

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

关于"A":

从Unity早期开始,许多代码样本都悬挂在网络上,恰好是"A"形式.随着岁月的流逝,这变得不那么真实了,但总的来说,"在www上铺设旧的Unity代码"一般都是危险的.

(实际上,正是出于这个原因,许多初学者程序员学会了使用Unity进行整体编程并在网络上查找Unity片段,认为或认为您"必须使用"方法A.)

请注意,着名的Unity大部分示例代码都非常愚蠢.实际上,您看到的网络样本通常就是一个很好的例子.

我个人认为方法"A"非常混乱,毫无意义.事实上,多年来我一直试图看到它的优势所在.我能想到的唯一优势是:它节省了驱动器空间.因此,您可以拥有一个 - 而不是拥有两个脚本 - 这可以节省驱动器上超过KB的空间.在将这两个概念合二为一时,我自己也看不出任何其他目的.

关于"B":

这可能是中型项目的方法.这里的缺点是应用程序必须从根本上知道将自己分成两个不同的应用程序.

如果部署很重要,如果它必须是"GI证明",B比C更容易(对于部署它的人 - 他们只是启动"某个应用程序"并且它自己的工作方式如何,部署者不必须弄清楚要部署哪个应用程序,频率等等); 但那对开发者来说更​​难.

关于"C":

如果系统(例如)与安全或交易有关,那么你就会想要这样做,所以一切都是KISS,并且通过混淆失败的可能性更小.如果系统的两个部分自然地更加不同,那么无论如何都要这样做是有意义的.(如果系统的两侧非常相似,那么你将倾向于B.)

如果项目非常大(即许多工程师),当然C更容易,因为它更加分散.它会让你更自然地形成两者之间的通信协议等.

C是"总是正确的".B对于"部署方便"可能是有用的.当然,如果您只是进行"hello world"测试,A很有用(如果令人困惑).

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

我必须清楚地告诉你:***你看到Unity的大多数示例代码是完全 - 绝对 - 完全 - 废话***.在Unity的许多方面,这绝对是真正的***.我将准确而具体地告诉你这是为什么:Unity是一个拥有少数专业工程师的领域,以及数百万对业余编程一无所知的业余爱好者.出于这个原因,奇怪的代码示例突然出现了一大堆废话***并且示例和技术在各处重复出现.这就是您看到的可笑的Unity代码示例的具体原因. (6认同)