10-26 04:05 阅读 21

unity教程电子书（unity教程）

1、有些技能可能是对传统Unity开发的冲击。比如用prefab替换对象实例就不是传统的Unity风格，这样做的成本相当高(需要大量的prefab)。这可能看起来很疯狂，

2、但在我看来是值得的。

3、 1.避免资产的分支

4、所有资产应该只有一个唯一版本。如果你真的需要一个分支版本的预置，场景或者网格，你需要做一个非常清晰的过程来确定哪个版本是正确的。错误的分支应该有一个特殊的名称，

5、例如，双下划线前缀：__MainScene_Backup。预制版本分支需要一个特殊的过程来确保安全。

6、 2.如果您使用版本控制，每个团队成员都应该保留一个项目的第二个副本用于测试。修改后，第二个副本和干净副本都应该更新和测试。

7、每个人都不应该修改自己的干净拷贝。这对于测试资产损失尤其有用。

8、 3.考虑使用外部级别编辑工具Unity并不是一个完美的级别编辑器。例如，我们使用TuDee创建基于3D图块的游戏，这使我们能够获得图块友好工具的好处(网格约束，

9、以90度的倍数旋转、2D视图、快速块选择等。).从XML文件实例化预置也很简单。

10、 4.考虑将关卡保存为XML而不是scene。这是一项了不起的技术：

11、它可以让你不必设置每一个场景；

12、它可以更快地加载(如果大多数对象在场景之间共享)。

13、它可以很容易地合并场景的版本(即使是Unity的新文本格式场景也有太多的数据，因此合并版本不切实际)。

14、它可以更容易地在不同级别之间保存数据。

15、你仍然可以使用Unity作为关卡编辑器(虽然你不需要它)。你需要写一些对你的数据进行序列化和反序列化的代码，实现运行时在编辑器和游戏中加载关卡，在编辑器中保存关卡。

16、你可能需要模仿Unity的ID系统来维护对象之间的引用关系。

17、 5.考虑编写一个通用的自定义检查器代码来实现一个自定义检查器是很简单的，但是Unity的系统有很多缺点：

18、它不支持从继承中获益；

19、它不允许在字段级别定义检查器组件，而只能在类类型级别定义。例如，如果没有游戏对象有ScomeCoolType字段，而您想在Inspector中使用不同的渲染，

20、然后，您必须为所有类编写检查器代码。

21、你可以通过从根本上重新实现督察制度来处理这些问题。通过反射机制的一些小技巧，他看到的并不是它看起来的样子，文章的底部(稍后翻译)会提供更多的实现细节。

22、场景组织6。使用命名的空游戏对象作为场景目录。仔细组织场景，你可以很容易地找到任何对象。

23、 7.将控制对象和场景目录(空游戏Objec)放在原点(0，0，0)。如果位置对这个物体不重要，那就把它放在原点。所以你在处理局部空间和世界空间时不会有麻烦。

24、代码也将更加简洁。

25、 8.尽量减少GUI组件的使用。偏移量通常应由控件的布局父对象控制。它们不应该依赖于它们的祖父节点的位置。位移不应相互抵消，以达到正确显示的目的。

26、这样做基本上可以防止以下情况发生：

27、父容器放在(100，-50)，字节点应该在(10，10)，所以放在(90，60)[父节点的相对位置]。

28、当容器不可见时，通常会释放此错误。

29、 9.把世界的地面放在Y=0可以更容易的把物体放在地面上，而且在游戏逻辑中，可以把世界当作一个2D空间(如果合适的话)，比如AI和物理模拟。

30、 10.让游戏从每个场景开始，会大大减少测试时间。为了使所有场景都可以运行，您需要做两件事：

31、首先，如果你需要前面场景产生的一些数据，就要模拟出来。

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

33、 myObject=FindMyObjectInScene(); if (myObjet==null){ myObject=SpawnMyObject();}

34、 11.将角色和地面物体的枢轴放在底部，而不是中间。这将方便您准确地将角色或其他对象放在地板上。如果合适的话，它还可能让游戏逻辑、人工智能，甚至物理学使用2D逻辑来表示3D。

