标签：style os 使用 ar 文件 数据 div art sp
首先我得说Unity3D已经做的很好了，搞这些东西意义真心不大。具体Unity3D有什么优势我之前也写过两篇文章来阐述自己的想法。
如果我的下一份工作是U3D的话，估计我就不会有这些想法或者研究了。不过谁让我又重新转回cocos2d了呢。我的新的工作大概就是写一个cocos2d-x的2.5D游戏。如果按照我自己的想法，那肯定是U3D来做，不过我在技术上从来不是刚愎自用的人。而且很多时候做游戏图形学和算法都没那么重要，说白了就是拿什么都能做，这里面更多的可能是个人对引擎的熟悉程度或者喜好程度。
这篇文章不会有什么技术性质的东西，更多的可能是吐槽或者是臆想。首先会分析下U3D的劣势（好话之前已经说的很多了），然后会分析下cocos2d-x做2.5D的优势，最后会分析下3D的可行性。
一、U3D的症结所在：
使用U3D开发3D游戏几乎是唯一正确的选择。如果是次世代游戏的话还可以考虑UE3或者UE4，但是就手游而言，靠次世代画面成功的游戏几乎没有。U3D几乎已经代表了画面的巅峰。而且很多时候一个游戏的画面不是引擎决定的，而是美术决定的。再优秀的引擎也会被渣美术给耽误。
使用U3D可以方便的跨平台，有灵活可扩展的编辑器，完善的粒子系统，丰富的资源和扩展，简单而系统框架体系。好处很多就不一一列举了。
这里分析下缺点，其中有些缺点是无关紧要的，有些是可以绕过去的，有些则是真正恶心的。这次去网易面试，主程也说，相比Unity，他们更习惯使用自研3D引擎，同样有完善的编辑器和工作流程，但是可以避免Unity的一些问题。
当然，只有网易这样的大公司而且是技术向的大公司会有这样的实力，小团队就安安稳稳的使用Unity就OK了。毕竟画面效果、游戏是否赚钱、开发进度都是跟团队水准相关的，跟引擎没有太大关系。不是说开发慢了或者画面渣了或者优化差了就是引擎不好，而是自身水平问题。
U3D一切都很美好，但是某些细节或者流程确实很恶心，两种情况下可能会考虑放弃U3D。一种是大公司自己研发引擎，现在开始重新研发意义不是很大，但是老牌的游戏公司都是有很深厚的技术积累的，研发引擎真心不是多么困难的事情，尤其是为手游服务的引擎。 第二种是，我的需求很简单，比如我只想渲染3D模型然后能播放动画就OK了，这种情况下不使用U3D也是OK的。
我个人感觉U3D在网游开发流程上并没有多么漂亮的实现，更多的是为独立游戏这样的小团队模式服务的。虽然成功的MMO手游非常多，但是牛x的团队绕过了坑，或者填平了坑并不能说明坑不存在。
1、资源管理方面。U3D资源是自动打包并且由引擎统一维护，你不需要（也很难）去以文件的形式控制一个资源。这很多时候让我感到束手束脚。虽然考虑到预制和场景中资源的加载和维护，由引擎统一管理资源是可以接受的，并且我也没有想到更加简单直白的方式。但是不爽终归是不爽。资源（如纹理、模型）的细节被隐藏在U3D的资源系统之后了，如何保证资源合理的释放，如何保证AssetBundle的资源依存关系都是值得单独写一篇文章的东西。这就是黑暗细节。
2、AssetBundle。因为Unity资源有一套内部的数据联系（比如脚本绑定、材质属性等等），所以Unity提供了独立于程序包的文件系统，这个也是页游和手游的自动更新策略的基础。它一方面可以完成自动更新的功能，另一方面也可以实现多人开发的数据维护工作。但是如何正确的打包保证资源的最优并不是一件容易的事情。而且资源打包到AssetBundle后，在编辑器开发会有一定限制，比如Animator就无法查看动画状态机了。
3、多人开发的资源管理。我现在唯一能想到的就是让美术也习惯用Unity，然后统一使用AssetBundle来进行资源维护，程序只需要关心Bundle就可以了。但是这要求资源就只是资源，如果程序还需要对资源进行一定的处理，比如绑定脚本、添加碰撞检测等，就需要额外的工作流程修改。而如果所有人共用一个svn（或git），那工程项目文件夹可能会有N个G（我的一个ARPG的项目文件夹就超过10G了）。而且Unity用meta文件来保存信息也有些恶心，有些信息是有用的，比如动画信息、纹理切分信息等等，但是很多是无用的，而一个大一些的网游零碎文件可能很多，meta文件体积就很恐怖了。
而且资源修改的时候可能会因为误操作导致绑定的脚本丢失等问题。这只能说简单的情况很简单，恶心的情况很恶心。
4、脚本。老实说，我并没有找到更好的解决方案。但是将脚本绑定到物件对象上并不是多么完美的方法。因为脚本和资源已经绑定在一起了，那意味着代码和资源必须放在一起管理，使用传统的方式来维护代码和资源不再可行。而且项目的正确程度也依赖于资源的数据配置，或者说程序员很大一部分工作需要配置资源数据。在svn或者git上面维护整个工程是一件非常痛苦的事情。我原本想开源之前停掉的那个项目，但是把2G的资源上传到github上是不可能的事情，而如果只上传代码又没有任何意义。如果是其他的项目的话，则可以只需要管理代码即可，资源的话在网盘里面维护一份最终的资源配置即可。
5、很多功能可用但是并不好用。这个主要是从MMO开发便利程度上来说。比如MecAnim，动画重定向非常美好，状态机的编辑方式也算方便，动画融合编辑尤其便利。但是就开发MMO来说这并不是很好的选择，至少很多公司依然使用老的动画系统。既有的框架（或者开发经验）都是基于老的动画系统来做的，而且完全满足所有功能（对于公司来说，重定向与否并不是核心考虑因素），没有必要尝鲜（虽然已经出来一两年了）。关于如何让开发上相对方便的使用MecAnim，我还写过一篇文章，不过即便如此也不能说多么完美的解决方案，只不过是由不可能变成可以开发而已。我认为MecAnim最大的坑就是没有兼容老的动画系统，在使用上新旧动画系统最大的改变是添加了状态机的编辑方式，但是连线、编辑状态转移参数的方式操作起来非常蛋疼，而直接播放动画的接口又可能对某些功能造成影响（或者说不知道有没有什么负作用，不开源的话能知其然而又知其所以然并不容易）。而最完美的情况应该是编辑器、动画重定向、动作融合编辑功能上相对独立，这样开发者可以根据自己的喜好定制动画系统。
6、2D功能方便但是鸡肋。这个是上一条的延伸。Unity4.3推出了2D功能，并且在4.5进一步完善，但是如果我想不做修改就拿它来开发一个2D的手游比如大掌门、刀塔传奇之类的，依然是非常痛苦的一件事。某种程度上说，cocos2dx更加顺手。倒并不是说一定要使用cocos的代码形式或者结构，我认为Unity的基于编辑器的开发流程还是很不错的。但是一些基础功能的缺失，或者说没有很方便直接的提供，让二次开发非常必要。我之前想写（改进）一个2D插件，已经完成70%了，但是由于后面要转回cocos，所以估计这个要延期了。Unity本身的Native只是提供了方便的显示图片和创建动画功能，但是图片打包功能非常薄弱（不支持图片旋转，不支持Trim，操作方式别扭，无法与TexturePacker相比），动画无法编辑以及精细控制（比如某一帧偏移控制、时间控制），同时没有既有的多分辨率解决方案（摄像机的分辨率控制）。而这些都是开发游戏所必须的功能。
二、我们需要什么样子的3D引擎：
就手游开发来说，次世代永远不是需要考虑的。即便Unity本身那些酷炫的效果也是在手游上“禁用”的，比如实时光照。我们一方面追求高模的表现效果，另一方面又要追求低面数的效率，本身就不可能达到所谓的“高画质”。但是一个游戏好不好看，炫不炫很多时候不是看是否是“显卡危机”，而是看美术的整体风格和感觉。比如，我就感觉满屏的光效和满屏的飘血数字就是非常酷的游戏了，至于毛发是否细致、嘴型是否匹配不在我的考虑范围之内。
我需要的3D引擎在功能上非常简单，能高效率的渲染3D模型、骨骼动画、粒子光效就足够了。重要的不是有多么丰富的功能，而是基础功能是否方便且极致。由于是自己开发的引擎，我们可以把更大的精力花费在效率的优化上面。比如我一直想实现一个千人战的RTS游戏，这个我在Unity测试的效率无法满足需求，除非把模型压的非常惨淡。自己开发的话就可以尝试着去优化和解决。
再次重申，最先进的图形学技术不是我所考虑的，实用才是第一要务。
三、有哪些可以参考的开源引擎：
有很多开源的3D引擎可以学习参考，站在巨人的肩膀上面会少走很多弯路。很多公司花几千万几年时间来搞3D引擎，而且有的还没有搞成（没有成功的游戏代表作），在我看来就是走弯路了。这些开发者大牛一方面鄙视OGRE之类的开源引擎认为技术上很渣，另一方面自己又没有做出令人信服的东西。引擎开发没有那么容易，因为要想做出让人信服的引擎需要编辑器、功能、效果、效率、开发流程等全盘考虑，这的确是费时费力的事情。但是同时引擎开发也没有那么困难，只要我们愿意舍弃所有我们不关注的东西那么可以很快做出让自己信服的引擎。
1、genesis-3d，搜狐畅游搞的一套开源引擎，跟Unity非常像。属于那种畅游自己不用，然后推荐给别人用的东西。参考价值不大，因为它庞大而复杂。而且我个人认为它走弯路了。弄的跟Unity很像，但是跟Unity比又没有任何亮点，反而是各种功能缺失，而且又没有Unity的开发社区，这样怎么去跟Unity抢地盘？
2、godot，又一个跟Unity很像的东西。也是编辑器向的引擎。
3、Torque3D、Torque2D，引擎卖不出去了，干脆开源好了。
4、GamePlay、Panda3D、PixelLight，不算太出名，但是功能相对完善。不走编辑器路线。其中Panda3D代码量很大。
5、Ogre、KlayGE、WildMagic，比较出名的开源引擎了，可以看看结构设计和图形技术。其他如鬼火之类的感觉没什么大亮点，跟OGRE差不多，挑一个看就完事了。
四、cocos2d-x的3D现状和进化的可行性：
cocos2d-x-3.2版本已经加入3D模型和骨骼动画的支持了，最新的github上面有更多的重构和改进，比如支持submesh了。当然对一个3D引擎了来说这远远不够，但是很多时候对我们制作2.5D游戏来说又绰绰有余。
至于为什么要考虑cocos2d-x的3D化，而不是用上面提到的引擎，主要考虑是学习成本和开发成本。学cocos的人很多，用cocos做游戏的人也很多。所以对应的开发人员比较好招，而跨平台遇到的坑基本上它都填平了。最最主要的是，看主程的习惯，主程的习惯可以指导技术方向，还是那句话，引擎无法决定开发效率，正确的使用引擎才是。
现阶段最主要的缺失是一个完善的粒子系统，比如OGRE的Particle Universe，粒子系统本身和编辑器缺一不可。其他的再看看武器绑点、换装能不能搞定，如果现在就可以的话，就不需要额外的开发工作量了。
只要开发流程是正确的，编辑器没有那么重要，只需要场景、UI等部分内容支持所见即所得的编辑就可以了。熟悉流程要比熟悉编辑器提升更多效率。
五、就算方向错误，浪费时间了会有什么损失：
好像也没什么损失，一方面再一次证明我对Unity的欣赏是正确的，另一方面可以学习到底层的引擎技术。这个对之后开发都很有帮助。当底层技术没有问题时，开发游戏就是写逻辑，条理清楚的把逻辑实现就OK了。但是当遇到新的问题时，懂得底层会帮助解决问题。
标签：style os 使用 ar 文件 数据 div art sp
原文地址：http://blog.csdn.net/langresser_king/article/details/39364795
