Unity3D使用经验总结 优点篇

司格特

09年还在和其它小伙伴开发引擎的时候，Unity3D就初露头角。 当时就对这种基于组件式的设计结构很不
理解。 觉得拆分过于细致，同时影响效率。

而时至今日，UNITY3D已经成为了众多团队的首选3D引擎。 并且，随着Unity3D 4.3的发布，原生的2D支
持也让人大开眼界。虽然Unity3d的原生2D功能还有很长的路要走，但也阻挡不了它称霸当下。

2011年中，公司的引擎项目停止之后，我的目光便转到了U3D的身上，经过几番挣扎后，终于对基于组件
式的对象模型有了新的认识。 而如今，这种模式，成为了我最推崇的模式。 因为它能解决我在设计引擎对
象时的纠结。 而这些纠结，是我在先前的引擎开发中，一直不能优雅地解决的。

首先，我们来说说U3D的好处。可能总结得不够完善，如果有不足的地方，就表示我自己没有体验到。



声明：为了不打扰大家的雅兴，所以，这里只讲它的优点，想看缺点的朋友，请看此文章的姐妹篇 Unity3
D使用经验总结 缺点篇



一、可定制的IDE环境


U3D这种ALL IN ONE的设计思路，我在一个叫神咒的代码中见到过。 集所有编辑器于一身。 虽然神咒的编
辑器不能自由扩展，但由于是公司内部的引擎，所以，它的使用，也很方便。 比如，在场景中突然想要对
一个模型的材质进行编辑，则选中此模型，右键，弹出材质编辑器即可。  U3D的组件式思路，将这种关系
变得更加紧密。 你都感觉不到自己在使用一个材质编辑器。 你会觉得，你是在操作这个模型本身。 它的材
质，它的碰撞器，它的对象结构等等。

回想一开始进入游戏行业的时候，天天啃着代码。 当时觉得代码就是一切，各种认为很牛X的代码，都忍不
住读上一番。 而随着时间的推移，特别是经过项目的洗礼后。 突然发现编辑器是多么的重要。 就我做的第
一个页游来说，起手前两个星期，我们就做了动画编辑器，场景编辑器。而最终证明，因为这两个简陋的
编辑器，使我们后面的工作变得更加容易。

因此，一个好的引擎，必定得先有一个功能完备的编辑器。



二、基于Mono的开发脚本

C/C++无疑是图形界的宠儿，也没有人想过用另一种语言来替代它。即使是U3D，亦是如此。 但是，早期
使用C/C++编写的引擎，都理所当然地使用C/C++来作为上层逻辑的开发。 又有一些，采用了纯脚本的模
式。比如Python,LUA。 脚本的好处在于更低的编码成本（经过仔细研究，我发现，这是由于写脚本语言的
心态和写C++的心态导致的。 写C++的时候，总是想着代码的复用度，而在脚本的时候，很多时间会认为
，这个脚本，就是为这个对象服务的，那我就按照策划需求来写就可以了。 我想，这也是许多时候，脚本
语言存在的意义。特别是早期引擎中，使用脚本来处理一些关键的事件响应）。  而大家熟知的虚幻引擎以
及有一个名不见经转的Torque，则自己整了一套开发语言。 我想，它们的目的，就是为了使大家能够以一
种更安全的方式来编程， C++一不小心，则会带来内存和效率问题。 它的使用成本，人员成本其实是高
于其它语言的。  Mono C# JS,BOO的出现，再一次让大家的眼睛一亮，原来，引擎可以这样整。

Mono的桥接，使得高效的C++图形引擎与带GC的内存安全语言进行结合。不仅减少了安全隐患，也使得
大家编写跨平台代码时更佳容易。 同时，这类语言的反射机制，更适合做编辑器。而比起先前的一些DIY
语言和像LUA这样的小巧型语言，Mono使脚本编程可以进行DEBUG，而不单纯的靠PRINT输出。

这里就顺带说一下三个语言的区别

C# 这是我见过的大型项目中使用得最多的语言，也是我比较喜欢的语言。 因为它和C++很像，同时严格
的类型和语法检查。

JS 在帮一些朋友做小东西的时候，使用过这个语言，由于mono自带的提示功能，写起来还是挺顺手。 但
总给我一种摸不着头脑的感觉。 并且U3D给的JS，不是严格的JS，有些语法不支持，而有些语法又很特别。