35、 12.统一所有模型的面方向(Z轴正或负)。所有面向脸的物体(比如人物)都要遵守这个规则。很多算法可以在统一面对面的前提下简化。

36、 13.在开始时获得比例，并要求艺术家将所有导入的比例因子设置为1，并将他们的变换比例设置为1，1，1。您可以使用参考对象(Unity Cube)进行缩放比较。

37、为你的游戏选择一个世界单位系数，然后坚持下去。

38、 14.为GUI组件或手动创建的粒子制作一个具有两个面的平面模型。将该平面设置为Z轴可以简化广告牌和GUI的创建。

39、 15.制作和使用测试资源。

40、为SkyBox创建一个带文本的正方形地图；

41、一个网格；

42、使用各种颜色平面进行着色器测试：白色、黑色、50%灰色、红色、绿色、蓝色、紫色、黄色和青色；

43、使用渐变颜色进行着色器测试：黑色到白色，红色到绿色，红色到蓝色，绿色到蓝色；

44、黑白格；

45、平滑或粗糙的法线贴图；

46、用于快速构建场景的一组灯光(使用PREFA)；

47、 prefabs16，一切都用Prefab，只有场景中的“目录”对象不使用Prefab。即使是只使用一次的独特物品也应该使用预设物品。这使得在不使用场景的情况下修改它们变得很容易。

48、 (一个额外的好处是，当您使用EZGUI时，它可以用来创建稳定的Sprite图集。)

49、 17.为特殊情况使用单独的预设，而不是特殊的实例对象。如果你有两种类型的敌人，只有不同的属性，创建不同属性的预置，然后链接它们。这可以：

50、在同一位置修改所有类型

51、在不使用场景的情况下进行更改。

52、如果你有很多类型的敌人，不要在编辑器中使用特殊的实例。另一种方法是通过编程来处理它们，或者对所有敌人使用一个核心文件/预置。使用下拉列表创建不同的敌人，

53、或者根据敌人的位置和玩家的进度。

54、 18.预设之间的链接，而不是实例对象。当预置放置在场景中时，它们的链接关系保持不变，但是实例的链接关系不变。尽可能使用预置之间的链接，可以减少场景创建的操作。

55、并且减少了对场景的修改。

56、 19.如果可能，自动创建实例对象之间的链接关系。如果你真的需要实例之间的链接，你应该在程序代码中创建它。例如，一个玩家对象需要在启动时向游戏管理器注册。

57、或者GameManager可以在开始时寻找玩家对象。

58、对于需要添加脚本的Prefab，不要用Mesh作为根节点。当你需要从Mesh创建一个Prefab时，首先创建一个空的GameObject作为父对象，并用来做根节点。把脚本放到根节点上，

59、而不要放到Mesh节点上。使用这种方法，当你替换Mesh时，就不会丢失所有你在Inspector中设置的值了。

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

61、 20、使用安全的流程来处理Prefab分支我们用一个名为Player的Prefab来讲解这个过程。

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

63、复制Player Prefab；

64、把复制出来的Prefab重命名为__Player_Backup；

65、修改Player Prefab；

66、测试一切工作正常，删除__Player_Backup；

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

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

69、则可以使用下面的流程：

70、第一个人：

71、复制Player Prefab；

72、把它重命名为__Player_WithNewFeature或者__Player_ForPerson2；

73、在复制的对象上做修改，然后提交给第二个人；

74、第二个人：

75、在新的Prefab上做修改；

76、复制Player Prefab，并命名为__Player_Backup；

77、把__Player_WithNewFeature拖放到场景中，创建它的实例；

78、把这个实例拖放到原始的Player Prefab中；

79、如果一切工作正常，则可使删除__Player_Backup和__Player_WithNewFeature;

80、扩展和MonoBehaviourBase21、扩展一个自己的Mono Behaviour基类，然后自己的所有组件都从它派生这可以使你方便的实现一些通用函数，例如类型安全的Invoke，

81、或者是一些更复杂的调用（例如random等等）。

82、 22、为Invoke, StartCoroutine and Instantiate 定义安全调用方法定义一个委托任务（delegate Task），用它来定义需要调用的方法，

83、而不要使用字符串属性方法名称，例如：

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

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

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

