译者：崔嘉艺（milan21）

审校：崔国军（飞扬971）

为什么会想要和大家说说Unity3D中加载场景，主要是因为在项目的场景中经常会出现一些问题，所以在这里就想和大家分享一些加载场景的想法。

这在游戏引擎中通常不是一个问题，但Unity需要你将每个“关卡”隔离为一个场景。并且Unity的场景有一些奇怪的设计选择（或者就是bug？） - 感觉他们引擎的场景是为玩具项目设计的，而不是为产品级别的游戏所设计。

这里有一个什么起作用、什么不起作用、以及我如何解决/在Unity内做得更好的意识流。。。这些内容没有经过仔细研究，大多是来自记忆或我自己的拍脑袋。 所以。。。这篇文章里面记录的内容可能不是全部是真的:)。

当我切换到Unreal4的时候，我将使用这样的帖子作为基准来比较Unity为什么会失败，以及多么糟糕 - 反之亦然。

举个简单的例子来说：

1.加载场景的时候，游戏中的所有内容都将被销毁。

2.场景不能带参数。

3.场景不能保留状态。

4.场景不能在代码中构造或是修改。 程序化的游戏？ 哈哈！ 根本没有机会！

5.你不能一次编辑多个场景（这是荒谬的，给开发带来不必要地痛苦）。

6. 。。。和一堆其他问题，其中许多问题是上述问题的副作用。

1.当场景加载的时候，没有办法告诉Unity要运行什么代码。

•这是必需的，因为Unity拒绝让你传递参数。

•因为没有办法传递参数，所以你必须依赖Awake（），Start（）和OnEnable（）方法。

•这三种方法被定义为在对象之间以“随机”的顺序进行运行。

•如果你有一个需要被查找、加载和定位的参数，可以将其放在Awake（）函数之中。

•如果需要对这个参数做全局引用，则必须在Start（）函数运行期间设置它，否则不能保证它已被找到。

•任何需要使用该参数的代码都不能写在OnEnable()之外的其他方法中。

•。。。但是：很多（绝大多数？）理应在Start()方法中的代码，如果写在OnEnable()中就不能正常工作了，因为Start()和OnEnable()这两个方法做的是不同的事情！

Unity的场景加载太烦人了。

Unity5:增量加载

你可以加载一个场景，然后在这个的基础之上加载另一个场景。在某种程度上这个功能在UnityPro中一直存在（比如允许“关卡加载器”的场景等等），但是Unity5对这一点进行了升级和扩展。

根据我的理解，Unity5并没有解决这些问题，但它确实减轻了这些问题。 特别是，我已经看到了编辑器的修改记录，以改善一次加载多个场景的处理。但我自己还没有尝试过这块（我还使用Unity4的版本）。从我看过的视频来看，它看起来像是一个明确的改进，但距离我称之为“标准”的游戏引擎仍然有相当长的一段时间。

如果你能使用Unity5，请看看你可以走多远。然后把有关你的提示和技巧通过推特发给我。

不要选择“在加载的时候删除一切（DontDestroyOnLoad）”

你可以标记任意数量的游戏物体为“嘿，Unity！ 当你删除一切（这是愚蠢的主意，但是可行）的时候，请不要删除这些游戏物体！

在理论上，这意味着你可以编写自己的迷你游戏引擎（你为什么要再次使用Unity，因为你一直想重新发明轮子，对吗？），然后把所有的游戏数据存储为一个“不要销毁”的对象，然后在新场景完成加载后解析并加载刚才那个“不要销毁”的对象。

这不解决任何问题-它只是将问题转移到一个新的地方，但至少它们现在是在你的代码中进行处理，而不是在Unity的代码中进行处理。你最终会写自己的迷你游戏引擎。你从Unity获得的是几乎零帮助，并。。。使这个问题更难。。。你必须保持与Unity的专有数据处理的兼容：初始化协议，蹩脚的序列化等等。

静态变量

