个人和Unity3D早在07年就有一面之缘，当时似乎它还是1.5左右的版本，源代码通过某种途径得到过，但当时我还从事端游开发，对于CryEngine,Gamebryo,Unreal这些高大上的引擎兴趣更浓厚。另外当时它还不支持手机平台（那时候手游也没这么火，06年时候还是基于J2ME-NokiaAPI，MotorolaAPI开发128*128屏），甚至拿它和Torque这种引擎比较也没找到什么特点出来，当时就给放弃了。最近几年其声势如火如荼，加上工作关系，于是对其进行一些接触。

先吐槽一句，从骨子里来说，依然不喜欢这种封装性过强的引擎，和C++一样，充满陷阱又容易入手，引得无数人自称高手出来嘚瑟，想着隐隐蛋疼。
这次接触Unity3D只有一个月时间，记录下自己的一些感觉。

先说优点： 1：编辑器化。 首先接触它的时候，我就觉得整个一个编辑器，这点和RpgMake,UnrealEdit都有些类似。对于编辑器化，毫无疑问是未来的一个趋势，从最早期的直接编程，到卡马克那代制造出“游戏引擎”，然后冒出的大量的第三方库，程序的复用性总在尝试进一步提高。当复用性提高到一个层级之后，可视化的编辑器也势在必然，从一般用户更喜欢界面系统，而不擅长命令行也可见一斑（再吐槽：程序员的最终境界之一似乎就是让别的程序员无路可走，笑~）。而U3D在编辑器这里做的更加极致，它将多个编辑器巧妙的组合起来，例如你在场景编辑器里右键选择材质就会直接弹出材质编辑器，而不需要枯燥的点Edit->Tools->MaterialEditor再选择指定的材质这么复杂操作。加强编辑器间的直接联系的确是个很不错的主意，想下之前ArkEngine，FKOgreWorldEdit的编辑器各自分离的做法还是不可取的。

2： 组件式架构。记得开始学习C++时候，就无限被强调C++是面向对象的，面向对象OO的特点是封装，继承，多态。当时觉得A：public B碉堡了，恨不得把世界万象抽象为继承类。结果后来逐渐发现钻石继承的坑，逐渐了解虚函数表的维护代价，逐渐对这玩意儿开始怀疑起来。后来看Effect C++又明文看到这本“圣经”提出，“尽量考虑使用组合，而不是继承。聚合优先。”，于是有一段时间颇有三观尽毁的感觉袭来。之后学习DX了解到com机制，模块强封装，其内部除IUnknown之外大部分依然是使用组合，又一次对组件式有了强烈好感。当然，在做游戏逻辑的工作中，考虑到团队的整体能力限制，组合式设计也是最容易被大家理解和接受的，反而这种想法也一直在脑海中。当然Unity刚开始接触的时候，各种组件拖拽到节点组件的这种方式，我直接就理解成AttackComponentNode( NodeType* p );了，也更适合没有强OO思想的人员使用（特别是非程序人员），无形中进一步降低了其入门难度。

3： WYSIWYG。What you see is what you get （所见即所得）。似乎第一次接触这个概念是在CryEngine还是Unreal2的讲座上已经忘记了，当时觉得碉堡了，也就直接促使我在Ogre进行游戏开发过程中，极其重视WorldEdit，编写漫游插件，事件预览插件花费了相当大的精力。这个东西似乎颇为受大家欢迎，特别是那些策划和经验不足的程序们，直接见到可视化的结果，且不说其他价值，光在团队士气的鼓舞上就颇有加分。当然U3D做的相对更加极致，它甚至允许在游戏运行过程中，实时编辑（结束预览后数据会丢失），这一点的确需要好好研究下怎么学到。

4：简单的跨平台发布。 游戏的发展史很有趣，页游用五年时间就把端游十几年的流程走快走完了，而手游又用一两年就走了前两者的一大半，对于如此频繁的平台迭代，游戏开发人员都要付出强大的学习力。然而，Unity的确帮了大忙，脑残式的一件跨平台发布，优势极大。何况大部分人开发都在Windows,Linux,MacOS下，而执行却要在Android,iOS上，不能跨平台的引擎受伤不轻啊，把握时代脉搏还真是个重要的活^ ^。

