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

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


【流程】


1、避免Assets分支


错误的分支应该起一个特别的名字,比如双下划线前缀:__MainScene_Backup。Prefab版本号分支须要一个特别的流程来保证安全(详见Prefabs一节)。


2、假设你在使用版本号控制的话。每一个团队成员都应该保有一个项目的Second Copy用来測试 改动之后,Second Copy和Clean Copy都应该被更新和測试。大家都不要改动自己的Clean Copy。这对于測试Asset丢失特别实用。


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


不是一个完美的关卡编辑器。比如,我们使用TuDee来创建3D Tile-Based的游戏,这使我们能够获得对Tile友好的工具的益处(网格约束。90度倍数的旋转,

视图,高速Tile选择等)。从一个XML文件来实例化Prefab也非常easy。详见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之间的关系是不明白的。


转载于:



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

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


【流程】


1、避免Assets分支


错误的分支应该起一个特别的名字,比如双下划线前缀:__MainScene_Backup。Prefab版本号分支须要一个特别的流程来保证安全(详见Prefabs一节)。


2、假设你在使用版本号控制的话。每一个团队成员都应该保有一个项目的Second Copy用来測试 改动之后,Second Copy和Clean Copy都应该被更新和測试。大家都不要改动自己的Clean Copy。这对于測试Asset丢失特别实用。


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


不是一个完美的关卡编辑器。比如,我们使用TuDee来创建3D Tile-Based的游戏,这使我们能够获得对Tile友好的工具的益处(网格约束。90度倍数的旋转,

视图,高速Tile选择等)。从一个XML文件来实例化Prefab也非常easy。详见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之间的关系是不明白的。