作者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/cn.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