使用Unity3D的50个技巧：Unity3D最佳实践（上）

刚开始学习Unity3D时间不长，在看各种资料。除了官方的手册以外，其他人的经验也是非常有益的。偶尔看到老外这篇文章，觉得还不错，于是翻译过来和大家共享。原文地址：http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/，下面是译文。

欢迎转载，请注明出处：燕良@游戏开发。另外，欢迎各路高手加入我的QQ群：264656505，切磋交流技术。

关于这些技巧

这些技巧不可能适用于每个项目。

• 这些是基于我的一些项目经验，项目团队的规模从3人到20人不等；
• 框架结构的可重用性、清晰程度是有代价的——团队的规模和项目的规模决定你要在这个上面付出多少；
• 很多技巧是品味的问题（这里所列的所有技巧，可能有同样好的技术替代方案）；
• 一些技巧可能是对传统的Unity开发的一个冲击。例如，使用prefab替代对象实例并不是一个传统的Unity风格，并且这样做的代价还挺高的（需要很多的preffab）。也许这些看起来有些疯狂，但是在我看来是值得的。

流程

1、避免Assets分支

所有的Asset都应该只有一个唯一的版本。如果你真的需要一个分支版本的Prefab、Scene或是Mesh，那你要制定一个非常清晰的流程，来确定哪个是正确的版本。错误的分支应该起一个特别的名字，例如双下划线前缀：__MainScene_Backup。Prefab版本分支需要一个特别的流程来保证安全（详见Prefabs一节）。

2、如果你在使用版本控制的话，每个团队成员都应该保有一个项目的Second Copy用来测试

修改之后，Second Copy和Clean Copy都应该被更新和测试。大家都不要修改自己的Clean Copy。这对于测试Asset丢失特别有用。

3、考虑使用外部的关卡编辑工具

Unity不是一个完美的关卡编辑器。例如，我们使用TuDee来创建3D Tile-Based的游戏，这使我们可以获得对Tile友好的工具的益处（网格约束，90度倍数的旋转，2D视图，快速Tile选择等）。从一个XML文件来实例化Prefab也很简单。详见Guerrilla Tool Development。

4、考虑把关卡保存为XML，而非scene

这是一种很奇妙的技术：

• 它可以让你不必每个场景都设置一遍；
• 他可以加载的更快（如果大多数对象都是在场景之间共享的）。
• 它让场景的版本合并变的简单（就算是Unity的新的文本格式的Scene，也由于数据太多，而让版本合并变的不切实际）。
• 它可以使得在关卡之间保持数据更简便。

你仍就可以使用Unity作为关卡编辑器（尽管你用不着了）。你需要写一些你的数据的序列化和反序列化的代码，并实现在编辑器和游戏运行时加载关卡、在编辑器中保存关卡。你可能需要模仿Unity的ID系统来维护对象之间的引用关系。

5、考虑编写通用的自定义Inspector代码

实现自定义的Inspector是很直截了当的，但是Unity的系统有很多的缺点：

• 它不支持从继承中获益；
• 它不允许定义字段级别的Inspector组件，而只能是class类型级别。举个例子，如果没有游戏对象都有一个ScomeCoolType字段，而你想在Inspector中使用不同的渲染，那么你必须为你的所有class写Inspector代码。

你可以通过从根本上重新实现Inspector系统来处理这些问题。通过一些反射机制的小技巧，他并不像看上去那么看，文章底部（日后另作翻译）将提供更多的实现细节。

                                                                                                                                         

场景组织

6、使用命名的空Game Object来做场景目录

仔细的组织场景，就可以方便的找到任何对象。

7、把控制对象和场景目录（空Game Objec）放在原点（0，0，0）

如果位置对于这个对象不重要，那么就把他放到原点。这样你就不会遇到处理Local Space和World Space的麻烦，代码也会更简洁。

8、尽量减少使用GUI组件的offset

