Da matemática do slot à paridade no cliente

Um jogo de slot tem duas descrições do mesmo evento. O modelo matemático diz que a configuração sete do conjunto de rolos três paga 4,20 sobre uma aposta de duas moedas, e o cliente mostra ao jogador cinco símbolos, dois deles wild, um destaque de linha, um banner de ganho e um novo saldo. Entre essas duas descrições está a única coisa que o jogador realmente consegue observar. Quando um estúdio entrega arte, matemática e engenharia em uma só encomenda, é nessa lacuna que vivem os defeitos caros: não em nenhuma das metades, mas na costura.

A decisão sobre a qual este artigo trata pertence ao comprador. Antes de um build ser aceito, alguém precisa decidir quais evidências provam que o cliente apresenta os resultados que o modelo define, quais fixtures essas evidências usam e qual mudança faz com que sejam executadas de novo. Os reguladores enunciam o dever em termos gerais. Os padrões técnicos remotos da UK Gambling Commission, por exemplo, exigem que os jogos sejam implementados de acordo com as regras e os pagamentos descritos ao cliente (RTS 7B), e que o sistema exiba de forma clara e precisa o resultado do jogo e a aposta do cliente por tempo suficiente para que ele o compreenda (RTS 7E). Ambas são afirmações sobre a costura. Nenhuma delas diz qual teste executar.

Paridade é uma questão de aceite, não uma fase de QA

Resolva a questão da paridade enquanto o briefing está sendo escrito, pelo mesmo motivo que as classes de volatilidade são fixadas antes da simulação. O RTS aim 5 é que o sistema de jogos implemente as regras do operador, as regras do jogo e as regras de apostas conforme descritas ao cliente, e a orientação de implementação indica o teste de novos produtos contra as regras publicadas e o monitoramento do desempenho em produção como as medidas razoáveis. Trata-se de uma obrigação de ciclo de vida. Uma demo que parece correta no dia da entrega responde a isso uma única vez.

Consequência prática: peça as evidências de paridade como entregável, com o mesmo status do pacote matemático. O pacote define probabilidades, tabelas de pagamento e identificadores de configuração. As evidências de paridade mostram o cliente reproduzindo esses resultados a partir desses identificadores. Um estúdio que consegue produzir o primeiro e não o segundo documentou um jogo que não demonstrou.

O evento de resultado é o contrato

A forma mais barata de tornar a paridade testável é fazer do resultado uma estrutura de dados com a qual as duas metades concordam, em vez de uma imagem desenhada pelo artista. Um registro de rodada viável carrega:

• o identificador da rodada, a configuração de aposta e a versão da matemática contra a qual ela foi avaliada;
• as posições dos rolos e a matriz de símbolos resultante, por identificador de símbolo e não por nome de sprite;
• cada ganho avaliado, sua linha ou way, os símbolos que o formaram, o multiplicador aplicado e o valor antes e depois do arredondamento;
• os eventos de recurso dentro da rodada, cada um com seu próprio gatilho e estado terminal;
• o prêmio total, o saldo de fechamento e o estado terminal da rodada.

Se o cliente calcula qualquer um desses itens localmente, ele tem uma segunda implementação da paytable, e duas implementações divergem. A forma comum de um defeito em produção é um wild que substitui na avaliação, mas é desenhado no cliente como símbolo comum, ou uma contagem de scatter que inclui um símbolo que o modelo excluía. Nenhum dos dois aparece em uma revisão de screenshots que só verifica se o grande ganho é grande.

Mantenha o registro na mesma linhagem da observabilidade de rodadas de que o lado da plataforma já precisa, para que a reclamação de um jogador sobre uma rodada se resolva em um identificador e não em um vídeo. A análise de rastreamento de rodadas cobre a metade operacional disso; as evidências de paridade são o que torna o rastreamento confiável em primeiro lugar.

Cinco classes de fixture

Uma fixture por estado de tela não prova nada. Um conjunto de entrega que sobreviveu ao contato com uma encomenda real cobre cinco classes, e cada classe é aprovada por uma pessoa nomeada, e não apenas pelo estúdio.

Renderização de símbolos e dimensões. Envie ao cliente uma matriz e confirme que ele desenha os símbolos que o modelo nomeou, nas posições que o modelo usou, incluindo símbolos empilhados e em expansão e qualquer símbolo que o modelo trate como wild. É a classe que pega pipelines de arte renomeando assets durante a otimização.

Exibição da avaliação de ganhos. Para cada fixture, as linhas, ways e valores destacados pelo cliente devem ser iguais à avaliação do modelo, na moeda de exibição, após a regra de arredondamento declarada. Inclua os casos difíceis: múltiplos ganhos coincidentes, ganhos limitados por uma regra de prêmio máximo e uma rodada em que o total exibido é a soma de vários subprêmios.

Transições de recursos e modos. Todo modo de bônus tem suas próprias regras e seu próprio multiplicador de custo, como estabelece o briefing de escopo do modo, e a transição do cliente deve ser conduzida pelo evento de recurso, e não pela conclusão da animação. Um cliente que avança o estado no fim da animação dessincroniza no momento em que um dispositivo perde quadros.

Comportamento de quase-acerto e antecipação. RTS 7C proíbe substituir eventos perdedores por eventos perdedores de quase-acerto, o que limita como a antecipação pode ser produzida. A antecipação autorada por resultado é aceitável onde as regras do mercado e a própria descrição do jogo o permitem; a antecipação implementada pela remarcação de uma rodada perdedora escolhida aleatoriamente é o defeito. Pergunte diretamente qual mecanismo é usado e teste-o com fixtures que não carregam substituição de quase-acerto.

