Re: [情报] 橘装实际掉落率分析

楼主: allbs (喵呜)   2016-12-07 18:11:17
※ 引述《Esun0104 (尚恩)》之铭言:
: 在巴哈看到有人贴,点进去看觉得很有意思,没人发我来简单分享一下。
: 英文数学样样不通,有错欢迎各位指正与鞭笞。
: 原文:https://goo.gl/dXniia
: 简单说一下,这个作者很有才,使用了PHP机器人去wowprogress.com上面
: 捞了单一欧洲服务器近万人过去4周的橘装获得状况来分析。
: 我的理解是他透过橘装获取管道对应橘装获取数量,为每一个橘装获取
: 的管道定义了一个KP分数如下,分数越高应该是取得的机率越大。
: 要注意的是,这仅仅为数据分析结果,并不代表真实的掉落率,实际掉落率
: 只能等BZ自行公布才能知道。
: http://i.imgur.com/1nl1zQ3.gif
: 这样同学们有没有比较了解呢?
先说结论,我之前的论点是4件以下时
出橘装的机率是会随着每次出橘失败累计到下一次
简单说,一橘不染的人,第一次出橘的机率是假设是1%,那下次出橘机率就2%、3%累加
这样对工程师来说,只要调整机率参数,就可以轻松达成
为了证明理论,用不同的参数去逼近实际数字,结果发现我这理论蛮符合的
0橘的人,每次出橘装的机率是0.015 % * N, N等于会调橘装的参与度
1橘的人,每次出橘装的机率是0.0015% * N, N等于会调橘装的参与度
2橘的人,每次出橘装的机率是0.0008% * N, N等于会调橘装的参与度
3橘的人,每次出橘装的机率是0.0006% * N, N等于会调橘装的参与度
4橘以上机率不明,没有累加出装机率
虽然没办法证明我的理论是对的,但是参数上看起来就很完美,
对照万人实验中,从0到1出橘装的机率
没有橘装的人,178次KP后,会有91.66%的人会拿到橘装
一件橘装的人,287次KP后,会有48.17%的人拿拿到橘装
二件橘装的人,216次KP后,会有17.62%的人拿拿到橘装
三件橘装的人,165次KP后,会有 7.56%的人拿拿到橘装
请准备一个EXL表格
0->1橘
A B C D E F G
D=B*C E=1-D F1=1-E1 G=1-F
F2=F1*E2
KP数 初始机率 倍数 拿到橘装机率 该次没拿到橘装机率 全部MISS的机率 拿到1橘机率
1 0.0150% 1 0.0150% 99.9850% 99.9850% 0.01%
2 0.0150% 2 0.0300% 99.9700% 99.9550% 0.04%
3 0.0150% 3 0.0450% 99.9550% 99.9100% 0.09%
4 0.0150% 4 0.0600% 99.9400% 99.8501% 0.15%
178 0.0150% 178 2.6700% 97.3300% 8.9701% 91.03%
(实测91.66%拿到橘装)
1->2橘
KP数 初始机率 倍数 拿到橘装机率 该次没拿到橘装机率 全部MISS的机率 拿到1橘机率
1 0.0015% 1 0.0015% 99.9985% 99.9985% 0.00%
2 0.0015% 2 0.0030% 99.9970% 99.9955% 0.00%
3 0.0015% 3 0.0045% 99.9955% 99.9910% 0.01%
4 0.0015% 4 0.0060% 99.9940% 99.9850% 0.01%
287 0.0015% 287 0.4305% 99.5695% 53.7507% 46.25%
(实测48.17%拿到橘装)
2->3橘
KP数 初始机率 倍数 拿到橘装机率 该次没拿到橘装机率 全部MISS的机率 拿到1橘机率
216 0.0008% 216 0.1728% 99.8272% 82.8949% 17.11%
(实测17.62%拿到橘装)
3->4橘
KP数 初始机率 倍数 拿到橘装机率 该次没拿到橘装机率 全部MISS的机率 拿到1橘机率
165 0.0006% 165 0.0990% 99.9010% 92.1090% 7.89%
(实测 7.56%拿到橘装)
作者: miaobee (阿力)   2016-12-07 18:15:00
QAQ??
作者: tryagain24 (wilson156)   2016-12-07 18:15:00
@@?
作者: devilshadow (大湿胸)   2016-12-07 18:20:00
算了一堆数字还不是要看脸,省点力气吧
作者: w199381 (恶心肥宅)   2016-12-07 18:22:00
快推 不然让人家以为我看的懂
作者: luis0624 (小柏)   2016-12-07 18:23:00
作者: HidakaShu (カタルシスカイハイ)   2016-12-07 18:25:00
喔喔原来如此 嗯嗯
作者: marssss (算不完的MC)   2016-12-07 18:27:00
很有说服力的推论 不过在机率低到这个程度的情况下只能说脸还是最重要的
作者: NoLimination (啊啊啊啊)   2016-12-07 18:29:00
那866天选之人的机率是?
作者: greg7575 (顾家)   2016-12-07 18:30:00
102级的怎么算?溢位了吗
作者: trance1204 (Trance)   2016-12-07 18:30:00
虽然看不懂~但好像很厉害
作者: mystery7631 (超潮设计师)   2016-12-07 18:30:00
一般是 1.看你几橘订个机率 2.在X橘形况下每50场或100场机率+Y% 然后加到某个层度就终止 防止不可预期这样不但好预期 也不用再额外消耗CPU的运算时间
作者: marssss (算不完的MC)   2016-12-07 18:32:00
不是很同意楼上 因为loot event发生率其实很低 计算甚少照原po的模型也只需要一个counter累积总机率就好 剩下的
作者: mystery7631 (超潮设计师)   2016-12-07 18:34:00
我不知道啦 我七八年写程式在写机率是不会这样
作者: marssss (算不完的MC)   2016-12-07 18:34:00
靠loot event时的条件式判断即可(n橘检查)
作者: mystery7631 (超潮设计师)   2016-12-07 18:35:00
累加算法很容易搞成overflow现象 不知道有没拼对基本上 能不要算就可以不要算 简单几个if就能搞定会啥还要消费cpu的运算 明明就可以规定好
作者: marssss (算不完的MC)   2016-12-07 18:37:00
在这个模型下要overflow就算是初始机率KP也高得吓人而且7.1改版当天发生的橘装大放送可能就是counter未归零
作者: mystery7631 (超潮设计师)   2016-12-07 18:38:00
很多时候 就只是官方中途机率更改了 前后产生了一个
作者: marssss (算不完的MC)   2016-12-07 18:38:00
因为你需要一个有感的防脸黑机制 而且真的计算量低会掉橘装的event给你打一整天顶多发生几十次 跟战斗计算
作者: mystery7631 (超潮设计师)   2016-12-07 18:39:00
数据,他可能只是某个参数调整后 前面+后面的结果
作者: marssss (算不完的MC)   2016-12-07 18:39:00
相比实在连零头都不算
作者: mystery7631 (超潮设计师)   2016-12-07 18:40:00
问题是 为啥需要自找麻烦 能不找麻烦就不要找麻烦你能节省 而且又有简单的算法 为啥不采用你只要固定调整每几场的参数 就好了
作者: marssss (算不完的MC)   2016-12-07 18:41:00
因为原po提的模型符合数据证明...
作者: paul26277 (空杯子)   2016-12-07 18:42:00
签名档......(跪)
作者: marssss (算不完的MC)   2016-12-07 18:44:00
也是要提一个符合防脸黑且能对应数据的模型吧?
作者: mystery7631 (超潮设计师)   2016-12-07 18:49:00
这数据从一开始就统计 结果是中间不知道调整多少次后产生的 所以吻合反而是奇怪的地方当然我不是说不可能拉 只是我工作多年还真没人这样写可能暴雪的工程师有不一样想法吧 我自己是觉得 结果
作者: STGCBA (我不是乳牛)   2016-12-07 18:51:00
反正一切都是运气
作者: mystery7631 (超潮设计师)   2016-12-07 18:51:00
是多次调整后混和的 你不知道中间调整过了啥
作者: marssss (算不完的MC)   2016-12-07 18:52:00
只有过去四周 也就是7.1改版之后 而且限定在4橘以下
作者: arcross (阿插)   2016-12-07 18:52:00
model fitting不就是把数字调到看起来很吻合吗
作者: mystery7631 (超潮设计师)   2016-12-07 18:52:00
但一个结果可能只是 我想让0橘的多5% 就这样而已..
作者: marssss (算不完的MC)   2016-12-07 18:53:00
这期间台面上消息只有"取消4橘以上反脸黑机制"而已吧?
作者: mystery7631 (超潮设计师)   2016-12-07 18:53:00
然后结果 可能是 之前没+5% 和后来+5%融合的
作者: arcross (阿插)   2016-12-07 18:55:00
是取消“四菊以上没有房脸黑”
作者: marssss (算不完的MC)   2016-12-07 18:55:00
如果是从7.0统计到现在的确会 但是1个月内...
作者: mystery7631 (超潮设计师)   2016-12-07 18:56:00
而且一个中等数据 可能是 2个极端值 融合成的结果除非你保证他概率和算法都不变 那这模型就很正确
作者: marssss (算不完的MC)   2016-12-07 18:57:00
所以才会是万人统计 而不是看个别例子啊
作者: mystery7631 (超潮设计师)   2016-12-07 18:58:00
没有说不可能 但我直觉是这种写法很麻烦 仅供参考
作者: marssss (算不完的MC)   2016-12-07 18:59:00
同版本短时间内(统计是11/26往前四周) 不变的可能性较大
作者: mystery7631 (超潮设计师)   2016-12-07 18:59:00
我说的极端值 是指他给定的算法是极端的
作者: bobby1028 (=Bobby=)   2016-12-07 19:00:00
结论是拿5橘的是真天选者,前两橘非核心砍角色比较快...伟哉BZ
作者: mystery7631 (超潮设计师)   2016-12-07 19:00:00
比如之前调橘装的算法可能是每场 0.1% 过50场0.2%7.1可能改成每场0.5% 过50场1% 这种极高极低的调整几场 是指事件 你只要把每个事件 给予一个属性 他就
作者: theget3874 (墨鱼)   2016-12-07 19:06:00
D3也是装备掉落池不对就重练啊 只是团队没想到的是魔兽重练要多久 更别提还有神兵XD
作者: mystery7631 (超潮设计师)   2016-12-07 19:06:00
属于那个物件 只要计算物件就知道该种事件发生多少次我看你回应就知道你根本没写过程式 没啥好聊的lol要改机率也不会照你这样改 我认真的 最近刚好负责
作者: ttt95217 (略)   2016-12-07 19:09:00
少年别激动
作者: mystery7631 (超潮设计师)   2016-12-07 19:11:00
场次是一定有的 你每进去 最少是一个事件 最少会给你一个UUID 就是绝对辨识码 统计场次这些都是小运算但float相加 相乘 对cpu的运算是耗蛮大的机率这种很敏感的东西更不太可能去直接累加
作者: ZJerry (杰瑞)   2016-12-07 19:15:00
感觉讨论是平行线,原PO这篇文也没说程式怎么写的只是提出机率可能是怎样累加而已
作者: asgard1991 (蟹脚)   2016-12-07 19:28:00
说到CPU负载突然想到之前的123Lag会不会其实是同时太多拾取运算结果卡住了XD
作者: Marabuda (Marabuda)   2016-12-07 19:29:00
先推再说以免人家以为我看不懂
作者: mystery7631 (超潮设计师)   2016-12-07 19:30:00
应该是这个 但更多原因应该是没写好 或CPU不给力
作者: arcross (阿插)   2016-12-07 19:30:00
其实是同时太多人打123 造成cpu负载过高 导致更多人打123
作者: mystery7631 (超潮设计师)   2016-12-07 19:31:00
其实MMO是非常消耗CPU的类型 因为交互这事情 不能
作者: izplus (izplus)   2016-12-07 19:31:00
最近没123,可是延时变长了
作者: mystery7631 (超潮设计师)   2016-12-07 19:32:00
分批处理 很多不能写成柱列(queue)来处理 要及时然后弄不好 没同一frame处理完 跑去下一frame 就会有不可预期的情况发生 像WOW机制太多很容易爆
作者: tony77731 (...)   2016-12-07 19:51:00
原文列表有人416KP出4橘 也有人731KP0橘 对BZ失望了
作者: hansen5026 (瀚生)   2016-12-07 20:00:00
赶快推文免得别人以为我看不懂
作者: evaal (AL)   2016-12-07 20:12:00
提出可能性,不代表确信并要说服其他人事情就是这样,理性勿战。 QAQ
作者: aynydy (老虎)   2016-12-07 20:17:00
这样看起来 狂刷H随机似乎最划算 每一个王都有给KP?
作者: apley (佛渡有缘人)   2016-12-07 20:18:00
嗯嗯,喔喔,是酱子啊。
作者: henry1234562 (亨利二十三)   2016-12-07 20:21:00
当然是先刷一遍M阿
作者: evan700607 (NO MATTER)   2016-12-07 22:35:00
0-1 脸 1-2 脸 2-3 脸 3-4 生辰八字
作者: roea68roea68 (なんもかんも政治が悪い)   2016-12-08 02:24:00
有可能啊 也不是没有前例 事实上炉石不就是这样搞..当然炉石宽松许多 越接近40包没橘机率越大 最差40包但原理上应该会是一样的 同公司用同样系统也不意外
作者: lpb (Θ_Θ)   2016-12-08 09:30:00
快推,假装自己看的懂。
作者: dh3014 (丝弦裂帛只字动天)   2016-12-08 10:20:00
以工程师的角度来看其实可能性真的满高的
作者: bally0527 (Stanley)   2016-12-08 10:45:00
这太专业了
作者: marssss (算不完的MC)   2016-12-08 10:54:00
说到底这么多机率的东西还用浮点数运算才叫浪费CPU...都已经觉得很专业了还不用整数去逼近运算才奇怪
作者: XDXDXD8022 (XDXDXD8022)   2016-12-08 10:56:00
上一个祈伦托开到第3 今天开到第4..
作者: barboo007   2016-12-08 11:34:00
借问,同帐号的橘装拾取是一起算的?
作者: zseineo (Zany)   2016-12-08 11:50:00
看角色
作者: mystery7631 (超潮设计师)   2016-12-08 13:32:00
对阿 所以才说if判断就能解决的问题 不用机率累加lol

Links booklink

Contact Us: admin [ a t ] ucptt.com