初衷,回顾改进之前游戏中设计的优劣,设计出简单健壮稳定,可读可维护,可拓展,可测试的优雅程序。
基于弱联网模式,战斗逻辑全部在客户端,关键信息在服务器上同步跑,使用帧同步,基于投票的反外挂设计。
架构设计思路整理:
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
形,最好的代码是没有注释一目了然,但是不好表达或有歧义的一定要写清楚注释。