战斗由客户端来做,后端来验证 方式 解决 一些弊端思路

探讨了游戏战斗系统中概率性控制的实现方式,分析了客户端与后端处理的利弊,提出了一种通过多套随机控制方案避免玩家修改概率的解决方案。

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

战斗由客户端来做,后端来验证  方式  原来 是 存在 弊端的,比如:一些概率性的 控制,这些概率性的控制如果交给客户端来做的话 势必会出现玩家自己来修改 这个概率的问题,那这些问题怎么解决呢,不解决的话就只能是后端做战斗,前端验证(这种方式如果整战报还好,如果是手动战报即一次出手就一份战报的话会经常出现由于网络延迟而造成战斗异常),那怎么解决这些概率性的问题呢?

---》可以让策划 把这些概率性的控制 搞成像皇帝转盘那样一连串的恶心的控制,可以多配几套这种控制,每次战斗时随机选择一套控制来让前端执行,每套控制里都有各自 自己的 概率性控制规则,这样玩家就算想改,也没得改,因为 已经配死 每种方案下概率控制的范围,比如a种方案,第一次概率肯定不触发,第二次按照什么样概率触发。。。而b中方案就有可能触发,触发概率多少,第二次肯定不触发。。。 等等通过这些多套方案 种 非常恶心的控制 来 避免 玩家 自己修改概率触发,因为玩家不知道有多少种方案,也不知道当前选择哪种方案,以及方案中的规则控制是什么,这样涉及 分 出手 来手动战斗发战报类型的战斗时就可以完全由前端 做战斗,等整个战斗完把 所有出手的战报一次性发给后端,后端来验证,后端可以通过保存的前端发来的战斗对应选择方案来对出手战报进行验证,只要有一个异常就判定该次出手不合法。

转载于:https://www.cnblogs.com/wzhanke/p/4762782.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值