这是做“不要在加载的时候删除一切(DontDestroyOnLoad)”的“真正的”方式，“不要在加载的时候删除一切(DontDestroyOnLoad)”是内置于编程语言的标准方法。 它让我觉得奇怪的是，Unity在有了一个更标准的方法以后，还添加了“不要在加载的时候删除一切” 是不是一个初级程序员谁不知道如何使用“静态”关键字？还是有一些令人讨厌的埋在Unity核心引擎的东西打破了静态？ （提示：我几乎可以保证它会是序列化系统中的某个地方的一个bug，我很讨厌这一点，如果你还没有注意到的话）。 在Unity的架构中几乎所有的东西都会与那个怪物打交道！）

它似乎对我来说总是工作正常。但它是可怕的：它什么时候会停止工作？ 你怎么才能知道这一点？ 有什么Unity的bug潜伏在这里？

自包含的场景

拿掉所有的游戏逻辑，我们已经把数据作为参数传递给了你的场景（在任何正常的引擎中）。。。而不是将参数嵌入在场景之内。

当场景加载的时候，它运行这个逻辑，然后发现“哦！ 我似乎缺少很多核心数据。我最好在运行的过程重新创建它！

这是一个曲折的逻辑，对那些新加入你的团队的开发者来说可能非常混乱（并且也可能混乱到了你自己，如果你从项目中休息了一段时间再回来）。但它有一些显著的好处：

你可以在游戏中运行场景。。。或。。。直接从Unity编辑器运行它，它将表现的（几乎）相同。可以以这种方式进行更快的测试+调试

场景保持着自包含的特点。 这是Unity的设计师“打算”你使用场景（虽然这对于游戏来说是一个非常糟糕的解决方案）的方式。 这对你的游戏的源代码控制和多用户编辑有一些微小的好处：如果你这样工作的话，你会遇到少量的Unity核心bug。

理论上：更多的“场景特定”的代码位于场景中（在Unity编辑器中）。当你的项目变大的时候，在理论上：这使得理解发生了什么更容易，因为代码+对象对于彼此都是本地局部的。我不完全确认这一点：与Unity那种比较差的安排代码+数据的方式相比。。。在实践中，这个局部性可能不明显（Unity编辑器“隐藏”了局部性，所以你作为开发人员并没有从中得到什么好处）。

使用预制件（Prefabs）

好吧，我遇到过那些声称这样做的人-在编辑器中创建场景，然后将所有内容转换为预制件，然后在场景加载的时候加载预制件，传递不同的“要加载的预制件的名字”列表。

哦，请不要这么做！

首先：Unity中的预制件对于这种复杂的情况会被严重破坏。他们不能正常工作，你应该尽可能避免使用预制件-除了那些最简单的用例（非嵌套、简单的小预制件）。

第二：哇，这很曲折。 你正在滥用“模板化的对象系统”来绕过“数据层”和“场景加载器”中的设计缺陷。它可能是一种天才做法-但它是那种不寻常的天才做法，它很容易在未来的更新后的引擎被破坏，而Unity可以合法地说：“嗯？你为什么要这样做？“

如果它在你的项目中正常工作，这太棒了！ 但对我来说，这总是一个隐患。可能我错过了一些好的做法，这可能是一个比我意识到的更好的路线。在大多数情况下，这是事实，Unity不能处理正确复杂的预制件是事实。Unity5据称修复了一些预制件方面的错误，所以。。。我会在某个时候再考虑使用预制件。然而，Unity中的预制件方面的历史是非常丑陋的，我会非常谨慎的信任他们。

Unity不支持字典和哈希表

这是一个巨大的散发着臭味的问题（纵观整个Unity的历史！）。

它改变了上述解决方法中的利弊平衡。你不能简单地添加命名参数到你的静态方法和 “不要在加载的时候删除一切”的列表中-因为Unity会穿过编程语言来直接删除/销毁/损坏它们。

（我说过我讨厌Unity的破天荒的序列化系统吗？好吧，我非常讨厌这个系统）。

最后，我发现“不要在加载的时候删除一切（DontDestroyOnLoad）”最有吸引力的部分是你可以使用：