Exibição do resultado e celebração. RTS 7E exige que o resultado e a aposta sejam exibidos de forma clara e precisa por tempo suficiente para serem compreendidos. RTS 14F acrescenta que um retorno menor ou igual ao valor total apostado não pode ser celebrado com áudio ou visuais de ganho. Esses dois requisitos interagem com a escada de faixas de ganho: o cliente precisa de um limite de faixa em “retorno acima do total apostado” que não seja o mesmo da curva de empolgação do artista. O checklist de design responsável de produto cobre o conjunto de controles em torno disso; aqui a questão é apenas se o conjunto de fixtures inclui um retorno exatamente igual ao valor apostado.

Onde a paridade realmente quebra

Quatro falhas respondem pela maioria das que vale a pena testar, e nenhuma delas é exótica.

A paytable existe duas vezes. O modelo tem uma; o cliente tem uma tabela de consulta para a apresentação do ganho. Elas concordam até que uma mudança de configuração, de moeda ou de variante de mercado chegue, e então discordam em uma única direção: o cliente subnotifica.

O arredondamento se move. Os valores do modelo são avaliados em uma precisão que a exibição não usa. Se a regra de arredondamento não estiver escrita no contrato do evento, o cliente arredonda por linha enquanto o modelo arredonda por rodada, e a diferença aparece na reconciliação, não na tela.

Os rolos e a matriz de resultados divergem. Uma tira visual de rolos que não consegue produzir o resultado que o modelo enviou é um defeito de mapeamento, e é o único que um screenshot não pega, porque o cliente desenhará alegremente algo plausível.

O build muda depois do aceite. A última alteração do estúdio em animação, assets de símbolos ou tratamento de formato de dinheiro pode mover um valor exibido sem tocar no modelo. É por isso que o conjunto de fixtures precisa de um gatilho, e não apenas de uma execução.

O que pedir na entrega

• O contrato do evento, por escrito, nomeando cada campo que o cliente consome e qual metade é responsável por ele.
• Um conjunto de fixtures com pelo menos uma rodada por classe de exibição, cada uma com a saída esperada do cliente registrada e armazenada para que possa ser reproduzida contra um build posterior.
• Uma rota de replay determinística, para que uma rodada contestada possa ser renderizada novamente a partir de seu identificador sem a sessão original do jogador.
• Uma reconciliação do RTP simulado contra os totais renderizados pelo cliente, e não apenas contra o modelo, para que o caminho de exibição esteja incluído no número que o laboratório de testes vê.
• Um gatilho de mudança nomeado: quais mudanças de repositório exigem a reexecução do conjunto de fixtures e quem assina o resultado.
• A documentação de modos e volatilidade que a exibição deve acompanhar, para que o aceite compare o cliente com uma versão e não com uma memória.

Para a maioria das encomendas, isso é um pequeno acréscimo ao briefing e uma grande redução de discussão mais tarde, porque transforma “o jogo parece errado” em uma fixture com identificador. Quando um publisher está encomendando o build em vez de herdá-lo, o mesmo conjunto pode ser escrito no escopo antes de a produção começar. Solicitar um orçamento começa pelo briefing do projeto Engine, com escopo, mercados e a lista de evidências definidos por escrito primeiro.

Perguntas frequentes

O que significa paridade entre matemática e cliente em um jogo de slot?

Significa que o cliente apresenta o resultado que o modelo matemático produziu: os mesmos símbolos nas mesmas posições, os mesmos ganhos avaliados e o mesmo prêmio total, na moeda de exibição e após a regra de arredondamento declarada. A paridade é demonstrada com fixtures que carregam um resultado conhecido e uma saída esperada do cliente, e não com uma revisão visual de uma sessão.

Quem deve ser responsável pelas fixtures de paridade, o estúdio ou o operador?

O estúdio que fornece arte, matemática e engenharia deve produzir o conjunto de fixtures, porque é ele que detém as duas metades da costura. O operador ou publisher que compra a encomenda deve aprovar as classes cobertas, receber as fixtures como entregável e assinar a reconciliação. O aceite apenas pelo fornecedor é uma autocertificação da própria integração do fornecedor.

O cliente pode calcular ganhos localmente em vez de renderizar a avaliação do modelo?

Pode, mas então a paytable existe duas vezes e as duas cópias precisam ser mantidas em sincronia por toda configuração, moeda e variante de mercado. Onde o cliente calcula localmente, o conjunto de fixtures se torna obrigatório, e não apenas recomendável, e o gatilho de mudança precisa incluir toda alteração de paytable e de símbolos em qualquer um dos lados.

Quais regras publicadas tornam a exibição do resultado parte do aceite?

Os padrões técnicos remotos da UK Gambling Commission exigem que o sistema exiba o resultado do jogo e a aposta do cliente de forma clara e precisa por um período longo o suficiente para ser compreendido (RTS 7E), que implemente regras e pagamentos conforme descritos ao cliente (RTS 7B) e que não celebre um retorno menor ou igual ao valor total apostado (RTS 14F). Outros mercados estabelecem seus próprios requisitos, portanto as classes de exibição devem ser revisadas conforme o mercado-alvo, e não presumidas.

Com que frequência as fixtures de paridade devem ser reexecutadas?

No mínimo na entrega, em toda mudança de configuração matemática e em toda alteração do cliente que afete renderização de símbolos, apresentação de ganhos, formatação de moeda ou estado de rodada. A regra barata é vincular a execução das fixtures ao mesmo portão de mudança do build, para que um release não possa ser montado a partir de um cliente e um modelo que nunca foram testados juntos.