Re: [情報] 橘裝實際掉落率分析

[allbs (喵嗚)]

※ 引述《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%拿到橘裝)


--
o0 0o                            偉業：中立熊貓人 7.0                 ^____^   
 qop                                                                 / o00o \  
 \_/                      在漂流島上將一個熊貓人升級到110等          | \__/ |  
  V                                                                  11-25-16  
 http://imgur.com/0KYferU  http://imgur.com/GtI43Mu  http://imgur.com/t0jZC4r
CST 2016/11/25 07:09       (UTC 2016/11/24 16:09)    總遊戲時數5小時44分3秒

--
※ 文章網址: https://www.ptt.cc/bbs/WOW/M.1481105484.A.662.html
推 miaobee: QAQ??
推 tryagain24: @@?
推 devilshadow: 算了一堆數字還不是要看臉，省點力氣吧
推 w199381: 快推 不然讓人家以為我看的懂
推 luis0624: 推
推 HidakaShu: 喔喔原來如此 嗯嗯
推 marssss: 很有說服力的推論 不過在機率低到這個程度的情況下只能說
→ marssss: 臉還是最重要的
這樣子符合BZ所說的，只要夠努力，4橘不是問題
推 mystery7631: 累進算法對寫程式其實超麻煩的 每次都要計算後再相加  12/07 18:29
不會吧
有出就歸1，沒出就+1，有問題嗎
推 NoLimination: 那866天選之人的機率是?
推 greg7575: 102級的怎麼算？溢位了嗎
跟等級無關，我猜是最新改版時，讓路邊寶箱也增加開橘裝的行列
推 trance1204: 雖然看不懂~但好像很厲害
→ mystery7631: 一般是 1.看你幾橘訂個機率 2.在X橘形況下每50場或
會說幾場，那就是只管M+
但是因為還有WQ寶箱也要加在內，所以用幾場，會更麻煩
→ mystery7631: 100場機率+Y% 然後加到某個層度就終止 防止不可預期
→ mystery7631: 這樣不但好預期 也不用再額外消耗CPU的運算時間
推 marssss: 不是很同意樓上 因為loot event發生率其實很低 計算甚少
→ marssss: 照原po的模型也只需要一個counter累積總機率就好 剩下的
推 mystery7631: 我不知道啦 我七八年寫程式在寫機率是不會這樣
→ marssss: 靠loot event時的條件式判斷即可(n橘檢查)
→ mystery7631: 累加算法很容易搞成overflow現象 不知道有沒拚對
→ mystery7631: 基本上 能不要算就可以不要算 簡單幾個if就能搞定
→ mystery7631: 會啥還要消費cpu的運算 明明就可以規定好
推 marssss: 在這個模型下要overflow就算是初始機率KP也高得嚇人
→ marssss: 而且7.1改版當天發生的橘裝大放送可能就是counter未歸零
→ mystery7631: 很多時候 就只是官方中途機率更改了 前後產生了一個
→ marssss: 因為你需要一個有感的防臉黑機制 而且真的計算量低
mystery7631的說法是機率是固定的
很簡單，用EXL計算也很快
每次出橘裝的機率設定多少，是固定的，不累加
零件橘裝的人，178次KP後，會有91.66%的人會拿到橘裝
一件橘裝的人，287次KP後，會有48.17%的人拿拿到橘裝
二件橘裝的人，216次KP後，會有17.62%的人拿拿到橘裝
三件橘裝的人，165次KP後，會有 7.56%的人拿拿到橘裝
0-1橘的機率是0.014 時會逼近實測結果
1-2橘的機率是0.0023
2-3橘的機率是0.0009
沒有規律性
→ marssss: 會掉橘裝的event給你打一整天頂多發生幾十次 跟戰鬥計算
→ mystery7631: 數據，他可能只是某個參數調整後  前面+後面的結果
→ marssss: 相比實在連零頭都不算
→ mystery7631: 問題是 為啥需要自找麻煩 能不找麻煩就不要找麻煩
→ mystery7631: 你能節省 而且又有簡單的算法 為啥不採用
→ mystery7631: 你只要固定調整每幾場的參數 就好了
→ marssss: 因為原po提的模型符合數據證明...
推 paul26277: 簽名檔......(跪)
→ marssss: 也是要提一個符合防臉黑且能對應數據的模型吧?
推 mystery7631: 這數據從一開始就統計 結果是中間不知道調整多少次
→ mystery7631: 後產生的 所以吻合反而是奇怪的地方
→ mystery7631: 當然我不是說不可能拉 只是我工作多年還真沒人這樣寫
→ mystery7631: 可能暴雪的工程師有不一樣想法吧 我自己是覺得 結果
→ STGCBA: 反正一切都是運氣
→ mystery7631: 是多次調整後混和的 你不知道中間調整過了啥
實際結果是4週內、萬人統計數字
中間應該沒有什麼大改版或調整參數
只有BZ跳出來說有防臉黑機制而已
→ marssss: 只有過去四周 也就是7.1改版之後 而且限定在4橘以下
→ arcross: model fitting不就是把數字調到看起來很吻合嗎
→ mystery7631: 但一個結果可能只是 我想讓0橘的多5% 就這樣而已..
→ marssss: 這期間檯面上消息只有"取消4橘以上反臉黑機制"而已吧?
→ mystery7631: 然後結果 可能是 之前沒+5% 和後來+5%融合的
→ arcross: 是取消「四菊以上沒有房臉黑」
推 marssss: 如果是從7.0統計到現在的確會 但是1個月內...
→ mystery7631: 而且一個中等數據 可能是 2個極端值 融合成的結果
→ mystery7631: 除非你保證他概率和演算法都不變 那這模型就很正確
→ marssss: 所以才會是萬人統計 而不是看個別例子啊
→ mystery7631: 沒有說不可能 但我直覺是這種寫法很麻煩 僅供參考
→ marssss: 同版本短時間內(統計是11/26往前四周) 不變的可能性較大
→ mystery7631: 我說的極端值 是指他給定的演算法是極端的
→ marssss: 看錯 是11/23
推 bobby1028: 結論是拿5橘的是真天選者，前兩橘非核心砍角色比較快..
→ bobby1028: .偉哉BZ
→ mystery7631: 比如之前調橘裝的演算法可能是每場 0.1% 過50場0.2%
→ mystery7631: 7.1可能改成每場0.5% 過50場1% 這種極高極低的調整
推 mystery7631: 幾場 是指事件 你只要把每個事件 給予一個屬性 他就
推 theget3874: D3也是裝備掉落池不對就重練啊 只是團隊沒想到的是魔
→ theget3874: 獸重練要多久 更別提還有神兵XD
→ mystery7631: 屬於那個物件 只要計算物件就知道該種事件發生多少次
→ mystery7631: 我看你回應就知道你根本沒寫過程式 沒啥好聊的lol
→ mystery7631: 要改機率也不會照你這樣改 我認真的 最近剛好負責
我不會寫程式，我只是單純覺得一個很怪的點
我的模組要計算場次，你的模組也要計算場次
那有什麼不一樣的地方而已
→ ttt95217: 少年別激動
※ 編輯: allbs (123.205.107.42), 12/07/2016 19:13:41
推 mystery7631: 場次是一定有的 你每進去 最少是一個事件 最少會給你
→ mystery7631: 一個UUID 就是絕對辨識碼 統計場次這些都是小運算
→ mystery7631: 但float相加 相乘 對cpu的運算是耗蠻大的
→ mystery7631: 機率這種很敏感的東西更不太可能去直接累加
推 ZJerry: 感覺討論是平行線，原PO這篇文也沒說程式怎麼寫的
→ ZJerry: 只是提出機率可能是怎樣累加而已
這是真的
※ 編輯: allbs (123.205.107.42), 12/07/2016 19:24:05
→ asgard1991: 說到CPU負載突然想到之前的123Lag會不會其實是同時太
→ asgard1991: 多拾取運算結果卡住了XD
推 Marabuda: 先推再說以免人家以為我看不懂
→ mystery7631: 應該是這個 但更多原因應該是沒寫好 或CPU不給力
→ arcross: 其實是同時太多人打123 造成cpu負載過高 導致更多人打123
→ mystery7631: 其實MMO是非常消耗CPU的類型 因為交互這事情 不能
推 izplus: 最近沒123，可是延時變長了
→ mystery7631: 分批處理 很多不能寫成柱列(queue)來處理 要及時
→ mystery7631: 然後弄不好 沒同一frame處理完 跑去下一frame 就會
→ mystery7631: 有不可預期的情況發生 像WOW機制太多很容易爆
推 tony77731: 原文列表有人416KP出4橘 也有人731KP0橘 對BZ失望了
推 hansen5026: 趕快推文免得別人以為我看不懂
推 evaal: 提出可能性，不代表確信並要說服其他人事情就是這樣，理性
→ evaal: 勿戰。   QAQ
推 aynydy: 這樣看起來 狂刷H隨機似乎最划算 每一個王都有給KP?
推 apley: 嗯嗯，喔喔，是醬子啊。
推 henry1234562: 當然是先刷一遍M阿
推 evan700607: 0-1 臉 1-2 臉 2-3 臉 3-4 生辰八字
推 roea68roea68: 有可能啊 也不是沒有前例 事實上爐石不就是這樣搞..
→ roea68roea68: 當然爐石寬鬆許多 越接近40包沒橘機率越大 最差40包
→ roea68roea68: 但原理上應該會是一樣的 同公司用同樣系統也不意外
推 lpb: 快推，假裝自己看的懂。
推 dh3014: 以工程師的角度來看其實可能性真的滿高的
推 bally0527: 這太專業了
推 marssss: 說到底這麼多機率的東西還用浮點數運算才叫浪費CPU...
→ marssss: 都已經覺得很專業了還不用整數去逼近運算才奇怪
推 XDXDXD8022: 上一個祈倫托開到第3 今天開到第4..
推 barboo007: 借問，同帳號的橘裝拾取是一起算的？
→ zseineo: 看角色
推 mystery7631: 對阿 所以才說if判斷就能解決的問題 不用機率累加lol