译者：崔嘉艺（milan21）
审校：崔国军（飞扬971）
为什么会想要和大家说说Unity3D中加载场景，主要是因为在项目的场景中经常会出现一些问题，所以在这里就想和大家分享一些加载场景的想法。
你如何对一个“关卡”进行编程？
这在游戏引擎中通常不是一个问题，但Unity需要你将每个“关卡”隔离为一个场景。并且Unity的场景有一些奇怪的设计选择（或者就是bug？）-感觉他们引擎的场景是为玩具项目设计的，而不是为产品级别的游戏所设计。
这里有一个什么起作用、什么不起作用、以及我如何解决/在Unity内做得更好的意识流。。。这些内容没有经过仔细研究，大多是来自记忆或我自己的拍脑袋。 所以。。。这篇文章里面记录的内容可能不是全部是真的:)。
当我切换到Unreal4的时候，我将使用这样的帖子作为基准来比较Unity为什么会失败，以及多么糟糕-反之亦然。
更新：我添加了更多的方法和想法/评论
举个简单的例子来说：
1.加载场景的时候，游戏中的所有内容都将被销毁。
2.场景不能带参数。
3.场景不能保留状态。
4.场景不能在代码中构造或是修改。 程序化的游戏？ 哈哈！ 根本没有机会！
5.你不能一次编辑多个场景（这是荒谬的，给开发带来不必要地痛苦）。
6.。。。和一堆其他问题，其中许多问题是上述问题的副作用。
更多Unity的bug使得你在处理这个问题的时候感觉像是在地狱里
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的破天荒的序列化系统吗？好吧unity场景，我非常讨厌这个系统）。
最后UI界面，我发现“不要在加载的时候删除一切（DontDestroyOnLoad）”最有吸引力的部分是你可以使用：
1
GameObject param1 = ... ;
2
GameObject persistentObject = ... ;
3
4
param1.transform.parent = persistentObject.transform;
5
6
//param1.tag = ... oh, no - can't do this. Unity's tags are hardcoded (that is NOT what Tag means, guys!)
7
8
param1.name ="Parameter 1";
然后，你可以使用类似以下的内容来对它进行检索：
1
GameObject persistentObject = ... ;
2
GameObject param1 = persistentObject.Find("Parameter 1");
（假设你不知何故得到了一个持久对象的引用。。。举个简单的例子来说，使它成为一个单例）。
我相信你也可以使用静态对象来做到这一点（？）但是。。。把一整个对象关系图隐藏在一个静态成员变量里面可能会进入“这可能会暴露Unity序列化的Bug”的领域。 最好避免这么做：不要浪费太多的时间在调试Unity上。
理想/正确的解决方案
数据就是数据
我们回到那个Unity中反复出现的问题，它对引擎的破坏这么大：Unity拒绝承认“数据”就是“数据”。 它坚持：“不，不！ 数据是代码和对象还有图形和物理对象以及。。。和。。。和。。。和。。。“。
（让我们澄清一点：有经验的程序员看不起Unity的方法，而且一般都是非常尖刻不留情。这不是因为我们对其他引擎和方法狂热-而是Unity的编程方法在20世纪80年代就基本上死了。它没有做什么限制，很快就被证明很难创建复杂的程序比如说是视频游戏）。
理想情况下，我们会将游戏的数据存储为数据，并在加载的时候将数据传递给场景。Unity阻止我们这样做。我们为模拟这一切而做的一切（例如嵌入JSON（反）序列化器）是搬掉Unity路障的解决方法。
当前的实验
我已经在以前的Unity项目中尝试了大多数以上的方法，没有一个做得特别好。
这次尝试什么？
这里是我目前的需求：
1.当场景加载的时候，我需要注入玩家角色。这是一个复杂的对象，包括渲染、物理和程序化网格。
2.当场景加载的时候unity场景，我需要单独配置一些不可见的状态：比如玩家的特征（例如命中点、得分）。。。这些不可见的状态关卡会克隆并用作可见状态（在关卡变化期间的命中点。当你开始一个关卡时候的命中点会“保存”那些不变的值）。
3.当场景加载的时候，。。。我也有不可见的状态，用于生成其他状态。举个简单的例子来说，关于到目前为止已经探索了这个关卡多少的信息、 战争迷雾等等。
4.当玩家完成关卡的时候，我需要选择一些数据保存到主菜单，并保存到磁盘中。
5.当玩家完成关卡的时候，我需要存储“之前”和“之后”之间的差异，以便我可以授予各种徽章/成就和一次性奖励等等。此外，以便我可以展示“ 这是你已经实现的成就！“的最终结束界面。
解决办法
我已经放弃了：我写了一个自己的迷你引擎来解决Unity可怕的场景管理。回顾我的许多Unity项目，我已经用了很多天，可能超过一个星期，不得不不断地重新实现这个核心功能，因为Unity版本的场景管理情况令人难以置信的混乱。
这是诸多bug的其中一个，就是这些bug让我认为Unity的技术负责人从来不自己写游戏。如果他们这样自己写游戏的话，他们不会忍受这种渣问题的。
简短的描述：
有用的功能
对两个游戏物体进行“比对”寻找差异化
这将是非常有用的。这将使得上面的许多解决方法更加容易。
这个功能也内置于Unity之中。我们知道这一点：序列化系统依赖于这个功能。
但是他们不允许我们访问（就我所知：我没有看到一个公共API会去调用这个功能）。
“克隆”一个游戏物体，保持对原始游戏物体的引用
所有面向对象编程语言的对象（包括C＃）会跟踪它们所创建的类。
如果Unity再次使用“clone object1 to create object2”来做同样的事情，这将使许多上面的方法更加容易，也更加不容易出错。
