棋牌游戏开发框架设计思路

说在前面的话：棋牌游戏市场，大部分都是品质低劣，生命周期短暂，绝大部分原因是因为棋牌游戏开发成本低，对开发人员的要求也低。大部分团队只需要快速出成品，只要有东西快速赚钱就可以了。16年的私人房模式，再次引爆了棋牌市场。我也该兑现我的承诺，跟大家分享下怎么架构和实现这套框架来满足棋牌游戏需求的。
经过几个月的努力，终于说服老板，以及各种上级，实施这套解决方案。现在框架OK了，也利用这套框架架构开发了多款游戏，虽然过程很艰辛，但是还是很值得。秉承保密原则，本人并不会将框架代码放出，只做技术交流。
根据之前在日立及IBM的项目经验，大部分成熟产品都会有一套完整的解决方案。不断的积累，终大道至简。这也是这个框架命名Theway的来源，希望coding的路上越走越轻松！

一、原型
符合棋牌项目框架，快速换皮，快速融合。多渠道多包体。自由拆装。
一次开发核心玩法，快速自由迭代各种市场版本。

二、架构设定
* 解耦，复用性，拓展性
* 多自由度、可分拆多项目开发，符合敏捷需求
* 品质保证体系
* 高效开发
* 支撑公司大部分业务

三、模块设计概要
减少客户端对Cocos2d-x引擎的依赖程度和降低耦合度，将引擎必要的初始化、逻辑更新、渲染、资源管理等交给底层处理，是客户端逻辑开发不需要过于依赖引擎层，同时，为了避免客户端代码中频繁、直接的调用平台相关诸多功能，我们将平台相关的功能封装在引擎封装模块内。这部分我们可以叫做BaseCore部分。

1、引擎封装模块 （EngineSystem）
* Cocos2d-xAPI的封装整合，绑定到Lua。关掉3D模块，另外不再使用扩展库。
* 达到可以随意切换Cocos版本，现阶段选择比较稳定的版本
* 自定义控件等绑定到Lua
* 跨平台特性处理
* 支付相关模块特殊处理
* 脚本加密解密处理
* 必要的时候，可以将脚本层换成js绑定，然后将逻辑代码修改成Lua的，就可以支持H5了

2、 UI系统（GUISystem）
* UI的一些基类，例如弹出框可以将如下属性封装成一个Dialog对象，派新类自然拥有这些属性了。可设置大小并且带有关闭按钮的一个基本视图，另外子类不再需要去设置dismiss了。
* 还有类似于Toast的创建，以及一些基本控件完全可以架构一个工厂对象，从而省略很多的基本控件的构造代码。当然也可以在Lua中通过配置文件来配置基本UI。
* 健全的纹理管理规则及清理规则，纹理缓存在场景切换后不会移除。可以考虑逐帧加载，将纹理分级，公共资源可以不remove，先删除可能不再使用的帧动画资源等。
* 特别设计有限状态机管理纹理内存，动态控制空间。以及利用状态机的事件特性来控制动态跳转。

3、 网络模块（NetSystem）
* Socket采用TCP/IP协议，封装伯克利套接字接口，设计接受和发送队列，通过互斥信号锁来处理队列共享问题。因为join函数调用的地方会阻塞主线程，我们可以考虑用detach方式，完全是交给系统处理，另外可以考虑第三个线程来开辟世界聊天或活动的这种比较频繁的协议（视情况），并且将协议解析及Lua的table序列化放在C++层。暴露基本接口给Lua脚本层，在脚本层处理网络心跳、断网重连相关的逻辑。顺便我们要支持IPv6的处理，这里只需要将地址解析、Socket初始化函数做兼容。接受子线程跟UI线程同步使用Cocos2d-x提供的事件来处理，然后C++将这个数据POP到Lua层，Lua这边根据协议头回调函数，或者是通过事件的方式派发到具体的业务。
* 对于一些通用的协议，Lua层设计成抢占方式，或者是添加一个tag来标记目前这条协议是处于模块。
* 设计模式上考虑使用生产－消费模式，尽量让协议的读写跟业务内容解耦。协议层的封拆包全部用python脚本生成的lua文件自动化处理，发送跟接受都是接受一个table，省去客户端的部分工作。
* Http，我们可以封装，上传下载，以及我们日志上传相关的模块等。如果使用3.11以下版本，需要替换libcurl，针对苹果IPv6问题。
* 结合日志模块，将协议交互写在一个文件方便查看
架构图如下：

