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