手游客户端设计思路整理

初衷，回顾改进之前游戏中设计的优劣，设计出简单健壮稳定，可读可维护，可拓展，可测试的优雅程序。

基于弱联网模式，战斗逻辑全部在客户端，关键信息在服务器上同步跑，使用帧同步，基于投票的反外挂设计。

架构设计思路整理：

1.客户端划分层次管理，管理器依赖接口，CObjMgr客户端做表现和表现相关的动态运算, SObjMgr存放关键数据如基础属性道具加成。拆分复杂的数据泥团。

 

2.基于接口和组件式设计，避免继承不够灵活拓展，如AnimCtrl，MoveCtrl。注意接口不要污染，组件要划分清晰保持单一职责(拆分变化)。

 

3.服务端业务功能抽象为独立数据组件，复杂总是可以抽象分解和中间件解决，例如AttributeData, BuffData。

 

4.通信机制：组件外通过广播，组件内通过消息，实现基于订阅/发布的观察者模式，因为一个Player数据的改变可能影响多个表现，传递参数用object结构体。C端需要主动获取S端数据，用查询模式(统一客户端对象id和服务端id)，拿到服务端id，并获取具体数据组件。

 

5.用Unity c#开发模式，暂时不考虑引入lua

用lua优点：

避免一个ui位置不对，纹理资源异常，字体大小和对齐问题，关键是sdk计费接入流程变更导致频繁出大版本。

用Lua缺点：

调试不方便，多语言切换开销。

除了一些没必要的冗余和交互栈访问开销，最困难的是游戏几乎都是业务逻辑，需要大量精力去划分稳定的模块，除非全部业务在Lua否则很难保证C#不用更新。

 

思路：

C#做战斗逻辑和数据是稳定层(包括网络协议)，网络消息不变，计费SDK不变更的情况下，不用出版本。

Lua只做UI表现和计费流程和秘钥存储逻辑，ui数据在C#层, 保持只有一份数据。

C#和lua间数据交互，用订阅发布模式。

C#->lua传递数据组件类引用刷新观察者，lua主动获取数据则仅通知消息ID给C#,C#回调刷新结果。

总结: 基于当前游戏类型，为了提高效率，全部用c#实现，不得已才引入lua.

 

6.Crash避免，独立模块间，尽量强绑定，资源管理用引用计数的内存池实现，提高场上单位的重用提升性能。

 

7.对于重构和设计模式，类的设计如果用到继承，尽量对修改开放对稳定逻辑关闭。要不断重构代码，合适设计模式都可使用。

 

8.战斗框架，单位组件化，技能模板化，ai用行为树模板化，技能实例由技能模板和异步事件系统实现，服务器发送消息驱动客户端进行。

9.编码规范，通用的，微软或google或linux形，最好的代码是没有注释一目了然，但是不好表达或有歧义的一定要写清楚注释。