5： 强大的生态圈规划。国内从来不是一线程序员的聚集地，强大的2G_2F_2W阻挡技术获得，加上国人原本不擅长的“交流分享”的本性，所以国内想出个什么碉堡的大型开源引擎，因为无法合作，这种事几乎是不可能的（呵呵，企鹅你行么）。而看国外的开源牛X项目层出不穷，而从之前sourceforge,googlecode到现在github，我们都会发现任何一个强大的项目都会有很强的一个社群，好的项目从来不是一个人自己做出来的，之前的卡马克时代已经一去不复返了（请原谅我这里吐槽很多，弄了几年个人引擎失败，怨念太大，没办法）。所以，常常翻墙获取海量最新资讯的人都应该得到一个很简单判断一个项目是否能引领未来的能力：如何看出一个项目是否有前景？看他的社区是否有人气，代码是否有较多的分支和版本更新基本就清楚了。那么U3D的强大之处就不言而喻了，我曾google几个关键字，例如"Prewitt Edge shader"和“Prewitt Edge shader NOT Unity”得到的搜索结果数之差就说明了一切，网上的Unity资料实在太多了。当然，社区,wiki这些是每个引擎都具备的。但Unity的AssetStore的出现，直接巩固了Unity的整个生态圈，实在太绝妙了。最近Unity又出了资格认证，对于一些中低层程序员也是一种福音。有时候购买一些插件，就能帮你解决很多问题；搜索一些问题，得到针对性的解决问题的思路；考些证，明确自己的目标，进一步了解自己，这些能够使得未接触Unity的人可以快速上手并且喜爱上它。

6： Unity的奇特脚本。这个东西依然让我觉得是褒贬参半，这模块我先只说优点。首先，因为C/C++的效率较高，对于早期硬件限制下，C/C++无疑是游戏开发的主力军。后来出现引擎，分离逻辑和功能（例如图形），由于逻辑常常更变，而且C++的坑多的令人发指，一不小心就带来内存问题，提高了研发能力要求和人力成本，加上可怜的标准库，于是就出现了将UI，AI，部分逻辑丢到Lua,Python等脚本的开发模式。当然也出现了一些自定义脚本，例如典型UnrealScript。那么我们先来吐槽下US这种东西，首先一个新鲜的语法，程序员适应需要有一定代价，另外作为脚本如果没有一定的基础库支持，那么写逻辑时其优势又将降低。如果给自定义脚本做很多基础功能支持，那么随着功能的扩充，将不得不开放更多的特性和接口扩充，其结果要么是自定义脚本背负的一个庞大的支持，变的复杂和低效，其优势之一“容易上手”就愈加不明显，而高级特性的开放……呵呵，那和C++又有什么区别了呢？于是悲剧的Unreal4似乎已经取消了UnrealScript，直接开放了C++，很是嘲讽不是么~^ ^。嘛，回到正题，那么Lua这种依附性语言呢？首先Lua的OO就无力吐槽了，加上原生程序库的可怜，完全依附寄主提供接口，而更遗憾的是，Lua原本效率就一般，而性能最大瓶颈又是和寄主（例如C++）的交互上，Lua_state堆栈操作始终是性能消耗最大的地方。那怎么办，用Lua做更多？它又丧失了灵活小巧的优点。真是无解。再次回到正题，U3D使用了C#和Js，当然据说还有个奇怪的Boo。Boo完全不懂，不提。js不熟也先放一边。说说最常见的C#开发，那首先说下C#本身，它的默认支持库相当全面，也有典型的OO支持，自己处理了C++最蛋疼的内存安全问题，执行效率不低，编译速度还很快（你妹，说好的编译时候让我去抽根烟的呢），另外其本身的反射机制，也极合适做编辑器。但它有个很致命的缺点，它是微软ms的.NET私生子产物，意味着Linix,MacOS对它没有兴趣，它原生无法跨平台。于是Unity就去找了成熟的mono帮忙做桥梁，解决了这一问题。原本混合式编程最蛋疼的几件事：更多知识，调试困难这些又被其隐藏源代码的方式给解决了，你只需要知道C#就能搞定，算是也帮了开发者一点忙。加上顺道整个了半成品的Mono编辑器也一定程度上方便了脚本开发。对于这点，我依然想吐槽几句，留之后吧。

缺点：// TODO: 价格比Unreal4,CryEngine都贵，Unreal4 19美元给全部源代码，Unity闭源。 半残品：网络半残，PhysX和简单物理半残，预设系统半残，声音系统半残，输入管理半残，Level层级管理半残，GUI半残。更适合当前国内大众化量产游戏。 成批出现不懂程序的程序。 失分的渲染能力和效率。 脚本。你真是脚本？ 看起来很美，做大型项目依然逃不开编码，逃不开自己的场景管理，自己的网络，自己的脚本等。 社区人多，但沉淀深度不如UDK。 天生的独立游戏引擎脸。