87、 //Defined in the common base class for all mono behaviourspublic I GetInterfaceComponentI() where I : class{ return GetComponent(typeof(I)) as I;} public static ListI FindObjectsOfInterfaceI() where I : class{ MonoBehaviour[] monoBehaviours=FindObjectsOfTypeMonoBehaviour(); ListI list=new ListI(); foreach(MonoBehaviour behaviour in monoBehaviours) { I component=behaviour.GetComponent(typeof(I)) as I; if(component !=null) { list.Add(component); } } return list;}

88、 24、使用扩展来让代码书写更便捷例如：

89、 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; } .}

90、 25、使用防御性的GetComponent()有些时候强制性组件依赖（通过RequiredComponent）会让人蛋疼。例如，很难在Inspector中修改组件（即使他们有同样的基类）。

91、下面是一种替代方案，当一个必要的组件没有找到时，输出一条错误信息。

92、 public static T GetSafeComponentT(this GameObject obj) where T : MonoBehaviour{ T component=obj.GetComponentT(); if(component==null) { Debug.LogError(“Expected to find component of type ” + typeof(T) + “ but found none”, obj); } return component;}

93、风格26、避免对同一件事使用不同的处理风格在很多情况下，某件事并不只有一个惯用手法。在这种情况下，在项目中明确选择其中的一个来使用。下面是原因：

94、一些做法并不能很好的一起协作。使用一个，能强制统一设计方向，并明确指出不是其他做法所指的方向；

95、团队成员使用统一的风格，可能方便大家互相的理解。他使得整体结构和代码都更容易理解。这也可以减少错误；

96、几组风格的例子：

97、协程与状态机（Coroutines vs. state machines）；

98、嵌套的Prefab、互相链接的Prefab、超级Prefab（Nested prefabs vs. linked prefabs vs. God prefabs）；

99、数据分离的策略；

100、在2D游戏的使用Sprite的方法；

101、 Prefab的结构；

102、对象生成策略；

103、定位对象的方法：使用类型、名称、层、引用关系；

104、对象分组的方法：使用类型、名称、层、引用数组；

105、找到一组对象，还是让它们自己来注册；

106、控制执行次序（使用Unity的执行次序设置，还是使用Awake/Start/Update/LateUpdate，还是使用纯手动的方法，或者是次序无关的架构）；

107、在游戏中使用鼠标选择对象/位置/目标：SelectionManager或者是对象自主管理；

108、在场景变换时保存数据：通过PlayerPrefs，或者是在新场景加载时不要销毁的对象；

109、组合动画的方法：混合、叠加、分层；

110、时间27、维护一个自己的Time类，可以使游戏暂停更容易实现做一个“Time.DeltaTime”和“”Time.TimeSinceLevelLoad“的包装，用来实现暂停和游戏速度缩放。

111、这使用起来略显麻烦，但是当对象运行在不同的时钟速率下的时候就方便多了（例如界面动画和游戏内动画）。

112、生成对象28、不要让游戏运行时生成的对象搞乱场景层次结构在游戏运行时，为动态生成的对象设置好它们的父对象，可以让你更方便的查找。你可以使用一个空的对象，或者一个没有行为的单件来简化代码中的访问。

113、可以给这个对象命名为”DynamicObjects“。

114、类设计29、使用单件（Singleton）模式

115、从下面这个类派生的所有类，将自动获得单件功能：

116、 public class SingletonT : MonoBehaviour where T : MonoBehaviour{ protected static T instance; /** Returns the instance of this singleton. */ public static T Instance { get { if(instance==null) { instance=(T) FindObjectOfType(typeof(T)); if (instance==null) { Debug.LogError(”An instance of “ + typeof(T) + ” is needed in the scene, but there is none.“); } } return instance; } }}单件可以作为一些管理器，

117、对于那些非唯一的prefab实例使用单件管理器（例如Player）。不要为了坚持这条原则把类的层次关系复杂化，宁愿在你的GameManager（或其他合适的管理器中）中持有一个它们的引用。

118、对于外部经常使用的共有变量和方法定义为static，这样你可以这样简便的书写”GameManager.Player“，而不用写成”GameManager.Instance.player“。

119、 30、在组件中不要使用public成员变量，除非它需要在inspector中调节