BOO 完全没有使用过，貌似也很少有人使用。



三、基于组件的对象系统

这是一个我最喜欢的系统，我也使用irrlicht引擎山寨过，山寨的过程中，几乎看完了它的组件参考手册，
使我对U3D引擎的组件系统又有了新的认识。 同时，目前公司自主研发的引擎，也是这样的思想。 不管
我是在工作中，还是业余捣鼓都受组件系统的影响。 慢慢的，喜欢上了这种对象模式。

之前在做一个RTS游戏项目的时候，参考了著名开源项目 0.A.D的代码。 当时只是为了去寻找LOS和多单
位协同寻路的方案。 但在参考其代码的时候，发现了它整个系统，都是基于组件式的。又一次，对组件
式有了好感。 而经过仔细思索后。 回到了我一直坚持的子系统划分法的游戏框架。 当我不禁感叹，原来
，自己也一直是在组件式。 只不过，我的组件式，是MANAGER方式，MANANGER内部进行对应的实体管
理、。 比如，背包系统，则只负责玩家背包数据，背包使用，背包相关的功能。 不管是数据存储，还是
与前端通信，都是背包系统自己在负责，其它模块完全不需要干涉。  而U3D中的组件系统，则将这个粒
度划得更仔细了……。  这对于早期的像OGRE的entity系统。仅仅是认为对象可以由子对象构成，可以说是
一个质的变化。

早期的引擎，基本上都是继承优先的设计方案，更多时候考虑的是编码的便利性，且引擎的走向都具有
针对性。 而当面对一些复杂情况的时候，继承式的编码是十分麻烦的。 并且，对于JAVA,C#这样的语言
，并没有提供多继承能力。 因此，继承式的编程，在面对越来越广泛的游戏需求的时候。显得无能为力。
组件式则是一种聚合优先的编码方式，它的复用度和伸缩度，都远远大于继承。 唯一让一些C++程序员
觉得不太顺眼的，可能就是过多的变量和虚函数调用开销吧。 但这些，在当下来说，都不是问题。 影响
大众步伐的，早已不是那种语言特性本身导致的开销。更多的，是如何使我们高效率，高质量地完成一个
游戏。 因此组件模式已经成为必然。 从新版的UE4的变革，以及畅游的G3D，国外一个开源的godot引擎
，就可以看出来，大家对组件模式，已经有了深深的好感和接受度。



四、所见即所得

这可以说是许多人最喜欢的特性，这也是G3D群里，问的人最多的特性，三天两头就有人问，G3D能不能
像U3D一样在编辑器里预览游戏效果呀。

U3D除了编辑后立即运行，还能在运行过程中时实编辑，查看效果。当然，运行过程中编辑对象的数据，
会在停止后失效。（注意，对文件属性的修改，不会失效）



五、代码驱动的开发模式

这种模式，可以使我们快速地构建一个原型。 对于U3D中的MonoBehaviour来说，它扮演的，就是如何驱
动它的目标对象。 因此，你可以将你的对象的各种能力分配到不同的脚本组件中，然后根据对象的需求来
挂接。



六、多平台发布

U3D支持的平台，无疑是当下较为流行的平台。 满足绝大部分项目需求。 早期的引擎，多以PC和CONSO
LE为主。 支持WINDOWS,XBOX,PS2已经是很不错了。 U3D便利的多平台发布特性，也使得它成为了当前
性价比最高的引擎的原因之一。

也有许多公司正在自主研发引擎，或者是将先前的PC引擎修改为多平台（IOS+ANDROID居多）。 但这也
档不了U3D的步伐。

七、良好的生态圈

在使用公司引擎的时候，我就发现，若我遇上一个问题，只能问公司的老员工们，或者找其它引擎TEAM
寻求帮助。而U3D这种生态圈，不是一天两天能形成的。GOOGLE,百度，各种论坛，都能很容易找到自
己想要解决的问题。 而对于一些经验上的问题，也有不少人总结。 这使得后来者，可以快速上手引擎。

而AssetStore的出现，不仅使U3D的生态圈更加稳固，同时也提供了许多机会。 你可以制作插件放网上卖，
赚取一些利益，也可以购买别人的插件，作为使用或者参考也好。 有时候，购买一些插件，可以让你快速
脱离当前的困境。 一个是解决进度问题，一个是解决思路问题。 这是之前其它引擎不具备的。