Re: [閒聊] 賭場翻牌(POKER)兩三事

[asLay (老詩)]

要數據其實可以到wiki底下看

‧ポーカー連続1000回やってみた。２～7はhigh、8～AはLowを選択。
ダブルアップ：278回。メダルの獲得上限まで到達した回数：22回。途中でDアップ回数
上限到達：0回。
2↑×：0 ｜ 3↑×：8 ｜ 4↑×：7 ｜ 5↑×：13 ｜ 6↑×：27 ｜ 7↑×：44
 8↓×：56 ｜ 9↓×：30 ｜ 10↓×：26 ｜ J↓×：23 ｜ Q↓×：16 ｜ K↓×：6 ｜
 A↓×：0
撲克1000回  遵守2~7選high 8~a選low
278回進翻倍   超過5萬有22回
D up(?)0回

‧ダブルアップ200回、2～7は↑、8～Aは↓で、それぞれの数字での勝率だしてみた。
K:91%、Q:82%、J:70%、10:79%、9:62%、8:29%、7:61%、6:60%、5:67%、4:70%、3:78%
-- 2014-11-07 (金) 17:16:09
‧↑
進翻倍200回  2~7選high 8~a選low 各數字勝率如下

‧同じくダブルアップ1000回で勝率出してみました。3～7は↑、8～Kは↓です。因みに
ドローは抜いて計算してます。
3:95%、4:85%、5:82%、6:67%、7:60%、8:49%、9:66%、10:71%、J:69%、Q:82%、K:95%
-- 2014-11-08 (土) 20:28:52
(跟上面那差不多意思不過是1000回)

‧200回統計出現率、2:5.3% 3:7.7% 4:5.9 5:6.9% 7:7.9% 8:9.6% 9:9% 10:10%
J:5.3% Q5.3% K:9% A:3.7%
 HL確率　H/D/L 2:100%/0%/0% 3:79%/21%/0% 4:100%/0%/0% 5:85%/0%/15%
6:46%/25%/29% 7:59%/12%/29% 8:38%/7%/55% 9:35%/0%/65% 10:47%/0%/53%
J:20%/0%/80% Q:10%/0%/90% K:5%/0%/95% A0%/0%/100%
200回統計  單牌出現率是這樣(略)
High/平/low 下一個出牌統計是這樣(略)