120、除非需要设计师（策划or美术）去调节的变量，特别是它不能明确表明自己是做什么的变量，不要声明为public。如果在这些特殊情况下，无法避免，则可使用两个甚至四个下划线来表明不要从外部调节它，例如：

121、 public float __aVariable;

122、 31、把界面和游戏逻辑分开这一条本质上就是指的MVC模式。

123、所有的输入控制器，只负责向相应的组件发送命令，让它们知道控制器被调用了。举一个控制器逻辑的例子，一个控制器根据玩家的状态来决定发送哪个命令。但是这样并不好（例如，如果你添加了多个控制器，

124、那将会导致逻辑重复）。相反的，玩家对象应该根据当前状态（例如减速、惊恐）来设置当前的速度，并根据当前的面朝向来计算如何向前移动。控制器只负责做他们自己状态相关的事情，控制器不改变玩家的状态，

125、因此控制前甚至可以根本不知道玩家的状态。另外一个例子，切换武器。正确的方法是，玩家有一个函数：”SwitchWeapon(Weapon newWeapon)“供GUI调用。

126、 GUI不应该维护所有对象的Transform和他们之间的父子关系。

127、所有界面相关的组件，只负责维护和处理他们自己状态相关的数据。例如，显示一个地图，GUI可以根据玩家的位移计算地图的显示。但是，这是游戏状态数据，它不属于GUI。GUI只是显示游戏状态数据，

128、这些数据应该在其他地方维护。地图数据也应该在其他地方维护（例如GameManager）。

129、游戏玩法对象不应该关心GUI。有一个例外是处理游戏暂停（可能是通过控制Time.timeScale，其实这并不是个好主意）。游戏玩法对象应该知道游戏是否暂停。但是，这就是全部了。另外，

130、不要把GUI组件挂到游戏玩法对象上。

131、这么说吧，如果你把所有的GUI类都删了，游戏应该可以正确编译。

132、你还应该达到：在不需要重写游戏逻辑的前提下，重写GUI和输入控制。

133、 32、分离状态控制和簿记变量簿记变量只是为了使用起来方便或者提高查找速度，并且可以根据状态控制来覆盖。将两者分离可以简化：

134、保存游戏状态

135、调试游戏状态

136、实现方法之一是为每个游戏逻辑定义一个”SaveData“类，例如：