通常应该由控件的Layout父对象来控制Offset；它们不应该依赖它们的爷爷节点的位置。位移不应该互相抵消来达到正确显示的目的。做基本上要防止了下列情况的发生：

父容器被放到了（100，-50），而字节点应该在（10，10），所以把他放到（90，60）[父节点的相对位置]。

这种错误通常放生在容器不可见时。

9、把世界的地面放在Y=0

这样可以更方便的把对象放到地面上，并且在游戏逻辑中，可以把世界作为2D空间来处理（如果合适的话），例如AI和物理模拟。

10、使游戏可以从每个Scene启动

这将大大的降低测试的时间。为了达到所有场景可运行，你需要做两件事：

首先，如果需要前面场景运行产生的一些数据，那么要模拟出它们。

其次，生成在场景切换时必要保存的对象，可以是这样：

 myObject = FindMyObjectInScene();

 if (myObjet == null)
 {
    myObject = SpawnMyObject();
 }

                                                                                                                                                                   

美术

11、把角色和地面物体的中心点(Pivot)放在底部，不要放在中间

这可以使你方便的把角色或者其他对象精确的放到地板上。如果合适的话，它也可能使得游戏逻辑、AI、甚至是物理使用2D逻辑来表现3D。

12、统一所有的模型的面朝向（Z轴正向或者反向）

对于所有具有面朝向的对象（例如角色）都应该遵守这一条。在统一面朝向的前提下，很多算法可以简化。

13、在开始就把Scale搞正确

请美术把所有导入的缩放系数设置为1，并且把他们的Transform的Scale设置为1,1,1。可以使用一个参考对象（一个Unity的Cube）来做缩放比较。为你的游戏选择一个世界的单位系数，然后坚持使用它。

14、为GUI组件或者手动创建的粒子制作一个两个面的平面模型

设置这个平面面朝向Z轴正向，可能简化Billboard和GUI创建。

15、制作并使用测试资源

• 为SkyBox创建带文字的方形贴图；
• 一个网格（Grid）；
• 为Shader测试使用各种颜色的平面：白色，黑色，50%灰度，红，绿，蓝，紫，黄，青；
• 为Shader测试使用渐进色：黑到白，红到绿，红到蓝，绿到蓝；
• 黑白格子；
• 平滑的或者粗糙的法线贴图；
• 一套用来快速搭建场景的灯光（使用Prefa）；

                                                                                                                                                                     

Prefabs

16、所有东西都使用Prefab

只有场景中的“目录”对象不使用Prefab。甚至是那些只使用一次的唯一对象也应该使用Prefab。这样可以在不动用场景的情况下，轻松修改他们。（一个额外的好处是，当你使用EZGUI时，这可以用来创建稳定的Sprite Atlases）

17、对于特例使用单独的Prefab，而不要使用特殊的实例对象

如果你有两种敌人的类型，并且只是属性有区别，那么为不同的属性分别创建Prefab，然后链接他们。这可以：

• 在同一个地方修改所有类型
• 在不动用场景的情况下进行修改

如果你有很多敌人的类型，那么也不要在编辑器中使用特殊的实例。一种可选的方案是程序化处理它们，或者为所有敌人使用一个核心的文件/Prefab。使用一个下拉列表来创建不同的敌人，或者根据敌人的位置、玩家的进度来计算。

18、在Prefab之间链接，而不要链接实例对象

当Prefab放置到场景中时，它们的链接关系是被维护的，而实例的链接关系不被维护。尽可能的使用Prefab之间的链接可以减少场景创建的操作，并且减少场景的修改。

19、如果可能，自动在实例对象之间产生链接关系

如果你确实需要在实例之间链接，那么应该在程序代码中去创建。例如，Player对象在Start时需要把自己注册到GameManager，或者GameManager可以在Start时去查找Player对象。

对于需要添加脚本的Prefab，不要用Mesh作为根节点。当你需要从Mesh创建一个Prefab时，首先创建一个空的GameObject作为父对象，并用来做根节点。把脚本放到根节点上，而不要放到Mesh节点上。使用这种方法，当你替换Mesh时，就不会丢失所有你在Inspector中设置的值了。

