|
|
文/问号是我
随着游戏开发的完整度提升，技能系统的设计复杂性也越来越高，导致了用模板方式的配置方法和处理方法会导致以下几个问题：
- 代码冗余
- 排错困难
- 配置项冗余
- 熟悉业务流程时间长
- 扩展性低
经过我思考决定重写之。分析以下几个观点，由于早期设计上的局限，和实际开发预期的不符，技能系统也必然会成为策划脑洞大开的一个点，并且也会成为MOBA游戏体验的深度核心项之一。于是一个成熟的MOBA技能系统应该包含一下几点：
- 代码流程清晰
- 错误定位精确
- 配置项定位精确
- 熟悉业务流程时间短
- 扩展性强
应该还有一些我没有想到或者没有记录到的点，在此就说明以上几个。
有一些程序在设计一些高扩展性同时又是核心要素的系统时，不出意外的也会遇到以上的几个问题。
这里的核心关键就是：
在设计之初对未来的需求是未知且不可预测的。
那么我是怎么解决以上的几个问题的呢？
因为我一直在使用 Unity 做前端开发。深知Unity的ECS (实体组件系统) 架构体系带来的便利。
于是我打算根据ECS的架构方式的模子去设计，但不完全根据ECS的架构来，保持对具体项目需求的贴切。
于是我设计了如下三个层：
有时候我认为这个设计很像行为树。好吧确实有点像，但又不是那么像。这里不深究，留疑。核心还是留在解决需求上。
流程控制层具备以下几个组件：
- CtrlBase -> 作为所有流程控制的基类
- CtrlBreak -> 用于中断所有流程控制组件
- CtrlCondition -> 用于流程控制中的分支操作
- CtrlDelayTime -> 用于流程控制中的延时执行操作
- CtrlDuration -> 用于在一段时间内执行一组动作
- CtrlSequence -> 用于序列执行一组动作
- CtrlTimeLine 组件 -> 用于创建一个时间轴，让所有流程组件在这个时间轴上执行
原子函数层（技能）具备以下几个组件：
- SkillCondition -> 提供技能条件的判定
- SkillEntity -> 提供技能实体的操作
- SkillFightObjMap -> 提供战斗对象查询获取等操作
- SkillInOutValueToPlayer -> 提供对战斗对象角色的数值输入输出
- SkillPlayuerCtrl -> 提供对角色的控制操作
- SkillTarget -> 提供技能对象的具体信息
逻辑层（技能）：
- SkillBase -> 所有逻辑层的基类 定义所有的技能逻辑层数据
- Hero1/skill_1 -> 英雄1的技能1逻辑对象
- Hero2/skill_2 -> 英雄2的技能2逻辑对象
...类推
从以上的结构中可以直接看出目前的冗余层在逻辑层，而逻辑层的支撑在控制层和原子函数层，随着开发深度的越来越高，控制层和原子函数层的操作组件会越来越多或功能性越来越强。则为逻辑层提供的操作/组合方式更为丰富，则可实现的动作会更为强大。
并且从排错来说只要控制层和原子层确保无误（实际也必须无误），基本错误定位能直接找到对应技能的逻辑层，且逻辑层没有多余代码，每一句都和技能的具体逻辑有所关联，线性排错。难度低。如若错误出在原子或控制层则是一批技能同时出现问题，也好定位。
所以这里已经做到代码流程清晰，错误定位精确。
同时因为每个技能有独立逻辑层则配置的定义也可以独立，这里也做到了配置项定位精确。
基于以上几点精确定位的特性导致熟悉业务的时间就因此变短了。
又因为原子函数层/控制层的支持性可扩展，具体技能的业务逻辑可定制，所以扩展性强了。
给予这种设计模式，带来的好处可见是非常大的，但是同时也导致了必须要让程序长期来维护或定制具体的技能模块。所以我一直认为策划是可以具备一些脚本功底的，只要我们保证原子函数层和控制层提供的是安全接口。则可以对策划放开脚本编写，甚至可以用弱类型解析类脚本语言来提供具体的技能逻辑定制。
还有一种方案是开发一款能够生成逻辑层的流程编辑器，将原子函数层和控制层反射导入。生成逻辑层代码。不过这个成本太高而且规则不好定制。有可能还没程序直接编程性价比更高。所以我没有选择开发流程编辑器的方式。
这个架构在我实际运用中，感觉还是非常好的，因为大多的技能其实相似性还是蛮高的，如果技能难度不高，原子函数不需要迭代添加，则进行逻辑组合的时候实际效率很高。我刚刚开发完这套系统，重构现有的技能（10个左右）也就花了3个小时左右吧。相比模板开发的方式我认为在定制和排错扩展的方面效率要高的多，而且对开发者的友好度更高。
总结下来我认为所有的设计都应该建立在更贴切实际开发需求上，我认为所有的系统设计都应该建立在需求的不可预知和灵活性扩展上，同时也需要衡量它的性价比，不做过度设计，不墨守成规。
via：符号乐园【原文】
|
|
发表于 2018-4-3 11:22:21