使用Unity的50个建议
关于这些建议
这些建议并不适用于所有的项目
- 这些建议是基于我与3-20人的小团队项目经验总结出来的
- 结构、可重复使用性、明晰度都是有价的——团队规模和项目规模决定了是否值得付这个价。
- 一些建议也许公然违抗了传统的Unity开发。例如：使用专业化的组合而不是使用实例就很不像Unity的作风，价格也很高。即使看上去挺疯狂的，但我还是看到了这些建议给开发者带来了利益。
过程方面
1.避免分支资产 对于任何资产我们应该只有一个版本。如果你非要把一个预设，场景，或网格分支开来，那么情遵循一个过程，这个过程必须清楚的表明哪一个才是正确的版本。错误的分支应该有一个显著的名字，例如，使用双下划线前缀__MainScene_Backup。预设的分支需要一个特定的过程来使其安全。（详见预设部分）
2.持有项目副本 任何一个使用版本控制的团队成员都应该持有项目的副本，用于测试检查。在变动之后，副本，这一干净的版本，应该更新并测试。任何人都不能对干净的副本做任何改变。当找回丢失的东西的时候，这一点就会发挥作用。
3.考虑使用外部关卡工具来编辑关卡 Unity并不是完美的关卡编辑器。例如，我们曾经使用TuDee来为3D游戏建立关卡，这是个能让我们轻松建立砖块的工具（捕捉网格、多倍数的90度旋转、2D视图、快速选择砖块）。从XML文件转为预设的实例是简单的。你可以从GuerrillaTool Development获得更多的启发。
4.在XML中保存关卡而不是在场景中 这是一个极好的技术
- 它使我们不必重新设置每一个场景
- 它使装载更加迅速（在场景之间共享大部分对象的情况下）
- 它让合并场景更加容易（即使用Unity基于文本的场景，但太多的数据仍就导致合并在任何情况下都是不切实际的）
- 它使跟踪关卡的数据轨迹更为简单
当然你也可以使用Unity作为关卡编辑器（虽然你不需要），你需要写一些代码来序列化和反序列化你的数据，在编辑器内和运行的时候装载关卡，然后在编辑器里保存关卡。你可能还需要模仿Unity的ID系统来维护对象之间的参照。
5.编写自定义的检查代码 写自定义检查相当简单，但是Unity的系统有很多弊端
- 它不支持利用继承
- 它不支持定义字段类型关卡的检查组件，只支持类的关卡。例如，如果每个游戏对象都有字段类型SomeCoolType,你想在检查过程中以不同的描述显现出来，那你就需要为所有的类写检查的代码。
你可以彻底的重新执行检查系统来解决这些问题。用一些映像技巧，这并不想看起来那么难，具体方法将在文章末尾提供。
6.使用命名为空的游戏对象作为场景文件夹 仔细安排你的场景使它容易找到对象。、
7.在000条件下维护预设和文件夹（空的游戏对象） 如果一个转变专门用于定位一个对象，那么它应该在原点。这样，在本地和世界空间运行出错的风险就更小，代码也会更简单。
8.减少GUI组件的偏移 偏移量应该始终用在父组件的布局组件里；它们不应该依靠更上一级的组件定位。偏移量不应通过互相抵消来正确显示，这基本上是为了防止以下事件：
父容器定位在(100, -50)，子容器，应该定位在(10, 10)，然后定位在(90, 60)[相对于父容器]。
这种错误在容器隐藏，或者是根本没有可视化表现的情况下是常见。
9.把你的世界基准定义在y = 0。这样更容易把对象放在地面上，在游戏逻辑、AI以及物理方面把世界看成一个2D空间（适当时）。
10.让游戏的每个场景运行流畅。这大大减少了测试时间，要让所有的场景运行流畅，你需要做两件事：
首先，你要找到一种方法仿制所有的数据，这些数据在之前下载的场景里是需要但却是不可用的。
第二，产生的对象必须坚持场景负载之间的下列语句
myObject= FindMyObjectInScene();
if(myObjet == null)
{
myObject = SpawnMyObject();
}
美术方面
11.把人物和站立物体的支点放在底部，而不是中心。这样易于将人物和物体精准的放在地面上。同时在游戏逻辑、AI以及物理方面，这也能让3D工程像2D一样简单，当然是在某些合适的情况下。
12. 让所有的网格面向同一方向（正或负Z轴）。这适用于那些有朝向概念的人物或者事物的网格。如果所有的东西都面朝一个方向，那么许多算法都可以得到简化。
13.从一开始就确定尺寸。
14.制作二聚平面用以GUI组件和手动创建粒子。
15.制作和使用的测试技术
- 网格
- 各种纯的颜色：白色，黑色着色试验，50%的灰，红，绿，蓝，黄，洋红，青蓝。
- 阴影检测梯度：黑色到白色，红色，绿色，红色，蓝色，绿色，蓝色。
- 黑白棋盘
- 平滑和崎岖的法线贴图
- 照明设备（如预制）快速建立测试场景
16.对于一切都可以使用预制。游戏场景中的唯一对象不应该是预制，而应该是文件夹。即使是只使用一次的特殊对象也应该是预制。这使得不改变场景也可以轻松实现转变。（这也让使用EZGUI构建sprite地图时更加可靠）
17.使用不同的预制来专业化，不使用专门的实例。如果你有两个类型的敌人，他们的唯一区别是他们的财产不同，那么对财产分别作预制，然后再将其链接，这让下面两点成为可能：
- 在一个地方对任何类型做改变
- 在不改变场景的情况下做出变化
如果你有太多的敌人类型，那么就不用在编辑器重做出专业化实例了。一种代替方法是做程序，或者使用对所有的敌人使用一个核心文件/预制。一个下降动作可以用于不同的敌人，一个运算可以基于敌人位置或玩家进程。
18.将预制之间链接，实例之间不链接。当把预制拖放到场景时，预制的链接可以得到保证，而实例则不可以。链接到预制可以在任何时候减少场景的建立，也可以减少场景变化的需求。
19.尽可能在实例之间自动建立连接。如果你需要链接实例，建立编程链接。例如，玩家预制可以在GameManager启动时自己注册，或者GameManager在启动时可以找到玩家预制实例。
- 如果你想添加其他脚本的话，就不要把网格放在预制的根源。
- 用链接预制代替嵌套预制。
20.使用安全的流程来分支预制。我们以玩家预制为例来解释：
如下是一个有风险的改变玩家预制的方法：
1. 复制玩家预制
2. 重命名该副本 __Player_Backup
3. 改变玩家预制
4. 如果一切顺利，删除 __Player_Backup
不要把把副本命名为Player_New，并且改变它！
有些情况更加复杂。例如，某个改变可能涉及两个人，按照上述步骤直到Person 2完成的时候，可能会破坏掉所有人的工作场景。如果足够快的话，仍会是这样。因为变化需要的时间更长，你可以仿照下面的方法：
Person 1
1. 复制玩家预制
2. 重命名为__Player_WithNewFeature或者__Player_ForPerson2.
3. 在副本上修改，并且提交到Person 2
Person 2：
1. 在新预制上做修改
2. 复制玩家预制，命名为 __Player_Backup.
3. 拖动__Player_WithNewFeature的实例到场景
4. 拖动这个实例到原来的玩家预制
5. 如果一切顺利，删除__Player_Backup 和 __Player_WithNewFeature.
拓展组件和 MonoBehaviourBase
21.拓展你自己的基本单一行为，并推导出所有它的组件。这让你实现一些通用功能，如类的安全调用和其他更复杂的调用。
22.定义调用的安全方法，StartCoroutine和实例化。定义一个委托任务，并用它来定义不依赖于字符串名称的方法，例如：
public voidInvoke(Task task, float time)
{
Invoke(task.Method.Name, time);
}
23.使用共享界面的拓展组件。有时候可以很方便的得到执行某个界面的组件，或者使用组件找到对象。下面的执行使用typeof来代替这些功能的通用版本。通用版本不能使用这些接口，但是typeof可以。请参考：
//Definedin the common base class for all mono behaviours
publicI GetInterfaceComponent() where I : class
{
return GetComponent(typeof(I)) as I;
}
publicstatic List FindObjectsOfInterface() where I : class
{
MonoBehaviour[] monoBehaviours =FindObjectsOfType();
List list = new List();
foreach(MonoBehaviour behaviour inmonoBehaviours)
{
I component =behaviour.GetComponent(typeof(I)) as I;
if(component != null)
{
list.Add(component);
}
}
return list;
}
24.使用拓展组件使语法更加方便，例如
public staticclass CSTransform
{
public static voidSetX(this Transform transform, float x)
{
Vector3 newPosition =
new Vector3(x, transform.position.y,transform.position.z);
transform.position = newPosition;
}
...
}
25.使用备用的GetComponent以供选择。有时候强制组件依赖关系令人头疼（通过RequiredComponent）。例如：这使得在检查器中难以改变组件（即使它们是相同的基本类型）。作为替代品，当一个组件需要输出一条没有被发现的错误信息时，下面的GameObject拓展就可以使用了。
publicstatic T GetSafeComponent( this GameObject obj) where T : MonoBehaviour
{
T component = obj.GetComponent();
if(component == null)
{
Debug.LogError("Expected to findcomponent of type "
+ typeof(T) + " but foundnone", obj);
}
return component;
}
术语/语法
26.避免使用不同的语法来做同一件事。许多情况下，可以有多种语法来做一件事。这时，请选择一种贯穿项目的始终，因为：
- 有些语法不能很好地协同工作。只使用一种语法使得设计能够朝着一个方向进行，并且不适合其他语法。
- 从始至终使用一种语法能让团队成员更好地了解项目进程，可以让架构和代码更容易理解，更少出错。
例子：
·协同VS.状态机。
·嵌套问题VS.相关问题VS.预制
·数据分离策略
·2D游戏状态中使用sprites的方法
·预制结构
·生产策略。
·查找对象的方法：按类型VS.名称VS.标记VS.层VS.参考（“链接”）。
·组对象的方法：类型VS.名称VS.标签VS.层VS.数组引用（“链接”）。
·寻找对象VS.自注册
·控制执行规则（使用Unity的执行规则设置VS.产生逻辑VS.清醒/启动和更新/晚更新依赖VS.手工方法VS.任何规则结构）
·选择对象/位置/用鼠标选择目标：选择管理VS.自我管理
·保持变化场景之间的数据：通过PlayerPrefs，或者加载一个新场景时不会被破坏的物体
·结合方式（混合，添加和分层）动画
产生对象
28.游戏运行时，不要让产生对象弄乱你的层次。当游戏运行时，在场景对象中设置他们的父对象将使东西更容易找到。你可以使用一个空的游戏对象，甚至是单例来使访问代码更容易。将这个对象成为DynamicObjects。
数据结构设计
29.为方便起见请使用单例下述可以使任何数据自动继承单例
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public class Singleton
{
protectedstatic T instance;
/**
Returnsthe instance of this singleton.
*/
publicstatic 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;
}
}
}
|
单例对管理很有用，比如粒子管理、音频管理、GUI管理
30.对于组件，绝不要公开那些不应在检查面板中调整的变量。否则，它建个可能被设计师改变，尤其是在不清楚它的用处的时候。在某些罕见的情况下，这是不可避免的。在这种情况下，请使用双下划线甚至四个下划线来作为变量的名称前缀，以警告那些想要做修改的人。
public float __aVariable;
31.把界面从游戏逻辑中分离出来
32.分离状态和簿记簿记变量是为了高效、方便，并可从状态中恢复。通过分离这些，你可以更容易的：
·保存游戏状态
·调试游戏状态
一种方法是：为每个游戏逻辑类定义一个保存数据类
|
1
2
3
4
5
6
7
8
9
10
11
|
[Serializable]
PlayerSaveData
{
public float health;
//public forserialisation, not exposed in inspector
}
Player
{
//... bookkeeping variables
//Don’t expose state in inspector. State isnot tweakable.
private PlayerSaveData playerSaveData;
}
|
33.独立专业化设置。考虑两个有着相同网格，但Tweakables不同（例如不同强度和不同速度）的敌人，有不同的方式来分离数据。我倾向于下述方式，特别是当对象被催生或者游戏保存的时候。（Tweakables不是状态数据，而是配置数据，所以不需要保存，当加载或催生对象的时候，Tweakables会自动分别加载）
·定义每个游戏逻辑类的模板类。例如，对敌人，我们还定义了Enemytemplate。所有的分化Tweakables都存储在Enemytemplate
·在游戏逻辑类里，定义一个变量的模板类型。
·做一个敌人的预制件，和两个模板预制weakenemytemplate和strongenemytemplate。
·加载或催生对象时，设置合适模板的模板变量。
这种方法可以变得相当复杂的（有时是不必要的，复杂的，所以要小心！）。
例如，为了更好地利用通用多态性，我们可以这样定义类：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
public class BaseTemplate
{
...
}
public class ActorTemplate : BaseTemplate
{
...
}
public class Entity
{
EntityTemplateType template;
...
}
public class Actor : Entity
{
...
}
|
34.字符串不要用于显示文字之外的任何事。特别是，不要使用字符串识别对象或预制等。动画是个不幸的例外，通常访问它们的字符串名称。
35.避免使用公共指数耦合阵列。例如，不要定义武器阵列，子弹阵列，和颗粒阵列，你的代码看起来像这样：
|
1
2
3
4
5
6
7
8
9
10
11
|
public void SelectWeapon(int index)
{
currentWeaponIndex = index;
Player.SwitchWeapon(weapons[currentWeapon]);
}
public void Shoot()
{
Fire(bullets[currentWeapon]);
FireParticles(particles[currentWeapon]);
}
|
这里的问题并不是完全在于代码，而是在检查面板中不犯错误地设置出来。
相反，定义一个类，封装三个变量，使一个数组：
|
1
2
3
4
5
6
7
|
[Serializable]
public class Weapon
{
publicGameObject prefab;
publicParticleSystem particles;
publicBullet bullet;
}
|
这段代码看上去更整洁，最重要的是，在检查面板里建立数据时不容易出错。
36.避免使用序列以外的数组结构。例如，一个玩家可能有三种攻击类型，每个都使用当前的武器，但是产生不同的子弹和行为。你可能想把三个子弹放在一个数组中，用这种逻辑：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
public void FireAttack()
{
///behaviour
Fire(bullets[0]);
}
public void IceAttack()
{
///behaviour
Fire(bullets[1]);
}
public void WindAttack()
{
///behaviour
Fire(bullets[2]);
}
枚举可以让代码看起来更好…
public void WindAttack()
{
///behaviour
Fire(bullets[WeaponType.Wind]);
}
|
但是不是在检查面板中。
最好使用独立的变量，名称可以有助于显示应该放入哪些内容。使用一个类来让它整洁。
|
1
2
3
4
5
6
7
|
[Serializable]
public class Bullets
{
publicBullet FireBullet;
public Bullet IceBullet;
public Bullet WindBullet;
}
|
PS：假设没有其他的火、冰、风等数据。
37.在序列化类中将数据分组以使事物在检查面板中看起来更整洁。一些实体可能有几十个tweakables，这就使得在检查面板中寻找正确的变量成为一场噩梦。以下步骤会让事情变简单：
·对变量组定义独立的类，使其公开并序列化。
·在主类里，为如上定义的每一类型定义公共变量
·不要在Awake 或 Start初始化这些变量，因为他们是序列化的，Unity会处理那些。
·你可以像以前一样通过定义赋值指定缺省值
·这将在检查面板中将变量按可折叠单位分组，便于管理。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
[Serializable]
public class MovementProperties
//Not aMonoBehaviour!
{
public float movementSpeed;
public float turnSpeed = 1;
//default provided
}
public class HealthProperties
//Not aMonoBehaviour!
{
public float maxHealth;
public float regenerationRate;
}
public class Player : MonoBehaviour
{
public MovementProperties movementProeprties;
public HealthPorperties healthProeprties;
}
|
文本
38.如果你的故事文本很多，那么请将文本放在一个文件中。不要放在检视面板的编辑器里。要让它在不打开Unity的情况下就可以编辑，特别是在不用保存场景的情况下。
39.如果你打算本地化，把所有字符串独立到一个地方。方法很多，其一是定义每个字符串都有公共字符串字段的文本类，默认设置为英语。例如：其他语言子属于它，然后用语言赋值重新初始化字段。
更先进的技术将读取电子数据表，然后基于所选语言为选择正确的字符串提供逻辑。
测试和调试
40.执行图形记录器调试物理，动画，和AI，这可以使调试相当快。
41.执行HTML记录器。在某些情况下，记录仍然是有用的。记录可以更容易地解析（彩色编码，多个视图，记录截图），可以使日志调试更愉快。
42.执行你自己的FPS计数器。是的，没人知道Unity的FPS计数器到底测量什么，但不是帧速率。执行你自己的，这样数量就可以协调直觉和视觉检查了。
43.快捷键实现屏幕截图。许多bugs是可见的，并且通过图片可以更容易发现。
44.实施快捷方式打印玩家的世界位置。这易于发现bug的位置。
45.执行debug选项使测试更容易，例如
·解锁所有项目
·禁用敌人
·禁用GUI
·让玩家无敌
·禁用所有的游戏
46.对于足够小的团队，为每一个成员做一个有debug选项的预制。将用户标示符放在一个不被承认的文件里，并且在游戏运行时读取，原因是：
·团队成员偶尔会不承认他们的debug选项，还可能影响到别人。
·改变debug选项不改变场景
47.维持所有游戏元素的场景。例如：一个你可以与所有敌人，所有对象互动的场景等等。这可以很容易地测试功能，不用耗费太多精力。
48.为调试快捷键定义常量并保持固定的位置。
49.记录你的设置。绝大多数的文件都应该编码，但是某些东西应该记录在代码之外。让设计师通过设置找代码是在浪费时间。记录设置能提高效率（如果是最近的记录）。
按下列方式记录：
·层使用（碰撞，裁剪，和光线投射–本质，哪一层里应该有什么）
·标签使用
·GUI深度层（应该显示什么）
·场景设置
·语法偏好
·预制结构
·动画层
·命名标准和文件夹结构
50. 遵循文件的命名规则和文件夹结构。统一的命名和文件夹结构更利于查找和辨认。相信你也希望创建自己的命名规则和文件夹结构。这里提供一个例子供参考。
命名的一般原则：
1.是什么就叫什么。一只鸟就应该就应该叫做“Bird”。
2.选择容易发音和记住的名字。如果你在做玛雅语的游戏，不要命名QuetzalcoatisReturn。
3.保持一致。选了一个名字就坚持到底。
4.使用Pascal案例，就像这样： ComplicatedVerySpecificObject。不要使用空格、下划线或者连字符，但是也有一个例外（请参阅命名同一事物的不同方面）。
5.不要用版本号或者表示进程的词汇（WIP,final）。
6.不要用缩写：DVamp@W 应该是 DarkVampire@Walk。
7.在设计文件中使用术语。如果文件中把die animation称作Die，那么请用DarkVampire@Die,而不是DarkVampire@Death.
8.把特定描述放在左边。是DarkVampire而不是VampireDark；是PauseButton而不是 ButtonPaused。
9.有些名字会形成序列。在这些名字中使用数字。例如：PathNode0, PathNode1。要从0开始，而不是从1开始。
10.不会形成序列的名字就不要使用数字。比如Bird0, Bird1, Bird2应该被叫做Flamingo, Eagle, Swallow.
11.给临时对象命名请使用双下划线前缀__Player_Backup.
命名同一事物的不同方面
在核心名称与描述性事物之间使用下划线，例如
·GUI按钮状 EnterButton_Active, EnterButton_Inactive
·纹理 DarkVampire_Diffuse, DarkVampire_Normalmap
·天空盒 JungleSky_Top, JungleSky_North
·LOD组 DarkVampire_LOD0, DarkVampire_LOD1
不要使用本规则来区分不同类型的项目，例如rock_small，rock_large应该是smallrock，largerock。
结构
场景、工程文件夹以及脚本文件夹的组织应当遵循类似的模式。
文件夹结构
Materials
GUI
Effects
Meshes
Actors
DarkVampire
LightVampire
...
Structures
Buildings
...
Props
Plants
...
...
Plugins
Prefabs
Actors
Items
...
Resources
Actors
Items
...
Scenes
GUI
Levels
TestScenes
Scripts
Textures
GUI
Effects
...
场景结构
Cameras
Dynamic Objects
Gameplay
Actors
Items
...
GUI
HUD
PauseMenu
...
Management
Lights
World
Ground
Props
Structure
...
脚本文件夹结构
ThirdParty
...
MyGenericScripts
Debug
Extensions
Framework
Graphics
IO
Math
...
MyGameScripts
Debug
Gameplay
Actors
Items
...
Framework
Graphics
GUI
...
怎样重新执行Inspector Drawing
1.为所有的编辑定义基类
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
BaseEditor
where T :MonoBehaviour
{
override public void OnInspectorGUI()
{
T data = (T) target;
GUIContent label =
new
GUIContent();
label.text =
"Properties"
;
//
DrawDefaultInspectors(label, data);
if
(GUI.changed)
{
EditorUtility.SetDirty(target);
}
}
}
|
2.使用反射和递归来绘制组件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
public staticvoid DrawDefaultInspectors
where T :
new
()
{
EditorGUILayout.Separator();
Type type =
typeof
(T);
FieldInfo[] fields = type.GetFields();
EditorGUI.indentLevel++;
foreach(FieldInfo field
in
fields)
{
if
(field.IsPublic)
{
if
(field.FieldType ==
typeof
(int))
{
field.SetValue(target,EditorGUILayout.IntField(
MakeLabel(field), (int)field.GetValue(target)));
}
else
if
(field.FieldType ==
typeof
(float))
{
field.SetValue(target,EditorGUILayout.FloatField(
MakeLabel(field), (float)field.GetValue(target)));
}
///etc. for other primitive types
else
if
(field.FieldType.IsClass)
{
Type[] parmTypes =
new
Type[]{field.FieldType};
string methodName =
"DrawDefaultInspectors"
;
MethodInfo drawMethod =
typeof
(CSEditorGUILayout).GetMethod(methodName);
if
(drawMethod ==
null
)
{
Debug.LogError(
"No methodfound: "
+ methodName);
}
bool foldOut =
true
;
drawMethod.MakeGenericMethod(parmTypes).Invoke(
null
,
new
object[]
{
MakeLabel(field),
field.GetValue(target)
});
}
else
{
Debug.LogError(
"DrawDefaultInspectors doesnot support fields of type "
+
field.FieldType);
}
}
}
EditorGUI.indentLevel--;
}
|
上述方法使用下述帮助
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
private staticGUIContent MakeLabel(FieldInfo field)
{
GUIContent guiContent = newGUIContent();
guiContent.text =field.Name.SplitCamelCase();
object[] descriptions =
field.GetCustomAttributes(
typeof
(DescriptionAttribute),
true
);
if
(descriptions.Length > 0)
{
//just use the first one.
guiContent.tooltip =
(descriptions[0] asDescriptionAttribute).Description;
}
return
guiContent;
}
|
注意：它在类代码中使用注释，来在检查面板中产生工具提示
3.定义新的自定义编辑器
不幸的是，你仍然需要定义每个MonoBehaviour类。幸运的是，这些定义可以是空的；所有的实际工作都由基类来完成。
|
1
2
3
|
[CustomEditor(
typeof
(MyClass))]
public classMyClassEditor : BaseEditor
{}
|
理论上说这一步可以自动化，但是我还没有尝试过。
原文链接：http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/