cocos2d-x进化为2.5D的一些想法

Posted 2020-09-18 cxchanpin

??

        首先我得说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。

一种是大公司自己研发引擎。如今開始又一次研发意义不是非常大。可是老牌的游戏公司都是有非常深厚的技术积累的，研发引擎真心不是多么困难的事情，尤其是为手游服务的引擎。  另外一种是，我的需求非常easy。比方我仅仅想渲染3D模型然后能播放动画就OK了。这样的情况下不使用U3D也是OK的。
      我个人感觉U3D在网游开发流程上并没有多么美丽的实现，很多其它的是为独立游戏这种小团队模式服务的。

尽管成功的MMO手游很多。可是牛x的团队绕过了坑，或者填平了坑并不能说明坑不存在。
      1、资源管理方面。

U3D资源是自己主动打包而且由引擎统一维护，你不须要（也非常难）去以文件的形式控制一个资源。

这非常多时候让我感到束手束脚。

尽管考虑到预制和场景中资源的载入和维护。由引擎统一管理资源是能够接受的，而且我也没有想到更加简单直白的方式。

可是不爽终归是不爽。

资源（如纹理、模型）的细节被隐藏在U3D的资源系统之后了，怎样保证资源合理的释放，怎样保证AssetBundle的资源依存关系都是值得单独写一篇文章的东西。

这就是黑暗细节。
      2、AssetBundle。

由于Unity资源有一套内部的数据联系（比方脚本绑定、材质属性等等），所以Unity提供了独立于程序包的文件系统，这个也是页游和手游的自己主动更新策略的基础。

它一方面能够完毕自己主动更新的功能，还有一方面也能够实现多人开发的数据维护工作。

可是怎样正确的打包保证资源的最优并非一件easy的事情。

并且资源打包到AssetBundle后。在编辑器开发会有一定限制，比方Animator就无法查看动画状态机了。
      3、多人开发的资源管理。我如今唯一能想到的就是让美术也习惯用Unity，然后统一使用AssetBundle来进行资源维护。程序仅仅须要关心Bundle就能够了。可是这要求资源就仅仅是资源。假设程序还须要对资源进行一定的处理，比方绑定脚本、加入碰撞检測等，就须要额外的工作流程改动。而假设全部人共用一个svn（或git），那project项目目录可能会有N个G（我的一个ARPG的项目目录就超过10G了）。并且Unity用meta文件来保存信息也有些恶心，有些信息是实用的，比方动画信息、纹理切分信息等等，可是非常多是没用的，而一个大一些的网游零碎文件可能非常多。meta文件体积就非常恐怖了。 并且资源改动的时候可能会由于误操作导致绑定的脚本丢失等问题。这仅仅能说简单的情况非常easy，恶心的情况非常恶心。
       4、脚本。

老实说，我并没有找到更好的解决方式。可是将脚本绑定到物件对象上并非多么完美的方法。由于脚本和资源已经绑定在一起了，那意味着代码和资源必须放在一起管理，使用传统的方式来维护代码和资源不再可行。并且项目的正确程度也依赖于资源的数据配置。或者说程序猿非常大一部分工作须要配置资源数据。在svn或者git上面维护整个project是一件非常痛苦的事情。

我原本想开源之前停掉的那个项目，可是把2G的资源上传到github上是不可能的事情。而假设仅仅上传代码又没有不论什么意义。假设是其它的项目的话，则能够仅仅须要管理代码就可以。资源的话在网盘里面维护一份终于的资源配置就可以。
       5、非常多功能可用可是并不好用。

