手游客户端设计思路整理

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

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

架构设计思路整理：

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 形，最好的代码是没有注释一目了然，但是不好表达或有歧义的一定要写清楚注释。