4、数据管理模块（DBSystem）
类似于ORM的设计架构，调用者不需要关注实现细节，来处理一些数据
音效相关，如音量关闭，音量大小等类似数据的处理
一些可以缓存在本地的数据，如一些公告之类的文本信息

5、更新模块（UpdateSystem）
* 资源热更新，用于部分Bug修改等。
* 模块下载，大厅可以选择部分模块进行热更，下载完后，即可重新启动虚拟机，或reset Package。达到真正热更意义。

资源热更新：
通常我们会在游戏中会出现一些小Bug或者需要更换部分图片素材，或者部分配置文件。来适应运营策略的部分小版本更新。

模块化更新：
大厅合集中，下载相应的模块，然后再点击就可以玩相应的模块了。技术设计上，可以将资源热更下来，即刻reset Lua的Package。或者将下载的模块添加到搜索路径。

版本管理：
1、trunk维护一个BaseCore版本，有改动，其它所有包体都要考虑更新版本。作为一个大版本处理。后期项目多了，有改动可必须拉分支进行修改，然后同步到trunk。
2、业务模块在BaseCore没有改动的情况下，完全可以不用更新程序包，直接热更新即可。作为一个小版本。小版本可以在一个新迭代后拉一个脚本Tag版本。
3、SVN管理。需要严格控制版本的关系。并且做好记录。

6、音频模块（SoundSystem）
* 统一音频解决方案，整个游戏中只有一套API
* 可以区分平台自动匹配资源名称，如android自动将后缀改成.ogg。iOS改成mp3等
* 提供音频文件预加载

架构图：

7、日志系统( LoggerSystem)
* 分级别的日志处理，类似log4j分Tag处理，更好的区分日志文件。
* 分文件处理，如果网络协议日志，行为日志等。
* 配合自动化测试，添加相应的行为日志为Bug修改提供帮助。
* 客户端可以设计将日志文件上传到日志后台。根据用户ID命名。
架构图：

8、事件系统（ EventSystem）
考虑到框架总体的拓展性，我们完全使用事件驱动模型（Event-driven）来设计和开发，将客户端中事件的触发时机和具体处理逻辑彻底分隔开。游戏的各个模块，仅需要注册、监听和实现其关心的消息事件，而无须关心事件何时被触发，降低了总体耦合度。游戏中所有UI面板的隐藏/显示、事件响应、音效的播放/停止、游戏流程的切换、游戏角色状态迁移等，完全通过事件驱动方式开发；同时这种基于事件的处理方式，为项目使用动态脚本拓展提供了支持：脚本层省去对逻辑代码的大量直接调用，通过消息事件完成脚本层和逻辑层的交互调度，大大简化了开发的复杂度。
* 解决多线程消息通知，类似于notification方式。
* 处理模块间耦合，配合状态机，来处理UI或者说是模块的行为。
* 处理全局系统数据等。如玩家数据

9、配置系统（ VariableSystem）
* 开发及运营包体配置
* 游戏中一些配置，支持差异化包设置
* 这些配置包括部分的动态配置，如大厅的布局位置等

10、自动化测试系统（ AutoTesterSystem）
* 提供简单的测试脚本支持。如重复进行某一个操作，所以每一个核心业务都需要预留测试接口，然后结合我们的行为日志，充分利用休息的时间，让其自动测试。
* Oriented日志。主要用来追踪用户操作行为，方便测试路径重现，只用在测试阶段。
* 脚本Crash后台，脚本测试比较难以Debug，将xpcall捕捉到的日志提交后台，目前情况是有一个简单的JavaWeb日志追踪页面。所以只是作为内测用。
* 自动化测试的时候，可以借助xcode等工具来查看内存情况。