使用互相链接的Prefab来实现Prefab嵌套。Unity并不支持Prefab的嵌套，在团队合作中第三方的实现方案可能是危险的，因为嵌套的Prefab之间的关系是不明确的。

20、使用安全的流程来处理Prefab分支

我们用一个名为Player的Prefab来讲解这个过程。

用下面这个流程来修改Player：

1. 复制Player Prefab；
2. 把复制出来的Prefab重命名为__Player_Backup；
3. 修改Player Prefab；
4. 测试一切工作正常，删除__Player_Backup；

不要把新复制的命名为Player_New，然后修改它。

有些情况可能更复杂一些。例如，有些修改可能涉及到两个人，上述过程有可能使得场景无法工作，而所有人必须停下来等他们修改完毕。如果修改能够很快完成，那么还用上面这个流程就可以。如果修改需要花很长时间，则可以使用下面的流程：

• 第一个人：
  1. 复制Player Prefab；
  2. 把它重命名为__Player_WithNewFeature或者__Player_ForPerson2；
  3. 在复制的对象上做修改，然后提交给第二个人；
• 第二个人：
  1. 在新的Prefab上做修改；
  2. 复制Player Prefab，并命名为__Player_Backup；
  3. 把__Player_WithNewFeature拖放到场景中，创建它的实例；
  4. 把这个实例拖放到原始的Player Prefab中；
  5. 如果一切工作正常，则可使删除__Player_Backup和__Player_WithNewFeature;

                                                                                                                                                                       

扩展和MonoBehaviourBase

21、扩展一个自己的Mono Behaviour基类，然后自己的所有组件都从它派生

这可以使你方便的实现一些通用函数，例如类型安全的Invoke，或者是一些更复杂的调用（例如random等等）。

22、为Invoke, StartCoroutine and Instantiate 定义安全调用方法

定义一个委托任务（delegate Task），用它来定义需要调用的方法，而不要使用字符串属性方法名称，例如：

 public void Invoke(Task task, float time)
 {
    Invoke(task.Method.Name, time);
 }

23、为共享接口的组件扩展

有些时候把获得组件、查找对象实现在一个组件的接口中会很方便。

下面这种实现方案使用了typeof，而不是泛型版本的函数。泛型函数无法在接口上工作，而typeof可以。下面这种方法把泛型方法整洁的包装起来。

 //Defined in the common base class for all mono behaviours
 public I GetInterfaceComponent<I>() where I : class
 {
    return GetComponent(typeof(I)) as I;
 }

 public static List<I> FindObjectsOfInterface<I>() where I : class
 {
    MonoBehaviour[] monoBehaviours = FindObjectsOfType<MonoBehaviour>();
    List<I> list = new List<I>();

    foreach(MonoBehaviour behaviour in monoBehaviours)
    {
       I component = behaviour.GetComponent(typeof(I)) as I;

       if(component != null)
       {
          list.Add(component);
       }
    }

    return list;

24、使用扩展来让代码书写更便捷

例如：

 public static class CSTransform
 {
    public static void SetX(this Transform transform, float x)
    {
       Vector3 newPosition =
          new Vector3(x, transform.position.y, transform.position.z);

       transform.position = newPosition;
    }
    ...
 }

25、使用防御性的GetComponent()

有些时候强制性组件依赖（通过RequiredComponent）会让人蛋疼。例如，很难在Inspector中修改组件（即使他们有同样的基类）。下面是一种替代方案，当一个必要的组件没有找到时，输出一条错误信息。

 public static T GetSafeComponent<T>(this GameObject obj) where T : MonoBehaviour
 {
    T component = obj.GetComponent<T>();

    if(component == null)
    {
       Debug.LogError("Expected to find component of type "
          + typeof(T) + " but found none", obj);
    }

    return component;
 }