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