Buff系统框架设计

2024-04-03 22:31:14

Buff的配置文件

BufType: 1: 精神类Buf 2: 物理类Buf 3.元素类Buf 4.其他类Buf 5.被动类Buf
BufSubType: 1000-1999 精神子类 2000-2999.物理子类 3000-3999.元素子类 4000-4999.其他子类 5000-5999.被动子类。所以子类可以唯一标识一个Buff的类别
OppGroupId: 表明该GroupBuff互斥的BuffGroup.玩家身上只可能两种BuffSubType存在一种

RawBufDesc.xml
<RawBufDesc RawBuffId="RawBuff的ID" bProBaseDerivedWXImp="是否有基础参数" bCalcImp="是否影响公式计算" bEquipImp="是否影响装备限制计算" bNeedTick="是否需要被Tick"></RawBufDesc>

BufDesc.xml
<BufDesc BuffId="Buf的Id" Name="Buff名" BufType="技能大类，其实没什么用，只是用来进行额外索引。" BufSubType="Buff类别，类别写死了该类别的Buff是替代、叠加、同时存在" LifeCycleTime="Buff存在时间" bRemoveOnDead="是否死亡消失" bDebuf="是否损益Buff" bGoodBuf="是否增益Buff" bOnlyInFight="是否战斗中有效" bVisible="是否显示效果" bSaveDB="是否需要存数据库" BufLv="Buff的等级，决定替代、叠加关系" bManualRemove="是否手动移除" ViewOrder="图标顺序">
<RawBufInsList>
<RawBufInsDesc RawBuffId="产生的RawBuff序列" P1="RawBuff参数" P2="RawBuff参数">
</RawBufInsList>
</BufDesc>

BufGroupDesc.xml
<BufGroupDesc GroupId="BuffGroupId,基本无效" BufSubType="参考前面，这个就可以索引BuffGroup" OppGroupId="对抗的BuffGroupId(其实可以不要GroupId,只要BuffSubType)" Name="Buff组名">
<buf bufId="" level=""></buf>
<buf ...></buf>
</BufGroupDesc>

PropertiesDesc.xml 记录了所有游戏使用的属性内容，已经其对应的宏
<PropertiesDesc ProId="属性ID" name="宏参数" displayerName="" bVisible="" desc="">

Buff系统构成
RawBuff构成了Buff
Buff相同SubType的内容构成了BufGroup，如果没有BuffGroup的SubType可以相互替代
BuffGroup记录了可以叠加的SubType组，和叠加的Buff关系

Buff的流程
判定是否Buff能够Attach
=> TFightActor::GetFirstBufBySubType(iSubType) 获取身上该SubType的Buff
=> 比较需要添加的Buff和已经有的Buff的 BuffLevel.如果已经有更强大的则不能添加

Attach Buff流程
=> AttachBufWithCalc(_U32 iBuffId, _U32 iBuffInstanceId, _U32 iPeriod, TActorRecalcContext* pCtx)
=> CalcBufChangeWhenAttachBufById(_U32 iBuffId, U32& iAttachBufId, _U32& iPeriod, _U32& iDetachBufId, _U32& iDetachInstanceId) 该函数会调整最后生成的BuffId, 生存周期和Detach的BuffId, BuffInstanceId

通过iBuffId的SubType判定该Buff是有BuffGroup还是没有。如果有BuffGroup获取其在组里面的BuffLevel,否则BuffLevel为1

=> CalcBufChangeWhenAttachBufBySubType(_U16 iBufSubType, _U32 iBufId, _U32 iBufLevelInc, _U32& iAttachBufId, _U32& iPeriod, _U32 iDetachBufId, _U32& iDetachInsId)
SubType的替换类别是
a.同Bufid替换
查找身上第一个同个Buffid的Buffer，
如果有，
则Detach原来的Attach现在的,
否则只Attach现在的
b.同SubType替换
查找身上第一个同SubType的Buffer，
如果有，
则Detach原来的Attach现在的，
否则只attach现在的
c.同SubType同Level替换
查找身上第一个同SubType的Buffer，
如果没有，
则直接attach现在的；
如果有，而且新的Buffer BuffLevel更高，
则Detach原来的Attach现在的，
否则无法Attach
d.叠加
查找该SubType的BuffGroup，
如果不存在则无法attach
如果存在，则获取当前SubType的Buff的BuffLevel
如果存在，则Detach当前Buff, 计算当前BuffLevel+添加Buff的newBuffLevel计算出新的Buff.添加新的Buff
如果不存在，直接Attach当前Buff
e.叠加、对抗
查找是否存在该SubType对抗的SubType的Buff
如果不存在，则走叠加的逻辑
如果存在，则Detach对抗的Buff, 把newBuff的new BuffLevel和对抗的BuffLevel相减。Attach剩下的BuffLevel的BuffId
f.时间叠加
如果存在该BuffId则detach原来的，attach新的，但是period时间是新的+原来的剩余时间
g.直接添加
不管任何情况，直接添加