然后，你可以使用类似以下的内容来对它进行检索：

（假设你不知何故得到了一个持久对象的引用。。。举个简单的例子来说，使它成为一个单例）。

我相信你也可以使用静态对象来做到这一点（？）但是。。。把一整个对象关系图隐藏在一个静态成员变量里面可能会进入“这可能会暴露Unity序列化的Bug”的领域。 最好避免这么做：不要浪费太多的时间在调试Unity上。

数据就是数据

我们回到那个Unity中反复出现的问题，它对引擎的破坏这么大：Unity拒绝承认“数据”就是“数据”。 它坚持：“不，不！ 数据是代码和对象还有图形和物理对象以及。。。和。。。和。。。和。。。“。

（让我们澄清一点：有经验的程序员看不起Unity的方法，而且一般都是非常尖刻不留情。这不是因为我们对其他引擎和方法狂热- 而是Unity的编程方法在20世纪80年代就基本上死了。它没有做什么限制，很快就被证明很难创建复杂的程序比如说是视频游戏）。

理想情况下，我们会将游戏的数据存储为数据，并在加载的时候将数据传递给场景。 Unity阻止我们这样做。我们为模拟这一切而做的一切（例如嵌入JSON（反）序列化器）是搬掉Unity路障的解决方法。

我已经在以前的Unity项目中尝试了大多数以上的方法，没有一个做得特别好。

这次尝试什么？

这里是我目前的需求：

1.当场景加载的时候，我需要注入玩家角色。这是一个复杂的对象，包括渲染、物理和程序化网格。

2.当场景加载的时候，我需要单独配置一些不可见的状态：比如玩家的特征（例如命中点、得分）。。。这些不可见的状态关卡会克隆并用作可见状态（在关卡变化期间的命中点。当你开始一个关卡时候的命中点会“保存”那些不变的值）。

3.当场景加载的时候，。。。我也有不可见的状态，用于生成其他状态。举个简单的例子来说，关于到目前为止已经探索了这个关卡多少的信息、 战争迷雾等等。

4.当玩家完成关卡的时候，我需要选择一些数据保存到主菜单，并保存到磁盘中。

5.当玩家完成关卡的时候，我需要存储“之前”和“之后”之间的差异，以便我可以授予各种徽章/成就和一次性奖励等等。此外，以便我可以展示“ 这是你已经实现的成就！“的最终结束界面。

解决办法

我已经放弃了：我写了一个自己的迷你引擎来解决Unity可怕的场景管理。回顾我的许多Unity项目，我已经用了很多天，可能超过一个星期，不得不不断地重新实现这个核心功能，因为Unity版本的场景管理情况令人难以置信的混乱。

这是诸多bug的其中一个，就是这些bug让我认为Unity的技术负责人从来不自己写游戏。如果他们这样自己写游戏的话，他们不会忍受这种渣问题的。

简短的描述：

• 每次场景开始加载的时候，写一个类加载钩子（使用C＃）。

• 调试Unity加载场景的时候所有正式文档之外的API调用。这可能需要很长时间。

• 做反向工程来知道Unity场景的哪些部分是“有效”和何时“有效”。

• 编写每个商业游戏引擎（Unity除外！）用于管理场景加载的那种代码。

• 将其包装在API中。

• 。。。

• 永远不要在Unity的场景系统里面再处理这个问题，永远永远都不要！

有用的功能

对两个游戏物体进行“比对”寻找差异化

这将是非常有用的。这将使得上面的许多解决方法更加容易。

这个功能也内置于Unity之中。我们知道这一点：序列化系统依赖于这个功能。

但是他们不允许我们访问（就我所知：我没有看到一个公共API会去调用这个功能）。

 “克隆”一个游戏物体，保持对原始游戏物体的引用

所有面向对象编程语言的对象（包括C＃）会跟踪它们所创建的类。

如果Unity再次使用“clone object1 to create object2”来做同样的事情，这将使许多上面的方法更加容易，也更加不容易出错。

【版权声明】

原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权。