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