回合制-战斗机制-实现分析

本文分析了回合制游戏的战斗机制实现,探讨了两种方案:方案一是服务器计算所有战斗数据,但面临交互处理复杂的问题;方案二是客户端参与战斗逻辑处理,减少了数据传输量,但需要客户端和服务端同步技能逻辑。通过实例比较,提出了利用树形结构表示战斗序列,以及处理技能交互和CD状态的方法,适用于不同类型的回合制战斗模式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

记录一下,想到哪里写到哪里。

回合制游戏一般流程是

一定时间内等待玩家输入,服务器计算该回合战斗数据,客户端收到数据后进行画面表现。

以此循环到战斗结束.

设计难点在于服务器返回怎样的数据结构,既简单又实现方便,数据量小,等具备常规工程化的特点。

 

梦幻举例:

1.对于一些概率性的技能等,输出肯定是一个确定的,比如触发or未触发。

2.对于伤害数值,输出的是一个具体数字,包含暴击,等相关信息。

方案1:

数据格式如果基于招式(技能,平A也可以看做是一个技能)的话,那么每个可攻击单位的每次攻击行为的数据可能像这样

172210_hQaB_1391394.png

对于一次完整的战斗,可达20个单位,每个单位的每次攻击大约是 220字节,一个回合大约就是4kb的数据量,最大上限可能是9kb。对于一个10回合的战斗,将会是40kb,还没包括玩家信息召唤兽信息等数据

173101_vU2n_1391394.png

官网找的一个录像帮战5回合,

每个 回合攻击序列都是这样一个SkillAction数组,依次播放,这样做存在的问题。是如果有技能是和该攻击行为有交互,比如反震,那么就很棘手了。方案1 pass

 

方案2:

根据方案1的缺点,方案2做了如下改进,客户端参与战斗逻辑处理,对于数值,几率等是服务器发送的,其余都可以是本地产生的结果。就算出外挂也只会影响他本人的体验,关键数据都是在服务器。这样的话,同一个技能,对应的数据客户端和服务端可能就很不一样

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值