求求管理看看这些建议有没有实现的可能！

深澜

逮住腿打断 发表于 2024-5-25 13:18
不过你这个建议 具体能不能实现你心中的完美模式 就看秃驴了   我们可以拓展出组队撸怪的思路出来 不过要 ...

你还是没看懂，我服。
那我再跟你说一下，不是你想的那样。
不是检测组队后队员伤害的排名，是检测多个队伍伤害的排名。
比如一个怪，有5个目标参与，有的目标是个人，有的是队伍。
那有队伍的是不是应该按队伍为单位做为统计，才合理和科学？
这里的统计队伍伤害是指以队伍为统计单位。
比如：1队打了35%的伤害，2队打了30%，3队打了25%，4队打了20%，5队打了15%

现有模式的问题，第一个打怪的人不死，不脱怪，怪死后，奖励只有他及他所在的队伍的成员。
如果第一个打怪的人死了，又归他死后第一个打那怪的人，总之就是，怪的死后，爆的东西只有少部分人能获取。
而新建议的这个模式是根据伤害来，是为了让所有参与了的人都有机会读取一次爆率，且分配机制更公平，那就是按伤害来，而不是看谁先出手，也不是看谁运气好，在上一个人死后谁打第一下。

深澜

逮住腿打断 发表于 2024-5-25 13:18
不过你这个建议 具体能不能实现你心中的完美模式 就看秃驴了   我们可以拓展出组队撸怪的思路出来 不过要 ...

接上一条，
假如有多个队伍参与打怪。
举例：1队打了35%的伤害，2队打了30%，3队打了25%，4队打了20%，5队打了15%

等于说是让这五个队伍在怪死的时候都读取爆率，
但又要如何区分他们呢，就是以他们的伤害比例做为基础系数，
即，1队以35%做为基础概率因子，
2队以30%……以此类推。

1580

深澜 发表于 2024-5-25 14:11
接上一条，
假如有多个队伍参与打怪。
举例：1队打了35%的伤害，2队打了30%，3队打了25%，4队打了20%，5 ...

程序现有的执行逻辑并非你想的，N组队打过怪，每组成员都去判断物品是否可爆出，是不现实的。

怪死亡时，只会找最合适的一个对像，使用其的爆率，与怪爆率列表进行运算，选出可以爆出物品

至于你说的多个队伍打怪，换算成每个人伤害累积值，最终也只有一个累积值最高的人物，胜出，至于你要把物品分给全队，那是另一个问题了
---------------------------------------------------
所以，基于以上规则，你所说的爆率配置，是没办法实现的，

格式：机率A/机率B RANDOM"[1/1]物品1|[1/2]物品2|[1/1]物品3" 数量 变量名 检测符(><=) 检测数量 操作类型(0-不操作 -减 +加 =等) 操作数量 是否轮巡

1580

一定要实现组队轮巡，只能定义怪物掉落模式

伤害累积值(个人、组队成员都可捡)
伤害累积值【组队轮巡】(有组队时，所有成员轮巡分配;无组队归个人)

师父

有想法固然是好，不过也不能想一出是一出吧，不要听一些人的拉跨意见，

深澜

1580 发表于 2024-5-25 15:32
程序现有的执行逻辑并非你想的，N组队打过怪，每组成员都去判断物品是否可爆出，是不现实的。

怪死亡时， ...

N组队打过怪，每组成员都去判断物品是否可爆出，是不现实的。

是为什么呢，我看你前几条说的，大概的意思是只能获取到最终打怪伤害最多或者最后杀死怪的那个目标的对象么。
这，怎么说呢，
引擎应该是C语言写的吧，虽然c语言编程我不会，但引擎开发lua脚本,对lua学了点皮毛，就以lua的实现思路说下吧，你看用c能实现同样的效果不。

打过怪的目标的对象以及伤害数据都存到一个数组里，这不就有所有打过怪的对象和伤害都有了吗？

当然，为了减少计算量，那就得减少对象数量，所以这里面有优先级，有队的，这个对象名字以队为单位，没队的才以个人为单位。

然后怪物死亡的时候，对这些数组进行排名，就能获得排名的对象了么，就不只有伤害最大的那个对象了呀。
能获得以上对象，那在怪物死亡后，让达到条件的对象都读取一次爆率，这不就实现了吗。

1580

深澜 发表于 2024-5-25 16:26
N组队打过怪，每组成员都去判断物品是否可爆出，是不现实的。

是为什么呢，我看你前几条说的，大概的意 ...

上面我已说过了，只能一个击杀者，进爆率文件计算，

至于为什么，自己想下不就知道了吗，N组，Y人，同个文件，例文件有1000行，需要执行的次数：1000*N*Y，真这样搞，杀一个怪，那么大的计算量，玩家基本上会感觉很卡，可以参考怪物死亡物品直接入包的功能，当一个爆率文件很多时，不停的执行，其它玩家就会感觉很大的卡，即，怪处理耗时过长，

深澜

1580 发表于 2024-5-25 16:30
上面我已说过了，只能一个击杀者，进爆率文件计算，

至于为什么，自己想下不就知道了吗，N组，Y人，同个 ...

这个是别的游戏里的这个模式的介绍。

深澜

1580 发表于 2024-5-25 16:30
上面我已说过了，只能一个击杀者，进爆率文件计算，

至于为什么，自己想下不就知道了吗，N组，Y人，同个 ...

嗯。明白你的意思，但实际应用过程中，应该不会有你说的那么夸张。

1、这种团战boss肯定不会设置爆垃圾，那么要爆的重要的东西数量肯定不会那么多，不会有你说的一个文件有1000行爆率内容。，
2、可以让gm自行设置一个计入计算的数值，达到多少比例伤害的加入计算，刚才我发了一张图，说是团队伤害达到0.1%，当然，咱们可以提高这个门槛，那么要计算的量就大大减少了，不会说打一点都要去计算。
3、通过第二条的过滤后，并且在实际运行中，一个boss打下来，基本上排名第1、2 、3的三个队伍就能抢掉90%的伤害，余下10%也分不了几个队伍，也就是说最终有资格触发爆率的队伍数量其实并不会太多，那么总的人数下来也并不会很夸张。

补充内容 (2024-5-25 16:56):
再补充一点，而且执行计算的时候，可以做分批计算，不同时计算，比如，排名1的对象执行了后排名2的对象再执行以此类推

补充内容 (2024-5-25 16:59):
上面补充说明说错了，是执行读取爆率的时候，是达到条件的对象不同时执行，是分批执行，1执行后设置一个延迟时间，然后2再执行……

1580

深澜 发表于 2024-5-25 16:33
这个是别的游戏里的这个模式的介绍。

可以理解成：伤害者均有机率获得；爆率文件逐行 判断，伤害者机率 决定物品归谁

主要，这个就受数量的影响，如参与人员过多，处理就会慢，是否可以优化为前10位或前X位参与者，进行计算 ，

爆出物品，是没办法做什么分段的，你想，怪都死了，物品还不显示出来，根本行不通