四、性能优化
1、纹理资源的优化、场景资源的优化
开发过程中，从严控制纹理，按照相应的Block合并大图，适当情况下，可以降低清晰度。另外场景管理包含资源的管理，例如某个动画在特定的场景中出现，我们可以直接将着部分资源在缓存中移除。
公共资源可以常驻在缓存中
如果对包体要求更严格，可以适当考虑将图片压缩成pvr格式(一种显卡可以直接识别的格式，目前市面上的刀塔传奇采用的这种方案)，但是这种情况是没有alpha通道的，也就是说透明度设置有问题，只能是作为一种备用方案。
2、将一些耗时的操作放在C++层，如读取配置文件，异步加载音频文件等等。
3、网络层采用多线程方式，以降低对主线程的影响。

五、质量及规格标准化
1、客户端架构标准
方案切实可行，并且性能是第一位的，或者说是开发效率上一个台阶。
2、代码开发标准
分两部分，第一部分是底层代码，健壮、高效，并且是讨论过、并切实可行。第二部分脚本代码需要从代码风格上进行管理上的强制要求。
3、代码Review标准
按照约定好的代码开发标准，切实实行，原则上实行捉对协作开发。

六、课题方案管理
适用范围：
1、架构及性能上的优化。
2、偏平台化的技术研究。
3、对性能提高、开发效率提高有明显帮助的技术点。
4、可开发工具及流程控制，甚至重构达到效率提升的。

七、安全相关
1、代码安全
客户端代码除了底层代码用C++以外，其它基本使用Lua脚本来开，所以脚本需要加密。以防止二次打包及非法行为。目前可以使用Cocos2d-x提供的xxtea加密策略。
2、支付安全
支付基本的参数不可暴露。

八、大厅架构
是一个最小资源包，只有一个登录到大厅的UI展示。可以不包括逻辑业务部分，然后再去热更新部想要玩的部分，一些公用部分完全可以设计放在这个版本内部。大体包括如下内容：
1、BaseCore部分
2、账号体系
3、热更功能
4、大厅UI
5、可以自由配置相关的模块来达到想要的包体
6、支付模块的基础部分

最理想化是可以如下操作，出某版本，后期想给这个版本加某个游戏，可以通过热更新的方式去更新。

模块化游戏大厅方案：
通过事件方式来注册游戏，通过配置来定好游戏中包含哪些模块，进行事件注册，然后再大厅打开模块后发送相应的事件去打开模块。

九、技术实现

9.1 技术选型及工程结构
综合选择Cocos2d-x3.11.1版本，更新了ipv6及openssl等相关内容。BaseCore版本我们用C++完成基本功能（暂时命名为theway），然后具体业务项目将theway引用作为依赖，并且业务开发使用Lua脚本开发。这样将底层跟业务解耦。另外为整合多个游戏带来最基本的技术上的支持。

9.2 自研引擎可行性
可以做成依赖项目，作为其他项目的底层，随着项目不断优化和集成可以衍生成一个拥有我们自己知识产权的引擎项目。这样底层修改或升级，只需要做兼容即可，大不必让业务开发受限。同时可以整合各项目的开发资源，提高开发效率，产品质量。

9.3 工具链开发
作为商业开发，开发工具的完善也是一项必不可少的环节，目的是为了提高产品开发的效率。例如我们利用工具提高开发效率的一个实际例子。用Python生成协议Bean来直接序列化消息内容，通过委托模式，业务模块只需要关注发送，返回协议回调函数收到一个Table，十分的方便好用。后面可以将一些重复工作用工具去做。
———————
作者：Diyal
来源：CSDN
原文：https://blog.csdn.net/diyal/article/details/54948858