--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.37.221.243
※ 文章網址: https://www.ptt.cc/bbs/GBF/M.1462338342.A.7E4.html
※ 編輯: asLay (114.37.221.243), 05/04/2016 13:19:29
→ Qoo777: 這種是給程式跑的 還是實際玩碧藍得出的結果?
→ asLay: wiki留言 不知統計方法
→ Qoo777: 而且我說的1000回 不是指進双倍的總合數 而是100 300 400
→ Qoo777: 500 各勝率要分開算  重點是 超過100的局 電腦有無作弊
→ asLay: 如果電腦在某回合作弊了  那他就必須要在某回合補回機率
→ asLay: 長期來看 我覺得你統計那些沒什麼意義啦
→ Qoo777: 會補回 但想想500能贏到上限的時間快 還是100 一樣機率
→ Qoo777: 證明CY為了要讓玩家更久的耗在賭場 更動不符合常數的機率
→ Qoo777: 還有比起撲克 我討厭賓果 所以借統計機會 順便把賭場畢業
推 idow: 你其實只要說一句  「你的資料沒屁用,等我統計給你看」
推 adolfal007: 玩家整天泡賭場，不會增加營運收入，所以作弊意義不大
→ w3dB: 可以增加遊戲黏著度呀
推 adolfal007: 設定 相當低機率但期望值仍是正的就夠了，也不需要
→ adolfal007: 作弊搞人，這樣玩家不會多花錢
→ watanabekun: 黏著度是要有，但不是無限提高
→ watanabekun: 不然不會有尤達和武勳系統這種加快玩家鍊等速度的設
→ watanabekun: 計接二連三推出
推 watanabekun: 需要讓玩家黏著的前提是，玩家在遊戲中的活動會不斷
→ watanabekun: 讓遊戲內容價值增加 (發現資訊、討論、推動經濟鏈等)
→ w3dB: 當然我也無憑無據 只是跟機率牽涉上我就不禁想到猴妹事件
→ w3dB: 前陣子忘了看 有人有記到猴妹的出現機率是多少嗎
→ watanabekun: 當初沒公開啊
推 adolfal007: 猴妹那有現實的錢賺啊，賭場不是
→ w3dB: 想知道70萬課長是前幾趴的衰人
→ adolfal007: 然後就有石油王測到猴妹機率比其他上升角低
→ watanabekun: 猴妹事件的問題點在於標示誤導，猴妹機率比貝熊低是
→ watanabekun: 設定，但廣告的時候沒有提及，只說都有up
→ adolfal007: 雖然我覺得這遊戲不太需要石油王，超得跟天花板機制
→ adolfal007: 其實蠻強的，超得就算只課一次GBF那麼多人玩也很可觀
→ adolfal007: 天花板反而會引中課去衝到頂
推 idow: 他就覺得不夠 現在才在搞限定制度阿 雖然事後有說還是會下放
→ watanabekun: 用計算機算了一下，70萬日幣(2330抽)抽不到一隻出現
→ watanabekun: 率0.029% (現在的非pick up SSR角出現率)是50.8%
推 Romulus: 啊人家都說要統計了就等結果啊
→ Romulus: 安潔拉當時有人有用log統計是3倍up左右
→ Romulus: 所以70萬僅僅只是12％的衰而已
→ watanabekun: 喔喔，是哪個值的三倍？
→ Romulus: 6%除以當時SSR總數
→ metallolly: 數學真是無所不在
推 watanabekun: 貝熊那次好像是5倍up..(不太確定)
→ watanabekun: 搞不好猴妹是基礎機率別人一半，然後放大倍率一樣
→ watanabekun: >>metallolly  因為手機/網頁遊戲能呈現的演出模式有
推 w3dB: 找了下沒看到6%時猴妹武的出現機率 感謝樓上諸位的計算
→ watanabekun: 限，為了增加沉浸性所以數值設計都非常精密，光用數
→ watanabekun: 字就能讓人產生強烈的持續遊戲動機
→ watanabekun: 中國的手機遊戲開發商更是精通這塊到不行
→ Golu: 實做上來說，不會隨時產生新的隨機表單，但是透過數值和選取
→ Golu: 的機制，可以讓玩家感受不出這組合是早就決定好的，而且還能
→ Golu: 滿足設定好的獲獎期望值，這就是數值企劃的重要性
→ taldehyde: 感覺戰貨箱也是早就決定好每個物品的順序...
推 franktpmvu: 那種跟其他人無關的抽獎 預先決定順序跟當下決定
→ franktpmvu: 其實也沒有甚麼區別
→ Golu: 有喔，連線需求頻率和效能上的差異
推 watanabekun: 玩家端可觀測的部份是真的沒差別啦 XD...
推 watanabekun: 在生成箱子時就決定順序，和每次抽時決定結果，只要
推 watanabekun: 隨機生成的原理一樣那機率就不會變
推 dukemon: 第一段那個是到達加倍上限(10次)是0回
推 Romulus: 實作為什麼不會每次產生新的亂數表？
→ Romulus: 這種東西不就每次request就new Random嗎
→ Romulus: 要不然就一個thread/global的random object
→ Romulus: 如果有業界人士願意說明server一般不是這樣做的話我非常
→ Romulus: 想聽
推 Golu: 舉例來說，同一時間內1萬次的request和10萬次的request，如
→ Golu: 果每次server能處理的request能處理2萬次的new random，前者
→ Golu: 當然沒問題，但是後者同一時間內卻還有8萬次的request正在等
→ Golu: 待，玩家感受到的延遲就會非常明顯，甚至可能因為玩家的重新
→ Golu: 發送request後累積更多的request
→ Golu: 折衷的做法包含在製作一個會在特定時間或者request數量之內
→ Golu: 存在的共用list，讓request直接讀取其內容，這樣server儲存
→ Golu: 資料和處理request的頻率會因此降低，至於機率或者期望值的
→ Golu: 問題，只要在建立list的時候有滿足設定條件(如完全自然機率)
→ Golu: 也能達到一樣的效果
推 eyes8168: 可惡身為一個工程師我居然看不懂樓上的內容Orz
推 eyes8168: 所以是先準備好一串的隨機結果Array,然後當Request發生
→ eyes8168: 從Array[0]開始依序抓取結果,在Array快用完的時候再產生
→ eyes8168: 新的Array這樣嗎XD
→ Golu: 用array的概念來說確實是這樣的概念，只是如果牽涉到需要儲
→ Golu: 存在database的內容(如抽抽記錄、戰鬥獎勵記錄)，就得額外
→ Golu: 考慮一些非常態操作的因素
推 tyai: 身為理組的看不懂+1
推 eyes8168: 還好沒理解錯,剛看還有點茫然的感覺XD
→ hajimels: Golu的言論我想八九不離十，GBF的處理都在server端，而
→ hajimels: 非client，new random一個request處理一個server會GG
推 eyes8168: 副官:RAM已枯竭
推 kaori9993: 簡單來說就是建立一個table，server開thr
→ kaori9993: ead持續預先寫入new random
→ kaori9993: client端則對這個table送request，server
→ kaori9993: 回送時順便把送出的該筆delete
推 Romulus: 那不就共用一個Random變數 理論上是一樣的事情啊
→ Romulus: Random怎麼可能用array的概念作
推 Romulus: 我沒聽說Random物件有效率問題的 有人可以提供文件嗎
→ Romulus: 這又不是在做資料庫，以Java為例的話
→ Romulus: 呼叫一次Random.nextInt()是要多少CPU time嗎
推 jackervator: 由於新任板主討厭JAVA故不參與討論(幹
推 jackervator: 不過我也對random request 這件事感到好奇
→ jackervator: randomness 共用這問題明顯蠻大的吧....還是我理解錯
推 franktpmvu: 共用光等待就等到爆了