这个主要是从MMO开发便利程度上来说。比方MecAnim。动画重定向非常美好，状态机的编辑方式也算方便，动画融合编辑尤其便利。可是就开发MMO来说这并非非常好的选择，至少非常多公司依旧使用老的动画系统。既有的框架（或者开发经验）都是基于老的动画系统来做的，并且全然满足全部功能（对于公司来说，重定向与否并非核心考虑因素）。没有必要尝鲜（尽管已经出来一两年了）。关于怎样让开发上相对方便的使用MecAnim，我还写过一篇文章。只是即便如此也不能说多么完美的解决方式，仅仅只是是由不可能变成能够开发而已。我觉得MecAnim最大的坑就是没有兼容老的动画系统，在使用上新旧动画系统最大的改变是加入了状态机的编辑方式。可是连线、编辑状态转移參数的方式操作起来非常蛋疼，而直接播放动画的接口又可能对某些功能造成影响（或者说不知道有没有什么负作用，不开源的话能知其然而又知其所以然并不easy）。

而最完美的情况应该是编辑器、动画重定向、动作融合编辑功能上相对独立，这样开发人员能够依据自己的喜好定制动画系统。
       6、2D功能方便可是鸡肋。

这个是上一条的延伸。Unity4.3推出了2D功能，而且在4.5进一步完好，可是假设我想不做改动就拿它来开发一个2D的手游比方大掌门、刀塔传奇之类的，依旧是很痛苦的一件事。

某种程度上说。cocos2dx更加顺手。倒并非说一定要使用cocos的代码形式或者结构。我觉得Unity的基于编辑器的开发流程还是很不错的。可是一些基础功能的缺失。或者说没有很方便直接的提供，让二次开发很必要。我之前想写（改进）一个2D插件。已经完毕70%了。可是因为后面要转回cocos。所以预计这个要延期了。Unity本身的Native仅仅是提供了方便的显示图片和创建动画功能。可是图片打包功能很薄弱（不支持图片旋转，不支持Trim，操作方式别扭。无法与TexturePacker相比），动画无法编辑以及精细控制（比方某一帧偏移控制、时间控制）。同一时候没有既有的多分辨率解决方式（摄像机的分辨率控制）。而这些都是开发游戏所必须的功能。

二、我们须要什么样子的3D引擎：
      就手游开发来说，次世代永远不是须要考虑的。即便Unity本身那些酷炫的效果也是在手游上“禁用”的，比方实时光照。我们一方面追求高模的表现效果，还有一方面又要追求低面数的效率。本身就不可能达到所谓的“高画质”。可是一个游戏好不好看，炫不炫非常多时候不是看是否是“显卡危机”，而是看美术的总体风格和感觉。比方，我就感觉满屏的光效和满屏的飘血数字就是非常酷的游戏了。至于毛发是否仔细、嘴型是否匹配不在我的考虑范围之内。
      我须要的3D引擎在功能上很easy，能高效率的渲染3D模型、骨骼动画、粒子光效就足够了。重要的不是有多么丰富的功能，而是基础功能是否方便且极致。因为是自己开发的引擎，我们能够把更大的精力花费在效率的优化上面。比方我一直想实现一个千人战的RTS游戏，这个我在Unity測试的效率无法满足需求。除非把模型压的很慘淡。

自己开发的话就能够尝试着去优化和解决。
      再次重申，最先进的图形学技术不是我所考虑的，有用才是第一要务。

三、有哪些能够參考的开源引擎：
      有非常多开源的3D引擎能够学习參考，站在巨人的肩膀上面会少走非常多弯路。非常多公司花几千万几年时间来搞3D引擎。并且有的还没有搞成（没有成功的游戏代表作），在我看来就是走弯路了。这些开发人员大牛一方面歧视OGRE之类的开源引擎觉得技术上非常渣。还有一方面自己又没有做出令人信服的东西。

引擎开发没有那么easy，由于要想做出让人信服的引擎须要编辑器、功能、效果、效率、开发流程等全盘考虑，这的确是费时费力的事情。可是同一时候引擎开发也没有那么困难，仅仅要我们愿意舍弃全部我们不关注的东西那么能够非常快做出让自己信服的引擎。
       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了。可是当遇到新的问题时，懂得底层会帮助解决这个问题。