手游client思考框架

        手游新公司新项目client我不太同意框架。虽然我也终于让步，当他居然问老板，使这个幼稚的行为而悔恨。

然而，就在最近我写了一些代码视图，我更坚定了自己的想法和思想。和思路不一定适合其它人，所以我并不会说其它人的思路或者习惯不正确或者不好，仅仅要能用清晰的思路写出清晰的代码就好了。

一、3D、Unity意味着更长的项目周期？

        非常多人都会有这种看法。由于Unity比cocos2d-x功能很多其它。坑很多其它，所以会加长项目的开发周期。也有一些技术向的人会觉得，Unity优化不到位，所以性能上还做不了大的mmo。甚至在性能上还不如OGRE。 我无法用井底之蛙来形容这些人。由于这些人都是项目负责人、技术总监、资深主程。可是在我看来项目开发的进度是跟团队水平有关的，跟引擎无关。

如今非常多线上的成功的3D MMO手游也证明了Unity的性能。

根本不存在“做不了”这种说法，甚至“坑太多，非常难做”这种说法都不成立。由于假设它真的那么“坑”的话，就不会有如此多的公司选择Unity，并且成功的开发出千万收入级别的游戏了。

        半个月前我还觉得2.5D游戏随便写，由于最早在网龙时使用C3引擎就非常安心、非常顺手。并且我看过C3的源码也不多。几百k而已。只是如今看看cocos2d-x的进度。以及我们自己对3D光效这块儿的移植，cocos2d-x成为一个合格的2.5D游戏引擎还须要至少一年时间。当然技术牛的团队能够自己去搞去优化。但是我实在想不出这么做有多少意义，使用Unity更加安心和方便。比方你不用担心光效的执行效率、引擎的稳定性、模型导入和渲染、模型动画处理、后期特效等等，而这些都是我近期使用cocos2d-x的时候被恶心到的。仅仅能说，我们觉得它非常easy。我们也觉得我们的需求非常easy，但是它就是做的不够好。

二、MVC框架真的适合手游client吗？

        应该非常多人都会觉得是的，这是一个经典的解耦合的框架。可是我感觉。框架不是目的，是否真的解耦合也不是目的，是否遵循某种设计模式更加不是目的。高速的构建client功能，而且要让它们清晰、灵活。改动和阅读起来方便，这个才是终于目的。仅仅有代码清晰了，才easy看懂，可以看懂是一切重构和优化的前提，也是改bug的前提。

假设我们为了遵循MVC，去硬靠上去，去纠结哪些东西是“显示逻辑”哪些东西是“业务逻辑”，真心不靠谱。

       我们如今的client框架大概是MVP结构，P（我们叫做controller）承载着绝大多数逻辑和功能。整个client就是由一个个的controller组成的。

我们为了遵循这个结构，所以明明一个类、一个函数调用就能够搞定的东西。要切分成几个不同的对象。由于这些对象有父子、兄弟、业务、显示这种关系，所以不能放在一起，对象之间通过一个又一个的事件通知来完毕业务流转。我非常不看好这种代码。仅仅能眼不见为净。

       我有点不明确，明明类似《我叫MT》这样简单的卡牌游戏都开发了一年时间。并且开发到后面自己都感觉厚重了，这种MVC有什么存在价值呢？它是适合换皮？还是适合扩展？还是适合删功能？还是适合新人学习？还是适合团队合作？

       在我看来。MVC本来就是为软件开发、Web页面开发搞出来的一套东西，最大的功能就是把显示和业务逻辑分离开，这样不管是改动页面内容还是改动后台逻辑都可以互不影响。 而游戏中呢？ 界面功能尽管非常多。可是是最不用担心的东西了，绝大多数情况是没有不论什么难度的。 而MVC在非UI部分可以给我们带来多大的便利呢？

       我是有用主义，有用主义并非说代码随便写。能完毕策划案就好。有用主义是通过清晰的规则和美丽的封装。让代码变得清晰简洁，让client开发变得有章可循。

       大概在一年前。我写过一篇文章，最后有描写叙述我对客户度框架的理解。我非常佩服以前的自己有如此清晰的思路>_<。

“这里也顺便说一下我对游戏client各模块依赖关系的看法，说真心话，游戏client真的是小项目。

