要数据其实可以到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 共用这问题明显蛮大的吧....还是我理解错

共用光等待就等到爆了