实时返回玩家表现监测游戏的机会
远程操作员需要监控他们提供的游戏的表现。
参见远程测试策略:第5节。
尽管游戏必须在发行前(以及可能影响公平性的更新后)进行测试,但设计、执行或操作问题仍有可能在测试或部署期间被忽视。这可能会影响游戏的RTP,并导致产品支付过高或过低。
如果你提供了适用的产品,你就必须有适当的流程来衡量游戏的持续性能。这些通常是定期报告或在存储的事务数据上运行的自动后端流程。
你应该在游戏超出可接受性能范围时发出警告。你们应该保留适当的记录,作为这些过程的证据,以及任何更详细的调查,这些调查是由于警报或升级的客户投诉而进行的,需要进行此类调查。
在年度游戏测试审核范围内的业务(那些制作和更新游戏并获得经批准的测试机构的外部测试的业务)将包括审查RTP监控过程的充分性。
虽然本指南的重点是具有统计定义的RTP的RNG驱动产品,如老虎机游戏,但也有一些性能监控适用于其他产品,如一些示例所示。这通常包括宾果、点对点扑克、21点和虚拟体育等产品,在这些产品中,玩家的技能或选择会影响回报。对于这些产品,监控的重点将放在可能事件结果的频率和分布上,以确保它们是可接受的随机。
这种监控的总体目标是确保游戏按照设计和宣传的方式公平运行。
如何计算玩家回报(RTP)
通过将游戏中产生的获胜和周转数据相除,您可以确定实际的RTP。
例如,如果一款RTP率为91.68%的游戏玩了一个月后,累计营业额为120万英镑,获胜金额为108.5万英镑,那么RTP的计算方法如下:
1,085,000 / 1,200,000 = .9042
因此本游戏的实际RTP为90.42%,低于设计RTP。
然而,重要的是,游戏的波动性也必须考虑在内,因为它会告诉允许容差高于或低于理论RTP。当只测量有限数量的游戏时,容忍度会更大,但随着游戏量的增加,容忍度会降低。
经过大量的游戏后,实际RTP应该非常接近或等于理论RTP。继续上面的例子,如果游戏的波动率(标准偏差)为5.6,那么可接受的上限和下限将如下所示:
游戏次数 | 范围+ / - | 平均值的百分比__ |
---|---|---|
50000年 | +/- | 4.90862 |
100,000 | +/- | 3.47092 |
200000年 | +/- | 2.45431 |
300000年 | +/- | 2.00393 |
400000年 | +/- | 1.73546 |
500000年 | +/- | 1.55224 |
600000年 | +/- | 1.41700 |
700000年 | +/- | 1.31188 |
800000年 | +/- | 1.22715 |
900000年 | +/- | 1.15697 |
1000000年 | +/- | 1.09760 |
†与平均值的偏差以95%的置信区间计算(在新选项卡中打开)。这意味着一款没有缺陷的游戏可能仍然会在20次测试中落在1次之外。可以选择较高的置信区间以减少误报警的机会,但应谨慎行事,以免产生太宽的容差。置信区间不应超过99%,这意味着一款没有缺陷的游戏可能会超出大约100次测试中的1次范围。一次测量失败并不能确定游戏/RNG是否存在缺陷,但连续失败或特定测量频率上的一系列失败却可以确定。
因此,如果40万场比赛累积了营业额和获胜数据,那么允许的公差将是高于或低于91.68的1.75。游戏可以在89.93%到93.43%之间返回,仍然被认为是预期的表现。
游戏设计师将计算出准确的理论RTP以及游戏的波动性(这些数据也将作为外部测试的一部分进行审查)。这些数据是用来衡量实际表现的。
在测量实际RTP之前应该达到多少游戏量?
仅通过少量游戏体验来衡量游戏是毫无意义的,因为偏差太大而无法产生有意义的结果。另一方面,等待数以百万计的游戏体验可能意味着在不合理的长时间内无法检测到错误的游戏。游戏的波动性将详细说明可接受的容忍范围,无论累积的游戏数量如何,都必须考虑到这一点。通过这种方式,测量可以在任何时间执行,波动性衍生的容差将决定游戏是否按照预期执行。
因为一款远程游戏将面向成千上万的玩家发布,所以这款游戏将迅速积累成千上万的游戏体验,特别是如果这款游戏是由多个远程赌场提供的热门游戏。在通过B2B供应商提供游戏的情况下,他们可能会掌握所有向其客户提供游戏的b2c的总胜利和营业额数据。
这将取决于被授权方(通常基于游戏设计师的指示)来确定测量方法和频率。一种方法是基于前30天的游戏进行每日测量,这将确保随着时间的推移而测量新的数据集。测量几个月的活动可以隐藏新更新引入的错误。可以同时测量更大的日期范围(例如,测量滚动的90天活动),以便考虑更大的游戏量(意味着数据将具有更精细的容忍度)。
另一种方法可以代替以天数为基础的测量,即在达到X次井眼后进行测量。这可以解释流行和不流行游戏之间的游戏量问题。
理论RTP是中线,上面和下面的允许容差分别由绿线和红线表示,并由游戏的波动性决定。随着更多游戏玩法的实现,实际RTP应该与理论RTP非常接近。
其他关于实时回归玩家表现监测的考虑因素
由于远程赌博将在数据库中记录事务,并且通常是在非常细粒度的级别上,因此它很容易促进更复杂的测量。记录游戏交易和性能测量的粒度应该与游戏的设计和复杂性相称,它应该能够实现准确的性能监控。下面是更详细的示例,这些示例可以作为正常监测过程的一部分,在特别的基础上执行,或者在调查明显的差异时执行。
测量每个桩位
一个允许玩家每次旋转改变赌注的游戏将导致营业额和赢得混合赌注的数字,并从所有下注级别中获胜。这意味着在最高下注水平下进行的活动可能会淹没在最低下注水平下进行的活动。在大量的游戏后,这种影响会减少,但是独立衡量每个主要下注级别的游戏可以给出更准确的结果。它还可以检测是否存在仅存在于特定赌注级别的问题(例如,设计的乘数可能无法正常工作)。在可能的情况下,应该考虑在利害关系层面上监控游戏,特别是在调查可能的游戏错误时。
每通道测量
远程游戏通常会在不同的平台或渠道(如手机、flash和下载)上单独发行。根据游戏的设计和架构,这可能意味着游戏错误可能只存在于一个渠道中,如果所有渠道的活动都被聚合到一个测量中,就很难检测到。我们已经看到了一些例子,即尽管一款游戏的手机版本是基于之前的flash版本,但在适应过程中所犯的错误却导致了只存在于手机版本中的错误。如果通道之间的差异可能影响公平性,则应在聚合级别和每个通道级别进行测量。
将基础游戏活动从奖励功能或累积奖金中分离出来
如果游戏设计带有复杂的奖励功能,那么就应该包含在基础游戏和功能游戏关卡中监控游戏的能力。当功能对整个游戏的RTP有很大影响时,这一点尤其重要,当游戏在功能中执行技能组件时,这一点当然也很重要(因为技能RTP组件将根据玩家的行动而发生很大变化)。例如,有些游戏将提供50/50(双倍或退出)赌博功能;监控整个游戏RTP(游戏邦注:包括赌博)并不一定能够确保赌博是真实且公平的50/50模式。同样,对于累进式累积奖金的游戏,基础游戏应该独立于累进式组件进行测量。
虚拟体育产品
与技能游戏类似,虚拟运动的回报主要取决于玩家的选择,所以不会有单一的理论RTP。取而代之的是,操作员可以根据设计的概率来监控命中率和每个可能事件结果的分布。例如,如果在一场比赛中有七匹虚拟马,确保每匹马根据其设计的概率赢得预期数量的比赛,这反映在提供的赔率(超过一轮)中。类似的方法可能适用于轮盘赌和二十一点。
那么现场发牌人赌场游戏呢?
RTP监控的主要焦点是RNG驱动的软件产品。现场庄家使用物理设备(如轮盘赌轮和牌组)来确定结果,并且围绕此类规定还有一系列其他完整性措施。例如,将对这些设备的供应(来自赌场标准制造商)、安装和持续操作进行控制。公平洗牌,轮盘赌轮盘的持续完整性测量和处理过程都对公平性产生影响,并将成为日常供应的一部分。
在一段时间的游戏后测量某些输出仍然是有价值的,例如在一段较长时间内轮盘赌上的结果分布,以查看它们是否具有可接受的随机性。这些信息将保存在数据库中,可以很容易地测量。
计算累进头奖
与累进式累积奖金系统相连的游戏需要在基础游戏关卡(即没有累积奖金组件的游戏)进行衡量。头奖达到非常高的价值,他们的表现应该单独监测。考虑到头奖往往是不频繁和大的,它们将具有高波动性评级,因此测量它们的RTP可能是不可行的。可以进行其他检查,例如头奖的频率和分布以及平均头奖水平是否符合预期。头奖系统的设计者最适合定义监测方法。
关键术语与实时返回玩家的表现监测游戏的机会
理论RTP
这是游戏设计的玩家回报百分比,它也是游戏的广告RTP,显示在玩家面对规则中,就像RTS 3C一样。
实际RTP
使用现场(操作)游戏生成的胜利和营业额数据计算。它显示了游戏在过去一段时间内实际实现的RTP,包括选定的胜利和营业额。
波动
最常见的是,游戏的标准偏差被用来表示游戏的波动性。高度不稳定的游戏将具有更大的容忍度,并且可能包含属于“非常大但罕见”类别的奖品。低波动性游戏的可预测性更强,主要由“小而常”类别的奖励组成。标准偏差是一个数学计算数字(游戏邦注:游戏方差的平方根,其中方差取决于游戏周期和奖励频率)。
营业额
在游戏中所做的所有赌注的总和,这将包括在游戏中获得的再投资奖金。
赢得
在游戏过程中获得的所有奖品的总和。一场比赛的结果是失误减去胜利。
最后更新:2025年1月29日
显示对该内容的更新
仅更改格式。