=> DetachBuf(_U32 iBuffId, _U32 iBuffInstanceId, TUpdateBufContext* pCtx)
遍历m_listBuff, if(pBuf->m_iId == iBuffId && (iBufInstance == 0 || pBuf->m_iInstanceId == iBufInstanceId)) DetachBuf(TBuff* pBuff, TUpdateBufContext* pCtx)
=>DetachBuf(TBuff* pBuff, TUpdateBufContext* pCtx)
pCtx记录Detach的BuffInstanceId, BuffDesc, DetachBuffCount
如果RawBuff列表在TFight的战斗Process中，删除
=>TFight::RemoveProcessRequeest(TRawBuff* pRawBuff)
把pRawBuff的Process从战斗的m_listProcessReqCtx里面移除，释放Process. RawBuff的内存资源还在哦
=> TFightActor::DetachBufInternal(TBuff* pBuf) Buff释放逻辑,(RawBuff没有内存释放哦)
遍历Buff的RawBuff里面
RawBuff::OnDetach()
从m_listRawBuffList清除RawBuff
从m_listBuffList清除Buff
=> TBuf::DestroyBuf(TBuf* pBuf)
释放Rawbuff内存
释放Buff内存

=> 如果Alive AttachBuf(_U32 iBufId, _U32 iBufInstanceId, _U32 iPeriod, TUpdateBufContext* pCtx)
=> TBuff::CreateBuf(_U32 iBuffId, _U32 iBuffInstanceId)
创建RawBuff对象
创建Buff对象
pBuff->m_iPeriod = iPeriod
pBuff->m_iCurrTime = 0

=>TFightActor::AttachBufInternal(TBuff* pBuf)
把pBuff放入m_listBuff
把pBuff的RawBuff数组放入m_listRawBuff
=>TBuf::OnAttach(TFightActor* pActor)
设置TBuff::m_pActor
设置TRawBuff::m_pActor

pCtx->m_arAttachBuf记录pBuff

=> TFightActor::RecalcPlayerSkillEquipBufProByCtx(TActorRecalcContext* pCtx, TActorRecalcContext* pPetCtx)
计算BuF属性影响
计算属性
校验属性

TickBuff流程
=> TFightActor::Tick
对需要进行Tick的RawBuff进行Tick操作
=>TRawBuff::Tick()
生成对应的客户端通知，跟技能是一样的，就是一个特效ID,还有相关参数，放入队列。
方式队列到客户端播放效果

服务器客户端同步协议
与技能相同的数据，是一个Process数组

Buff系统框架设计相关推荐

Asp.net基于工作流引擎的系统框架设计开发(源代码+论文)
工作流就是一系列相互衔接.自动进行的业务活动或任务.工作流引擎是工作流管理系统的核心,它的主要功能是通过计算机技术的支持去定义.执行和管理工作流,协调工作流执行过程中工作之间以及群体成员之间的信息交互 ...
Android源码分析（三）-----系统框架设计思想
一 : 术在内而道在外 Android系统的精髓在源码之外,而不在源码之内,代码只是一种实现人类思想的工具,仅此而已...... 近来发现很多关于Android文章都是以源码的方向入手分析Androi ...
追踪(trace)系统框架设计的思考
开发过稍微大一点的soa服务系统的程序员都听说过trace系统(但真正从零开始设计的人,我个人认为很少).为什么需要trace呢?原因是调用soa服务的调用链路太复杂(什么是调用链路,下面解释),tr ...
网络游戏战斗系统之buff系统具体设计实现
在网络游戏中的战斗形式多种多样,不同游戏的战斗逻辑也有很大的差异.但是一般都会涉及技能系统和buff系统,两种之间相互关联,技能可以产生buff作用在目标上,影响目标.同时buff也会影响技能的释放效 ...
再议成就系统框架设计
根据http://blog.csdn.net/heartrude/article/details/8523570的设计,其实还有几点可以优化 1.Group组的Buff是靠严格的配置的偏移量计算出来的 ...
【毕业设计】asp.net基于工作流引擎的系统框架设计开发(源代码+论文)
文章目录目录一.系统设计二.系统实现源文件目录一.系统设计 4.1模块的划分通过对用户需求调研并分析,确定系统应具备的功能,所需模块包括:状态图管理,任务管理,任务指派,任务提交. 4. ...
基于WPF系统框架设计(7)-TextBox/PasswordBox在ViewModel中支持回车命令
应用场景我现在做一个系统登录功能,要求在PasswordBox上输完密码后回车,能够响应Enter事件,并执行ViewModel中对应的方法.如果登录成功则隐藏当前窗口显示主窗体,登录失败则焦点返回 ...
《数字孪生虚拟电厂系统框架设计及其实践展望》——阅读笔记
数字孪生的典型特征 1.互操作性:物理实体和数字空间双向映射.动态交互和实时连接,因此物理-数字孪生系统能够量测获取实时数据更新数字模型,同时通过控制接口将数字模型中校正计算后的控制参数回传给实 ...
Java、JSP大阳电动车销售系统的设计与实现
随着国际互联网络的发展,各行各业以及人们的生活已经对网络形成了依赖,互联网络已经形成了一种非常重要经济模式,网络拉近了世界距离,网络销售渗透到了各个行业.电动车作为大众消费产品,而且是绿色环保交通工具 ...

最新文章

热门文章