那么作为这个小项目。没有必要过分关注耦合，模块化之类的东西。

凡是能让我的代码变得整洁，能让我写代码写的顺手方便的功能就是好功能，即便是约束也乐于遵守。可是假设为了模块化，而让我写代码时写个Impl。再写个provider，那会让人恶心透了，事实证明，有些模块化纯粹是杞人忧天。

有些复用性的想法纯粹是自作多情，比方这样的－－你看我的代码模块化的多好，逻辑模块一行代码不用改就能够用到其它项目。

我想说。假设你的游戏赚钱了，我们要再做一个类似的项目。那么我就算把你的ui模块也搬过来又有什么问题。

假设我们要做的是一个新的项目，那么我还是要从那一坨代码中找到我想要的能够复用的东西。那还不如让代码变得简单，直接些，我更easy理解。

       作为游戏client，有三个主要模块就足够了。逻辑模块、渲染模块、ui模块，全部跟引擎打交道的地方都停留在渲染模块，渲染模块是对引擎的再封装。即便有少量东西扩散到ui模块也应该仅仅停留在ui控件内部。

逻辑模块仅仅负责而且负责全然的逻辑，这也是为什么逻辑层不能引入ui元素的原因。

      逻辑层的东西就是一个一个的管理类。负责游戏的各个业务逻辑。  渲染层是对引擎的再封装，比方封装一个人物渲染类，负责渲染人物（逻辑层里还应该有一个人物类来处理业务逻辑，比方姓名、帮派，这个是组合关系）。

  ui层就是一个一个的界面。   渲染层封装好后能够几个月不动。逻辑层和ui层一一相应，完毕一个业务逻辑就是逻辑层加入一个管理类以及ui层加入几个对话框。

他们之间相对独立。有交互就靠上面提到的事件中心来调度。

      这样一个事件中心，看着是很easy的东西。可是却是整个client的基础架构，一个好的架构能够让人更加高速的完毕功能（而当架构搭建好后，90%的时间都是在写业务逻辑和界面逻辑），而不好的架构可能让我们写代码又慢，bug又多。”

        一切的核心是封装，一切的目的是实现client的逻辑和功能。基于上面提到的框架，我实在想不到会有什么副作用或者不好的地方。

更何况手游项目都不大，假设有人能把一个手游项目写出几十万上百万的代码量。我非常难对此表示认同。

三、基于组合编程、面向对象编程、函数式编程？

       我们从教科书中学到了面向对象编程，而后面又出了本经典。说应该用组合来替代继承，再后面又有大神出来说函数式编程多么好。

       我们应该怎样设计client的对象呢？  首先函数式编程我是不打算学了。由于我看了几篇文章都没有领会它的精神，但能够肯定的是函数式编程绝对不是面向过程编程。不要对象仅仅写函数就万事大吉的。

这里就要提到一个习惯问题，用自己习惯的写法去做代码封装，而不要用一知半解的概念去东施效颦。

       组件式结构必定有其先进和灵活的地方，Unity中的组件思想不管是学起来还是用起来都很方便，大概是我见过的最美丽的实现，这个美丽不光体如今组件本身，还体如今组件间的通信，组件与GameObject的关系等等。

       那是不是继承就全然没用了？ 当然不是。

即便在Unity中也依旧会有非常多地方须要继承来实现。组件能够描写叙述一个物体的附加能力，而继承则能够描写叙述一个物体是什么，有什么功能。合理的继承能够让代码清晰而精简。 而觉得代码不须要继承，仅仅用组合来描写叙述就是高大上的思想，反而会产生凌乱的代码。

四、怎样从零開始打造一个手游client

       原本我对自己缺乏一些自信，觉得自己做一个RPG、ARPG什么的缺乏经验和积累，怀疑自己能不能高速的搭建好整个项目。 可是有的时候不一定是自己的成功能够给自己涨自信，别人的失败一样能够给自己涨自信。

       1、技术选型。

这个非常重要。

第一步错了。后面就是在错误的道路上渐行渐远。

假设要做2D游戏那就用cocos2d-x，假设要做3D那就用Unity。本来我是不想提这样的一刀切的观点的，这样显得非常没有水平，由于真正的高手是拿什么都能够做的非常好的。

