刚开始学习Unity3D时间不长,在看各种资料。除了官方的手册以外,其他人的经验也是非常有益的。偶尔看到老外这篇文章,觉得还不错,于是翻译过来和大家共享。
这些技巧不可能适用于每个项目。
所有的Asset都应该只有一个唯一的版本。如果你真的需要一个分支版本的Prefab、Scene或是Mesh,那你要制定一个非常清晰的流程,来确定哪个是正确的版本。错误的分支应该起一个特别的名字,例如双下划线前缀:__MainScene_Backup。Prefab版本分支需要一个特别的流程来保证安全(详见Prefabs一节)。
修改之后,Second Copy和Clean Copy都应该被更新和测试。大家都不要修改自己的Clean Copy。这对于测试Asset丢失特别有用。
Unity不是一个完美的关卡编辑器。例如,我们使用TuDee来创建3D Tile-Based的游戏,这使我们可以获得对Tile友好的工具的益处(网格约束,90度倍数的旋转,2D视图,快速Tile选择等)。从一个XML文件来实例化Prefab也很简单。详见Guerrilla Tool Development。
这是一种很奇妙的技术:
你仍就可以使用Unity作为关卡编辑器(尽管你用不着了)。你需要写一些你的数据的序列化和反序列化的代码,并实现在编辑器和游戏运行时加载关卡、在编辑器中保存关卡。你可能需要模仿Unity的ID系统来维护对象之间的引用关系。
实现自定义的Inspector是很直截了当的,但是Unity的系统有很多的缺点:
仔细的组织场景,就可以方便的找到任何对象。
如果位置对于这个对象不重要,那么就把他放到原点。这样你就不会遇到处理Local Space和World Space的麻烦,代码也会更简洁。
通常应该由控件的Layout父对象来控制Offset;它们不应该依赖它们的爷爷节点的位置。位移不应该互相抵消来达到正确显示的目的。做基本上要防止了下列情况的发生:
父容器被放到了(100,-50),而字节点应该在(10,10),所以把他放到(90,60)[父节点的相对位置]。
这种错误通常放生在容器不可见时。
这样可以更方便的把对象放到地面上,并且在游戏逻辑中,可以把世界作为2D空间来处理(如果合适的话),例如AI和物理模拟。
这将大大的降低测试的时间。为了达到所有场景可运行,你需要做两件事:
首先,如果需要前面场景运行产生的一些数据,那么要模拟出它们。
其次,生成在场景切换时必要保存的对象,可以是这样:
登录后复制
myObject = FindMyObjectInScene();
if (myObjet == null)
{
myObject = SpawnMyObject();
}
1.2.3.4.5.6.
这可以使你方便的把角色或者其他对象精确的放到地板上。如果合适的话,它也可能使得游戏逻辑、AI、甚至是物理使用2D逻辑来表现3D。
对于所有具有面朝向的对象(例如角色)都应该遵守这一条。在统一面朝向的前提下,很多算法可以简化。
请美术把所有导入的缩放系数设置为1,并且把他们的Transform的Scale设置为1,1,1。可以使用一个参考对象(一个Unity的Cube)来做缩放比较。为你的游戏选择一个世界的单位系数,然后坚持使用它。
设置这个平面面朝向Z轴正向,可能简化Billboard和GUI创建。
只有场景中的“目录”对象不使用Prefab。甚至是那些只使用一次的唯一对象也应该使用Prefab。这样可以在不动用场景的情况下,轻松修改他们。(一个额外的好处是,当你使用EZGUI时,这可以用来创建稳定的Sprite Atlases)
如果你有两种敌人的类型,并且只是属性有区别,那么为不同的属性分别创建Prefab,然后链接他们。这可以:
如果你有很多敌人的类型,那么也不要在编辑器中使用特殊的实例。一种可选的方案是程序化处理它们,或者为所有敌人使用一个核心的文件/Prefab。使用一个下拉列表来创建不同的敌人,或者根据敌人的位置、玩家的进度来计算。
当Prefab放置到场景中时,它们的链接关系是被维护的,而实例的链接关系不被维护。尽可能的使用Prefab之间的链接可以减少场景创建的操作,并且减少场景的修改。
如果你确实需要在实例之间链接,那么应该在程序代码中去创建。例如,Player对象在Start时需要把自己注册到GameManager,或者GameManager可以在Start时去查找Player对象。
对于需要添加脚本的Prefab,不要用Mesh作为根节点。 当你需要从Mesh创建一个Prefab时,首先创建一个空的GameObject作为父对象,并用来做根节点。把脚本放到根节点上,而不要放到Mesh节点上。使用这种方法,当你替换Mesh时,就不会丢失所有你在Inspector中设置的值了。
使用互相链接的Prefab来实现Prefab嵌套。 Unity并不支持Prefab的嵌套,在团队合作中第三方的实现方案可能是危险的,因为嵌套的Prefab之间的关系是不明确的。
我们用一个名为Player的Prefab来讲解这个过程。
用下面这个流程来修改Player:
不要把新复制的命名为Player_New,然后修改它。
有些情况可能更复杂一些。例如,有些修改可能涉及到两个人,上述过程有可能使得场景无法工作,而所有人必须停下来等他们修改完毕。如果修改能够很快完成,那么还用上面这个流程就可以。如果修改需要花很长时间,则可以使用下面的流程:
这可以使你方便的实现一些通用函数,例如类型安全的Invoke,或者是一些更复杂的调用(例如random等等)。
定义一个委托任务(delegate Task),用它来定义需要调用的方法,而不要使用字符串属性方法名称,例如:
登录后复制
public void Invoke(Task task, float time)
{
Invoke(task.Method.Name, time);
}
1.2.3.4.
有些时候把获得组件、查找对象实现在一个组件的接口中会很方便。
下面这种实现方案使用了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;
}
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.
登录后复制
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;
}
...
}
1.2.3.4.5.6.7.8.9.10.11.
有些时候强制性组件依赖(通过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;
}
1.2.3.4.5.6.7.8.9.10.11.12.
在很多情况下,某件事并不只有一个惯用手法。在这种情况下,在项目中明确选择其中的一个来使用。下面是原因:
几组风格的例子:
做一个“Time.DeltaTime”和""Time.TimeSinceLevelLoad"的包装,用来实现暂停和游戏速度缩放。这使用起来略显麻烦,但是当对象运行在不同的时钟速率下的时候就方便多了(例如界面动画和游戏内动画)。
在游戏运行时,为动态生成的对象设置好它们的父对象,可以让你更方便的查找。你可以使用一个空的对象,或者一个没有行为的单件来简化代码中的访问。可以给这个对象命名为“DynamicObjects”。
从下面这个类派生的所有类,将自动获得单件功能:
登录后复制
public class Singleton<T> : 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;
}
}
}
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.
单件可以作为一些管理器,例如ParticleManager或者AudioManager亦或者GUIManager。
除非需要设计师(策划or美术)去调节的变量,特别是它不能明确表明自己是做什么的变量,不要声明为public。如果在这些特殊情况下,无法避免,则可使用两个甚至四个下划线来表明不要从外部调节它,例如:
登录后复制
public float __aVariable;
1.
这一条本质上就是指的MVC模式。
所有的输入控制器,只负责向相应的组件发送命令,让它们知道控制器被调用了。举一个控制器逻辑的例子,一个控制器根据玩家的状态来决定发送哪个命令。但是这样并不好(例如,如果你添加了多个控制器,那将会导致逻辑重复)。相反的,玩家对象应该根据当前状态(例如减速、惊恐)来设置当前的速度,并根据当前的面朝向来计算如何向前移动。控制器只负责做他们自己状态相关的事情,控制器不改变玩家的状态,因此控制前甚至可以根本不知道玩家的状态。另外一个例子,切换武器。正确的方法是,玩家有一个函数:“SwitchWeapon(Weapon newWeapon)”供GUI调用。GUI不应该维护所有对象的Transform和他们之间的父子关系。
所有界面相关的组件,只负责维护和处理他们自己状态相关的数据。例如,显示一个地图,GUI可以根据玩家的位移计算地图的显示。但是,这是游戏状态数据,它不属于GUI。GUI只是显示游戏状态数据,这些数据应该在其他地方维护。地图数据也应该在其他地方维护(例如GameManager)。
游戏玩法对象不应该关心GUI。有一个例外是处理游戏暂停(可能是通过控制Time.timeScale,其实这并不是个好主意)。游戏玩法对象应该知道游戏是否暂停。但是,这就是全部了。另外,不要把GUI组件挂到游戏玩法对象上。
这么说吧,如果你把所有的GUI类都删了,游戏应该可以正确编译。
你还应该达到:在不需要重写游戏逻辑的前提下,重写GUI和输入控制。
簿记变量只是为了使用起来方便或者提高查找速度,并且可以根据状态控制来覆盖。将两者分离可以简化:
实现方法之一是为每个游戏逻辑定义一个”SaveData“类,例如:
登录后复制
[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;
}
1.2.3.4.5.6.7.8.9.10.11.12.13.
假设我们有两个敌人,它们使用同一个Mesh,但是有不同的属性设置(例如不同的力量、不同的速度等等)。有很多方法来分离数据。下面是我比较喜欢的一种,特别是对于对象生成或者游戏存档时,会很好用。(属性设置不是状态数据,而是配置数据,所以我们不需要存档他们。当对象加载或者生成是,属性设置会自动加载。)
这种方法可能有点复杂(在一些情况下,可能不需要这样)。
举个例子,最好使用泛型,我们可以这样定义我们的类:
登录后复制
public class BaseTemplate
{
...
}
public class ActorTemplate : BaseTemplate
{
...
}
public class Entity<EntityTemplateType> where EntityTemplateType : BaseTemplate
{
EntityTemplateType template;
...
}
public class Actor : Entity <ActorTemplate>
{
...
}
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.
特别是不要用字符串作为对象或者prefab等等的ID标识。一个很遗憾的例外是动画系统,需要使用字符串来访问相应的动画。
举例说明,不要定义一个武器的数组,一个子弹的数组,一个粒子的数组,这样你的代码看起来像这样:
登录后复制
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.8.9.10.11.
这在代码中还不是什么大问题,但是在Inspector中设置他们的值的时候,就很难不犯错了。
我们可以定义一个类,来封装这三个变量,然后使用一个它的实例数组:
登录后复制
[Serializable]
public class Weapon
{
public GameObject prefab;
public ParticleSystem particles;
public Bullet bullet;
}
1.2.3.4.5.6.7.
这样代码看起来很整洁,但是更重要的是,在Inspector中设置时就不容易犯错了。
举个例子,一个玩家可以有三种攻击形式,每种使用当前的武器,并发射不同的子弹、产生不同的行为。
你可以把三个子弹作为一个数组,并像下面这样组织逻辑:
登录后复制
public void FireAttack()
{
/// behaviour
Fire(bullets[0]);
}
public void IceAttack()
{
/// behaviour
Fire(bullets[1]);
}
public void WindAttack()
{
/// behaviour
Fire(bullets[2]);
}
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.
使用枚举值可以让代码看起来更好一点:
登录后复制
public void WindAttack()
{
/// behaviour
Fire(bullets[WeaponType.Wind]);
}
1.2.3.4.5.
但是这对Inspector一点也不好。
最好使用单独的变量,并且起一个好的变量名,能够代表他们的内容的含义。使用下面这个类会更整洁。
登录后复制
[Serializable]
public class Bullets
{
public Bullet FireBullet;
public Bullet IceBullet;
public Bullet WindBullet;
}
1.2.3.4.5.6.7.
这里假设没有其他的Fire、Ice、Wind的数据。
有些对象有一大堆可调节的变量,这种情况下在Inspector中找到某个变量简直就成了噩梦。为了简化这种情况,可以使用一下的步骤:
这可以把变量分组到Inspector的分组页签中,方便管理。
登录后复制
[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;
}
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.
不要把他们放到Inspector的字段中去编辑。这些需要做到不打开Unity,也不用保存Scene就可以方便的修改。
有很多种方法来实现这点。例如,定义一个文本Class,为每个字符串定义一个public的字符串字段,并把他们的默认值设为英文。其他的语言定义为子类,然后重新初始化这些字段为相应的语言的值。
另外一种更好的技术(适用于文本很大或者支持的语言数量众多),可以读取几个单独的表单,然后提供一些逻辑,根据所选择的语言来选取正确的字符串。
这可以显著的加速调试工作。详见这里。
在很多情况下,日志是非常有用的。拥有一个便于分析的Log(颜色编码、有多个视图、记录屏幕截图等)可以使基于Log的调试变动愉悦。详见这里。
没有人知道Unity的FPS计算器在做什么,但是肯定不是计算帧速率。实现一个你自己的,让数字符合直觉并可视化。
很多BUG是图形化的,如果你有一个截图,就很容易报告它。一个理想的系统,应该在PlayerPrefes中保存一个计数,并根据这个计数,使得所有成功保存的截屏文件都不被覆盖掉。截屏文件应该保存在工程文件夹之外,这可以防止人们不小心把它提交到版本库中。
这可以在汇报位置相关的BUG时明确它发生在世界中的什么位置,这可以让Debug容易一些。
一些例子:
设置一个用户标识文件,单不要提交到版本库,在游戏运行时读取它。下面是原因:
例如,一个场景,包括所有的敌人,所有可以交互的对象等等。这样可以不用玩很久,而进行全面的功能测试。
Debug键通常(方便起见)在一个地方来处理,就像其他的游戏输入一样。为了避免快捷键冲突,在一个中心位置定义所有常量。一种替代方案是,在一个地方处理所有按键输入,不管他是否是Debug键。(负面作用是,这个类可能需要引用更多的其他对象)
代码应该拥有最多的文档,但是一些代码之外的东西也必须建立文档。让设计师们通过代码去看如果进行设置是浪费时间。把设置写入文档,可以提高效率(如果文档的版本能够及时更新的话)。
用文档记录下面这些:
命名和目录结构的一致性,可以方便查找,并明确指出什么东西在哪里。
你很有可能需要创建自己的命名规则和目录结构,下面的例子仅供参考。
场景组织、工程目录、脚本目录应该使用相似的模式。
登录后复制
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
...
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.
登录后复制
Cameras
Dynamic Objects
Gameplay
Actors
Items
...
GUI
HUD
PauseMenu
...
Management
Lights
World
Ground
Props
Structure
...
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.
登录后复制
ThirdParty
...
MyGenericScripts
Debug
Extensions
Framework
Graphics
IO
Math
...
MyGameScripts
Debug
Gameplay
Actors
Items
...
Framework
Graphics
GUI
...
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删