Unity3D使用经验总结 优势篇

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

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

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

首先，咱们来讲说U3D的好处。可能总结得不够完善，若是有不足的地方，就表示我本身没有体验到。

 

声明：为了避免打扰你们的雅兴，因此，这里只讲它的优势，想看缺点的朋友，请看此文章的姐妹篇 Unity3D使用经验总结 缺点篇

 

1、可定制的IDE环境

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

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

所以，一个好的引擎，一定得先有一个功能完备的编辑器。

 

2、基于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 彻底没有使用过，貌似也不多有人使用。

 

3、基于组件的对象系统

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

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

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

 

4、所见即所得

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

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

 

5、代码驱动的开发模式

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

 

6、多平台发布

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

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

7、良好的生态圈

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

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