可是非常多人就是无法正确的选择client引擎，后果就是浪费时间，甚至项目失败。

            如今用Unity做的成功的2D游戏也比較多了，所以假设你熟悉Unity的话。那就都用Unity好了，这样能够更好的做团队的技术积累。 而假设没有什么经验的话。那么cocos2d-x+lua是最好的选择。由于简单易上手，招人也easy。 可是要注意，确定了cocos2d-x那就专心做2D的东西，假设美术和策划觉得用3D元素才干表现出一个酷炫的游戏的话，那Unity是不二选择。

        2、领会选择的引擎的开发流程和开发思路。

比方cocos2d-x中怎样处理人物移动、技能播放、UI。Unity中怎样处理人物攻击判定、物理效果、组件通信等等。 我刚開始接触Unity的时候花了非常长时间去思考这些问题，尽管浪费了一些时间，可是换来的是清晰的思路，当明确了这些问题。才干写出Unity Style的代码。 假设游戏中的基础功能都可以实现出来。那么一个Demo就成型了。

        3、游戏最核心的玩法。

  大多数情况下就是战斗系统。 这里可能涉及到一些相对困难的东西。比方ARPG中的技能系统设计、三消游戏中的转珠算法、卡牌游戏中的战斗流程设计等等。 这个花一个月甚至更长的时间来做都是合情合理的。 基本上这个东西实现完了，游戏中最重头的部分就结束了，剩下的就是纯逻辑的功能了。而纯逻辑功能尽管耗时间，可是没有什么难度，并且能够靠添人来加快开发进度。

        4、数据结构设计。

这个主要是数值策划相关的东西。比方人物有哪些属性，装备有哪些属性。用什么结构来存储人物信息，装备信息存放在哪里。程序的主要工作就是理清楚这些属性该怎样配置，怎样载入、怎样同步。

        5、网络通信和UI模块设计。尽管这两个是全然不同的东西，可是解决思路是一样的。选择一个技术方案（比方protobuf,cocostudio）。进行合理的封装，使得写这些功能独立而简单。 这个是后面开发的重头内容，client一大半代码都是在处理网络消息和ui逻辑。

        6、详细功能模块的实现。基于上面提到的client架构，“加入一个功能就是加入一个管理类。以及一些列的消息和界面”，我觉得这个找个应届生都应该会做。

        ex-2：针对第二点我再多说点。就ARPG的技能系统来说。之前我觉得要实现一个非常美丽的技能系统一定要灵活，一定要可扩充。最好策划须要什么新效果都能够自己来组合设计，不须要程序改一行代码。 这个理论上是可行的，可是也不过理论上，我看了一些Unity线上游戏的代码，他们的技能系统并不灵活，有的甚至非常死，一个技能就是一个类。 可是这个并最好还是碍他们成为出色的ARPG。实现功能是最重要的。只要大的框架有了，细节功能上的设计不是必需追求完美。

五、拥抱策划的变化？

       首先，我不觉得游戏功能不停的推翻重做是靠谱的行为。假设是老板的话，那我还能够接受。可是假设是策划的话，那就真该批判了。我自己常开玩笑说我是专业策划。业余爱好是写代码。我觉得策划应该对自己要做什么游戏、游戏有什么噱头、游戏画面和玩法的目标是什么、游戏的终于样子是什么都有一个清醒的认识。假设连终于游戏是什么样子都想象不到的话，那怎样保证设计出的游戏会吸引人。 我想那些成功的游戏在设计之初就依旧确定了游戏的核心，他们肯定会有这种认识：这个游戏就该是这个样子的。这种游戏绝对会火，这么爽的游戏绝对好玩。

      其次，即便我们须要应对重复无常的策划，那么我上面提出的框架也一样能够方便的进行改动。

不一定须要严格的功能模块切分，而当我们接手别人维护的代码的时候，很多其它的时候是理解策划案功能。而觉得通过严格的模块划分和模块间事件通信来完毕解耦合就能够更加方便的维护整个项目。在我看来是不切实际的。除非真的个人维护个人的，自己的烂摊子自己最熟悉，否则真要查起bug来。说不定更加痛苦。

      最后，当我们需要改变时，皮肤，同样可以轻松搞定。

我们是非常灵活的独立和明确的。至少渲染层封装是绝对有能力复。其中的逻辑是同层的用途很广，再假设某些功能无法用语言，然后相应的ui层也将不需要。