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

看板GO_FATE作者 (老詩)時間8年前 (2016/05/04 13:05), 8年前編輯推噓27(27推 0噓 70→)
留言97則, 17人參與, 最新討論串2/2 (看更多)
要數據其實可以到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
→
05/04 13:25, , 1F
這種是給程式跑的 還是實際玩碧藍得出的結果?
05/04 13:25, 1F
→
05/04 13:26, , 2F
wiki留言 不知統計方法
05/04 13:26, 2F
→
05/04 13:28, , 3F
而且我說的1000回 不是指進双倍的總合數 而是100 300 400
05/04 13:28, 3F
→
05/04 13:28, , 4F
500 各勝率要分開算 重點是 超過100的局 電腦有無作弊
05/04 13:28, 4F
→
05/04 13:32, , 5F
如果電腦在某回合作弊了 那他就必須要在某回合補回機率
05/04 13:32, 5F
→
05/04 13:32, , 6F
長期來看 我覺得你統計那些沒什麼意義啦
05/04 13:32, 6F
→
05/04 13:33, , 7F
會補回 但想想500能贏到上限的時間快 還是100 一樣機率
05/04 13:33, 7F
→
05/04 13:34, , 8F
證明CY為了要讓玩家更久的耗在賭場 更動不符合常數的機率
05/04 13:34, 8F
→
05/04 13:37, , 9F
還有比起撲克 我討厭賓果 所以借統計機會 順便把賭場畢業
05/04 13:37, 9F
推
05/04 13:39, , 10F
你其實只要說一句 「你的資料沒屁用,等我統計給你看」
05/04 13:39, 10F
推
05/04 13:45, , 11F
玩家整天泡賭場，不會增加營運收入，所以作弊意義不大
05/04 13:45, 11F
→
05/04 13:47, , 12F
可以增加遊戲黏著度呀
05/04 13:47, 12F
推
05/04 13:56, , 13F
設定 相當低機率但期望值仍是正的就夠了，也不需要
05/04 13:56, 13F
→
05/04 13:57, , 14F
作弊搞人，這樣玩家不會多花錢
05/04 13:57, 14F
→
05/04 13:57, , 15F
黏著度是要有，但不是無限提高
05/04 13:57, 15F
→
05/04 13:58, , 16F
不然不會有尤達和武勳系統這種加快玩家鍊等速度的設
05/04 13:58, 16F
→
05/04 13:58, , 17F
計接二連三推出
05/04 13:58, 17F
推
05/04 13:58, , 18F
需要讓玩家黏著的前提是，玩家在遊戲中的活動會不斷
05/04 13:58, 18F
→
05/04 13:59, , 19F
讓遊戲內容價值增加 (發現資訊、討論、推動經濟鏈等)
05/04 13:59, 19F
→
05/04 14:01, , 20F
當然我也無憑無據 只是跟機率牽涉上我就不禁想到猴妹事件
05/04 14:01, 20F
→
05/04 14:02, , 21F
前陣子忘了看 有人有記到猴妹的出現機率是多少嗎
05/04 14:02, 21F
→
05/04 14:04, , 22F
當初沒公開啊
05/04 14:04, 22F
推
05/04 14:04, , 23F
猴妹那有現實的錢賺啊，賭場不是
05/04 14:04, 23F
→
05/04 14:04, , 24F
想知道70萬課長是前幾趴的衰人
05/04 14:04, 24F
→
05/04 14:05, , 25F
然後就有石油王測到猴妹機率比其他上升角低
05/04 14:05, 25F
→
05/04 14:05, , 26F
猴妹事件的問題點在於標示誤導，猴妹機率比貝熊低是
05/04 14:05, 26F
→
05/04 14:06, , 27F
設定，但廣告的時候沒有提及，只說都有up
05/04 14:06, 27F
→
05/04 14:06, , 28F
雖然我覺得這遊戲不太需要石油王，超得跟天花板機制
05/04 14:06, 28F
→
05/04 14:06, , 29F
其實蠻強的，超得就算只課一次GBF那麼多人玩也很可觀
05/04 14:06, 29F
→
05/04 14:07, , 30F
天花板反而會引中課去衝到頂
05/04 14:07, 30F
推
05/04 14:07, , 31F
他就覺得不夠 現在才在搞限定制度阿 雖然事後有說還是會下放
05/04 14:07, 31F
→
05/04 14:08, , 32F
用計算機算了一下，70萬日幣(2330抽)抽不到一隻出現
05/04 14:08, 32F
→
05/04 14:08, , 33F
率0.029% (現在的非pick up SSR角出現率)是50.8%
05/04 14:08, 33F
推
05/04 14:10, , 34F
啊人家都說要統計了就等結果啊
05/04 14:10, 34F
→
05/04 14:11, , 35F
安潔拉當時有人有用log統計是3倍up左右
05/04 14:11, 35F
→
05/04 14:12, , 36F
所以70萬僅僅只是12％的衰而已
05/04 14:12, 36F
→
05/04 14:12, , 37F
喔喔，是哪個值的三倍？
05/04 14:12, 37F
→
05/04 14:13, , 38F
6%除以當時SSR總數
05/04 14:13, 38F
→
05/04 14:14, , 39F
數學真是無所不在
05/04 14:14, 39F
推
05/04 14:15, , 40F
貝熊那次好像是5倍up..(不太確定)
05/04 14:15, 40F
→
05/04 14:15, , 41F
搞不好猴妹是基礎機率別人一半，然後放大倍率一樣
05/04 14:15, 41F
→
05/04 14:15, , 42F
>>metallolly 因為手機/網頁遊戲能呈現的演出模式有
05/04 14:15, 42F
推
05/04 14:16, , 43F
找了下沒看到6%時猴妹武的出現機率 感謝樓上諸位的計算
05/04 14:16, 43F
→
05/04 14:16, , 44F
限，為了增加沉浸性所以數值設計都非常精密，光用數
05/04 14:16, 44F
→
05/04 14:16, , 45F
字就能讓人產生強烈的持續遊戲動機
05/04 14:16, 45F
→
05/04 14:17, , 46F
中國的手機遊戲開發商更是精通這塊到不行
05/04 14:17, 46F
→
05/04 15:43, , 47F
實做上來說，不會隨時產生新的隨機表單，但是透過數值和選取
05/04 15:43, 47F
→
05/04 15:44, , 48F
的機制，可以讓玩家感受不出這組合是早就決定好的，而且還能
05/04 15:44, 48F
→
05/04 15:45, , 49F
滿足設定好的獲獎期望值，這就是數值企劃的重要性
05/04 15:45, 49F
→
05/04 16:18, , 50F
感覺戰貨箱也是早就決定好每個物品的順序...
05/04 16:18, 50F
推
05/04 16:23, , 51F
那種跟其他人無關的抽獎 預先決定順序跟當下決定
05/04 16:23, 51F
→
05/04 16:24, , 52F
其實也沒有甚麼區別
05/04 16:24, 52F
→
05/04 16:32, , 53F
有喔，連線需求頻率和效能上的差異
05/04 16:32, 53F
推
05/04 16:37, , 54F
玩家端可觀測的部份是真的沒差別啦 XD...
05/04 16:37, 54F
推
05/04 16:38, , 55F
在生成箱子時就決定順序，和每次抽時決定結果，只要
05/04 16:38, 55F
推
05/04 16:38, , 56F
隨機生成的原理一樣那機率就不會變
05/04 16:38, 56F
推
05/04 17:11, , 57F
第一段那個是到達加倍上限(10次)是0回
05/04 17:11, 57F
推
05/05 08:32, , 58F
實作為什麼不會每次產生新的亂數表？
05/05 08:32, 58F
→
05/05 08:32, , 59F
這種東西不就每次request就new Random嗎
05/05 08:32, 59F
→
05/05 08:33, , 60F
要不然就一個thread/global的random object
05/05 08:33, 60F
→
05/05 08:34, , 61F
如果有業界人士願意說明server一般不是這樣做的話我非常
05/05 08:34, 61F
→
05/05 08:34, , 62F
想聽
05/05 08:34, 62F
推
05/05 10:20, , 63F
舉例來說，同一時間內1萬次的request和10萬次的request，如
05/05 10:20, 63F
→
05/05 10:20, , 64F
果每次server能處理的request能處理2萬次的new random，前者
05/05 10:20, 64F
→
05/05 10:20, , 65F
當然沒問題，但是後者同一時間內卻還有8萬次的request正在等
05/05 10:20, 65F
→
05/05 10:20, , 66F
待，玩家感受到的延遲就會非常明顯，甚至可能因為玩家的重新
05/05 10:20, 66F
→
05/05 10:20, , 67F
發送request後累積更多的request
05/05 10:20, 67F
→
05/05 10:26, , 68F
折衷的做法包含在製作一個會在特定時間或者request數量之內
05/05 10:26, 68F
→
05/05 10:26, , 69F
存在的共用list，讓request直接讀取其內容，這樣server儲存
05/05 10:26, 69F
→
05/05 10:26, , 70F
資料和處理request的頻率會因此降低，至於機率或者期望值的
05/05 10:26, 70F
→
05/05 10:26, , 71F
問題，只要在建立list的時候有滿足設定條件(如完全自然機率)
05/05 10:26, 71F
→
05/05 10:26, , 72F
也能達到一樣的效果
05/05 10:26, 72F
推
05/05 10:56, , 73F
可惡身為一個工程師我居然看不懂樓上的內容Orz
05/05 10:56, 73F
推
05/05 11:03, , 74F
所以是先準備好一串的隨機結果Array,然後當Request發生
05/05 11:03, 74F
→
05/05 11:04, , 75F
從Array[0]開始依序抓取結果,在Array快用完的時候再產生
05/05 11:04, 75F
→
05/05 11:04, , 76F
新的Array這樣嗎XD
05/05 11:04, 76F
→
05/05 11:17, , 77F
用array的概念來說確實是這樣的概念，只是如果牽涉到需要儲
05/05 11:17, 77F
→
05/05 11:17, , 78F
存在database的內容(如抽抽記錄、戰鬥獎勵記錄)，就得額外
05/05 11:17, 78F
→
05/05 11:18, , 79F
考慮一些非常態操作的因素
05/05 11:18, 79F
推
05/05 12:00, , 80F
身為理組的看不懂+1
05/05 12:00, 80F
推
05/05 12:26, , 81F
還好沒理解錯,剛看還有點茫然的感覺XD
05/05 12:26, 81F
→
05/05 18:32, , 82F
Golu的言論我想八九不離十，GBF的處理都在server端，而
05/05 18:32, 82F
→
05/05 18:33, , 83F
非client，new random一個request處理一個server會GG
05/05 18:33, 83F
推
05/05 19:45, , 84F
副官:RAM已枯竭
05/05 19:45, 84F
推
05/05 20:10, , 85F
簡單來說就是建立一個table，server開thr
05/05 20:10, 85F
→
05/05 20:10, , 86F
ead持續預先寫入new random
05/05 20:10, 86F
→
05/05 20:12, , 87F
client端則對這個table送request，server
05/05 20:12, 87F
→
05/05 20:12, , 88F
回送時順便把送出的該筆delete
05/05 20:12, 88F
推
05/05 22:26, , 89F
那不就共用一個Random變數 理論上是一樣的事情啊
05/05 22:26, 89F
→
05/05 22:27, , 90F
Random怎麼可能用array的概念作
05/05 22:27, 90F
推
05/05 22:29, , 91F
我沒聽說Random物件有效率問題的 有人可以提供文件嗎
05/05 22:29, 91F
→
05/05 22:30, , 92F
這又不是在做資料庫，以Java為例的話
05/05 22:30, 92F
→
05/05 22:31, , 93F
呼叫一次Random.nextInt()是要多少CPU time嗎
05/05 22:31, 93F
推
05/06 01:34, , 94F
由於新任板主討厭JAVA故不參與討論(幹
05/06 01:34, 94F
推
05/06 01:38, , 95F
不過我也對random request 這件事感到好奇
05/06 01:38, 95F
→
05/06 01:39, , 96F
randomness 共用這問題明顯蠻大的吧....還是我理解錯
05/06 01:39, 96F
推
05/06 21:29, , 97F
共用光等待就等到爆了
05/06 21:29, 97F
‣ 更多 asLay 的文章
文章代碼(AID): #1NAOCcVa (GO_FATE)
‣ 更多 asLay 的文章
文章代碼(AID): #1NAOCcVa (GO_FATE)