137、 [Serializable]PlayerSaveData{ public float health; //public for serialisation, not exposed in inspector} Player{ //. bookkeeping variables //Don't expose state in inspector. State is not tweakable. private PlayerSaveData playerSaveData; }

138、 33、分离特殊的配置假设我们有两个敌人，它们使用同一个Mesh，但是有不同的属性设置（例如不同的力量、不同的速度等等）。有很多方法来分离数据。下面是我比较喜欢的一种，特别是对于对象生成或者游戏存档时，

139、会很好用。（属性设置不是状态数据，而是配置数据，所以我们不需要存档他们。当对象加载或者生成是，属性设置会自动加载。）

140、为每一个游戏逻辑类定义一个模板类。例如，对于敌人，我们来一个”EnemyTemplate“，所有的属性设置变量都保存在这个类中。

141、在游戏逻辑的类中，定义一个上述模板类型的变量。

142、制作一个敌人的Prefab，以及两个模板的Prefab：”WeakEnemyTemplate“和”StrongEnemyTemplate“。

143、在加载或者生成对象是，把模板变量正确的复制。

144、这种方法可能有点复杂（在一些情况下，可能不需要这样）。

145、举个例子，最好使用泛型，我们可以这样定义我们的类：

146、 public class BaseTemplate{ .} public class ActorTemplate : BaseTemplate{ .} public class EntityEntityTemplateType where EntityTemplateType : BaseTemplate{ EntityTemplateType template; .} public class Actor : Entity ActorTemplate{ .}

147、 34、除了显示用的文本，不要使用字符串特别是不要用字符串作为对象或者prefab等等的ID标识。一个很遗憾的例外是动画系统，需要使用字符串来访问相应的动画。

148、 35、避免使用public的数组举例说明，不要定义一个武器的数组，一个子弹的数组，一个粒子的数组，这样你的代码看起来像这样：

149、 public void SelectWeapon(int index){ currentWeaponIndex=index; Player.SwitchWeapon(weapons[currentWeapon]);} public void Shoot(){ Fire(bullets[currentWeapon]); FireParticles(particles[currentWeapon]); }

150、这在代码中还不是什么大问题，但是在Inspector中设置他们的值的时候，就很难不犯错了。

151、我们可以定义一个类，来封装这三个变量，然后使用一个它的实例数组：

152、 [Serializable]public class Weapon{ public GameObject prefab; public ParticleSystem particles; public Bullet bullet;} 这样代码看起来很整洁，

153、 36、在结构中避免使用数组举个例子，一个玩家可以有三种攻击形式，每种使用当前的武器，并发射不同的子弹、产生不同的行为。

154、你可以把三个子弹作为一个数组，并像下面这样组织逻辑：

155、 public void FireAttack(){ ///behaviour Fire(bullets[0]);} public void IceAttack(){ ///behaviour Fire(bullets[1]);} public void WindAttack(){ ///behaviour Fire(bullets[2]);} 使用枚举值可以让代码看起来更好一点：

156、 public void WindAttack(){ ///behaviour Fire(bullets[WeaponType.Wind]);}

157、但是这对Inspector一点也不好。

158、最好使用单独的变量，并且起一个好的变量名，能够代表他们的内容的含义。使用下面这个类会更整洁。

159、 [Serializable]public class Bullets{ public Bullet FireBullet; public Bullet IceBullet; public Bullet WindBullet;}这里假设没有其他的Fire、Ice、Wind的数据。

160、 37、把数据组织到可序列化的类中，可以让inspector更整洁有些对象有一大堆可调节的变量，这种情况下在Inspector中找到某个变量简直就成了噩梦。为了简化这种情况，可以使用一下的步骤：

161、把这些变量分组定义到不同的类中，并让它们声明为public和serializable；

162、在一个主要的类中，把上述类的实例定义为public成员变量；

163、不用在Awake或者Start中初始化这些变量，因为Unity会处理好它们；

164、你可以定义它们的默认值；

165、这可以把变量分组到Inspector的分组页签中，方便管理。

166、 [Serializable]public class MovementProperties //Not a MonoBehaviour!{ public float movementSpeed; public float turnSpeed=1; //default provided} public class HealthProperties //Not a MonoBehaviour!{ public float maxHealth; public float regenerationRate;} public class Player : MonoBehaviour{ public MovementProperties movementProeprties; public HealthPorperties healthProeprties;}

167、文本38、如果你有很多的剧情文本，那么把他们放到一个文件里面。不要把他们放到Inspector的字段中去编辑。这些需要做到不打开Unity，也不用保存Scene就可以方便的修改。

168、 39、如果你计划实现本地化，那么把你的字符串分离到一个统一的位置。有很多种方法来实现这点。例如，定义一个文本Class，为每个字符串定义一个public的字符串字段，并把他们的默认值设为英文。

169、其他的语言定义为子类，然后重新初始化这些字段为相应的语言的值。

170、　另外一种更好的技术（适用于文本很大或者支持的语言数量众多），可以读取几个单独的表单，然后提供一些逻辑，根据所选择的语言来选取正确的字符串。

171、测试与调试40、实现一个图形化的Log用来调试物理、动画和AI。这可以显着的加速调试工作。详见这里。

172、 41、实现一个HTML的Log。在很多情况下，日志是非常有用的。拥有一个便于分析的Log（颜色编码、有多个视图、记录屏幕截图等）可以使基于Log的调试变动愉悦。详见这里。

173、 42、实现一个你自己的帧速率计算器。没有人知道Unity的FPS计算器在做什么，但是肯定不是计算帧速率。实现一个你自己的，让数字符合直觉并可视化。

174、 43、实现一个截屏的快捷键。很多BUG是图形化的，如果你有一个截图，就很容易报告它。一个理想的系统，应该在PlayerPrefes中保存一个计数，并根据这个计数，

175、使得所有成功保存的截屏文件都不被覆盖掉。截屏文件应该保存在工程文件夹之外，这可以防止人们不小心把它提交到版本库中。

176、 44、实现一个打印玩家坐标的快捷键。这可以在汇报位置相关的BUG时明确它发生在世界中的什么位置，这可以让Debug容易一些。

177、 45、实现一些Debug选项，用来方便测试。一些例子：

178、解锁所有道具；

179、关闭所有敌人；

180、关闭GUI；

181、让玩家无敌；

182、关闭所有游戏逻辑；

183、 46、为每一个足够小的团队，创建一个适合他们的Debug选项的Prefab。

184、设置一个用户标识文件，单不要提交到版本库，在游戏运行时读取它。下面是原因：

185、团队的成员不会因为意外的提交了自己的Debug设置而影响到其他人。

186、修改Debug设置不需要修改场景。

187、 47、维护一个包含所有游戏元素的场景。

188、例如，一个场景，包括所有的敌人，所有可以交互的对象等等。这样可以不用玩很久，而进行全面的功能测试。

189、 48、定义一些Debug快捷键常量，并把他们保存在统一的地方。Debug键通常（方便起见）在一个地方来处理，就像其他的游戏输入一样。为了避免快捷键冲突，在一个中心位置定义所有常量。一种替代方案是，

190、在一个地方处理所有按键输入，不管他是否是Debug键。（负面作用是，这个类可能需要引用更多的其他对象）

191、文档49、为你的设置建立文档。

192、代码应该拥有最多的文档，但是一些代码之外的东西也必须建立文档。让设计师们通过代码去看如果进行设置是浪费时间。把设置写入文档，可以提高效率（如果文档的版本能够及时更新的话）。

193、用文档记录下面这些：

194、 Layer的使用（碰撞、检测、射线检测——本质上说，什么东西应该在哪个Layer里）；

195、 Tag的使用；

196、 GUI的depth层级（说什么应该显示在什么之上）；

197、惯用的处理方式；

198、 Prefab结构；

199、动画Layer。

200、命名规则和目录结构50、遵从一个命名规范和目录结构，并建立文档命名和目录结构的一致性，可以方便查找，并明确指出什么东西在哪里。

201、你很有可能需要创建自己的命名规则和目录结构，下面的例子仅供参考。

202、普遍的命名规则

203、名字应该代表它是什么，例如鸟就应该叫做Bird。

204、选择可以发音、方便记忆的名字。如果你在制作一个玛雅文化相关的游戏，不要把关卡命名为QuetzalcoatisReturn。

205、保持唯一性。如果你选择了一个名字，就坚持用它。

206、使用Pascal风格的大小写，例如ComplicatedVerySpecificObject。

207、不要使用空格，下划线，或者连字符，除了一个例外（详见为同一事物的不同方面命名一节）。

208、不要使用版本数字，或者标示他们进度的名词（WIP、final）。

209、不要使用缩写：DVamp@W应该写成DarkVampire@Walk。

210、使用设计文档中的术语：如果文档中称呼一个动画为Die，那么使用DarkVampire@Die，而不要用DarkVampire@Death。

211、保持细节修饰词在左侧：DarkVampire，而不是VampireDark；PauseButton，而不是ButtonPaused。举例说明，在Inspector中查找PauseButton，

212、比所有按钮都以Button开头方便。（很多人倾向于相反的次序，认为那样名字可以自然的分组。然而，名字不是用来分组的，目录才是。名字是用来在同一类对象中可以快速辨识的。）

213、为一个序列使用同一个名字，并在这些名字中使用数字。例如PathNode0, PathNode1。永远从0开始，而不是1。

214、对于不是序列的情况，不要使用数字。例如Bird0, Bird1, Bird2，本应该是Flamingo, Eagle, Swallow。

215、为临时对象添加双下划线前缀，例如__Player_Backup。

216、为同一事物的不同方面命名在核心名称后面添加下划线，后面的部分代表哪个方面。例如

217、 GUI中的按钮状态：EnterButton_Active、EnterButton_Inactive

218、贴图： DarkVampire_Diffuse, DarkVampire_Normalmap

219、天空盒：JungleSky_Top, JungleSky_North

220、 LOD分组：DarkVampire_LOD0, DarkVampire_LOD1

221、结构场景组织、工程目录、脚本目录应该使用相似的模式

以上就是unity教程这篇文章的一些介绍，希望对大家有所帮助。