要數據其實可以到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%

這種是給程式跑的 還是實際玩碧藍得出的結果?

wiki留言 不知統計方法

而且我說的1000回 不是指進双倍的總合數 而是100 300 400500 各勝率要分開算 重點是 超過100的局 電腦有無作弊

如果電腦在某回合作弊了 那他就必須要在某回合補回機率長期來看 我覺得你統計那些沒什麼意義啦

會補回 但想想500能贏到上限的時間快 還是100 一樣機率證明CY為了要讓玩家更久的耗在賭場 更動不符合常數的機率還有比起撲克 我討厭賓果 所以借統計機會 順便把賭場畢業

你其實只要說一句 「你的資料沒屁用,等我統計給你看」

玩家整天泡賭場，不會增加營運收入，所以作弊意義不大

可以增加遊戲黏著度呀

設定 相當低機率但期望值仍是正的就夠了，也不需要作弊搞人，這樣玩家不會多花錢

黏著度是要有，但不是無限提高不然不會有尤達和武勳系統這種加快玩家鍊等速度的設計接二連三推出需要讓玩家黏著的前提是，玩家在遊戲中的活動會不斷讓遊戲內容價值增加 (發現資訊、討論、推動經濟鏈等)

當然我也無憑無據 只是跟機率牽涉上我就不禁想到猴妹事件前陣子忘了看 有人有記到猴妹的出現機率是多少嗎

當初沒公開啊

猴妹那有現實的錢賺啊，賭場不是

想知道70萬課長是前幾趴的衰人

然後就有石油王測到猴妹機率比其他上升角低

猴妹事件的問題點在於標示誤導，猴妹機率比貝熊低是設定，但廣告的時候沒有提及，只說都有up

雖然我覺得這遊戲不太需要石油王，超得跟天花板機制其實蠻強的，超得就算只課一次GBF那麼多人玩也很可觀天花板反而會引中課去衝到頂

他就覺得不夠 現在才在搞限定制度阿 雖然事後有說還是會下放

用計算機算了一下，70萬日幣(2330抽)抽不到一隻出現率0.029% (現在的非pick up SSR角出現率)是50.8%

啊人家都說要統計了就等結果啊安潔拉當時有人有用log統計是3倍up左右所以70萬僅僅只是12％的衰而已

喔喔，是哪個值的三倍？

6%除以當時SSR總數

數學真是無所不在

貝熊那次好像是5倍up..(不太確定)搞不好猴妹是基礎機率別人一半，然後放大倍率一樣>>metallolly 因為手機/網頁遊戲能呈現的演出模式有

找了下沒看到6%時猴妹武的出現機率 感謝樓上諸位的計算

限，為了增加沉浸性所以數值設計都非常精密，光用數字就能讓人產生強烈的持續遊戲動機中國的手機遊戲開發商更是精通這塊到不行

實做上來說，不會隨時產生新的隨機表單，但是透過數值和選取的機制，可以讓玩家感受不出這組合是早就決定好的，而且還能滿足設定好的獲獎期望值，這就是數值企劃的重要性

感覺戰貨箱也是早就決定好每個物品的順序...

那種跟其他人無關的抽獎 預先決定順序跟當下決定其實也沒有甚麼區別

有喔，連線需求頻率和效能上的差異

玩家端可觀測的部份是真的沒差別啦 XD...在生成箱子時就決定順序，和每次抽時決定結果，只要隨機生成的原理一樣那機率就不會變

第一段那個是到達加倍上限(10次)是0回

實作為什麼不會每次產生新的亂數表？這種東西不就每次request就new Random嗎要不然就一個thread/global的random object如果有業界人士願意說明server一般不是這樣做的話我非常想聽

舉例來說，同一時間內1萬次的request和10萬次的request，如果每次server能處理的request能處理2萬次的new random，前者當然沒問題，但是後者同一時間內卻還有8萬次的request正在等待，玩家感受到的延遲就會非常明顯，甚至可能因為玩家的重新發送request後累積更多的request折衷的做法包含在製作一個會在特定時間或者request數量之內存在的共用list，讓request直接讀取其內容，這樣server儲存資料和處理request的頻率會因此降低，至於機率或者期望值的問題，只要在建立list的時候有滿足設定條件(如完全自然機率)也能達到一樣的效果

可惡身為一個工程師我居然看不懂樓上的內容Orz所以是先準備好一串的隨機結果Array,然後當Request發生從Array[0]開始依序抓取結果,在Array快用完的時候再產生新的Array這樣嗎XD

用array的概念來說確實是這樣的概念，只是如果牽涉到需要儲存在database的內容(如抽抽記錄、戰鬥獎勵記錄)，就得額外考慮一些非常態操作的因素

身為理組的看不懂+1

還好沒理解錯,剛看還有點茫然的感覺XD

Golu的言論我想八九不離十，GBF的處理都在server端，而非client，new random一個request處理一個server會GG

副官:RAM已枯竭

簡單來說就是建立一個table，server開thread持續預先寫入new randomclient端則對這個table送request，server回送時順便把送出的該筆delete

那不就共用一個Random變數 理論上是一樣的事情啊Random怎麼可能用array的概念作我沒聽說Random物件有效率問題的 有人可以提供文件嗎這又不是在做資料庫，以Java為例的話呼叫一次Random.nextInt()是要多少CPU time嗎

由於新任板主討厭JAVA故不參與討論(幹不過我也對random request 這件事感到好奇randomness 共用這問題明顯蠻大的吧....還是我理解錯

共用光等待就等到爆了