处理项目时是否更新 Unity 引擎？答案

【问题标题】：Updating Unity Engine or not when working on a project?处理项目时是否更新 Unity 引擎？
【发布时间】：2015-10-18 22:59:16
【问题描述】：

我从几个月开始就开始使用 Unity，也就是在 Unity 5 发布之前。

我记得，当我还在为一个非常简单的项目使用 Unity 4 时，我将它更新到 Unity 5，当我重新打开该项目时，基本上场景中的所有内容都被删除了，我不得不重新构建它。好吧，这没什么大不了的，因为它只是一个试验，但现在我开始从事一个更大的项目。到现在为止我安装的小更新（比如，从 Unity 5.1 到 5.2 等）并没有对我正在制作的试用游戏造成任何伤害，它们仍然是我制作的，但我想知道...现在我正在处理一些我绝对不想突然被删除或搞砸的东西，当它们出现时安装新的引擎更新是一个好习惯吗？还是我应该只安装次要的并忽略最终的 Unity 6？

【问题讨论】：

附加问题：尽可能频繁地更新 Unity 是否会降低更新时因不兼容而丢失内容的风险？我的意思是，从 5.0 更新到 5.6 是否比从 5.5 更新到 5.6 风险更大（它们不是实际版本。只是为了举例）？

标签： c# unity3d game-development

【解决方案1】：

问题有点类似于源码冲突的问题：

即我应该遵循 CI 最佳实践并经常更新，还是应该继续在自己的小世界中编写代码，仅在 6 个月后与同行的代码执行 SVN 合并？

当然，后者每天的问题较少，但从长远来看，很可能会导致地狱中的代码合并噩梦。

就 Unity3D 而言，如果您的计划是制作一款商业游戏，那么像更新源代码一样经常更新 Unity3D 可能是明智之举。原因是您更新 Unity（以及我可能添加的相关 3rd 方资产）的时间越长，当您决定更新时，您遇到冲突或不兼容的可能性就越高（我从经验中说，我相信其他人会证明）。

此外，Unity3D 会针对您打算定位的平台不断更新，包括错误修复；性能增强或其他附加功能。

使用 MVVM 从 Unity3D 中解耦

游戏工作室和 Unity3D 的普遍共识是通过使用桥接模式和 MVVM 将您的实际处理逻辑与 Unity3D 完全分离。这允许您在普通的旧 Visual Studio 中编写，您可以在其中按照 MVVM 模式快速进行原型设计和单元测试。只有 V 知道 Unity3D 通常表示为 Unity3D 行为。 Tell me more

您的直接好处是，如果执行得当，您的大部分代码都不会受到 Unity3D 更改的影响。

【讨论】：

是的，我的目标是制作一款商业游戏。确实，Unity 的更新通常会让一切变得更好。但是，我不想因为某种不兼容而失去数周或数月的工作。
这是使用别人的代码的代价，不管是简单的.DLL；一个 NuGet 包；或完整的游戏引擎中间件，如 Unity3D。如果您不希望出现此类问题，您可以随时将自己与外部代码分离并编写自己的游戏引擎。
@JohnStrife 请参阅上面的“使用 MVVM 与 Unity3D 解耦”
那么，您的意思是我可以备份我的整个游戏，将其与 Unity 分开，以获得不受游戏引擎更改影响的“安全”副本？您链接的视频中是否讨论了这样做的方式？（因为很长，有用的我都会看）
@JohnStrife 这与备份无关。我强烈建议您花时间观看视频作为学习练习