Submissão para certificação de jogo de cassino: guia de preparo

Uma submissão para certificação de jogo de cassino deve vincular um candidato exato de release ao código, matemática, regras, arte, configuração, ambiente e evidências de teste que o descrevem. Uma pasta com documentos individualmente corretos não está pronta quando o laboratório não consegue provar que todos pertencem à mesma versão do jogo e ao mercado-alvo.

Para o responsável de produto do estúdio, líder de compliance, líder de testes, equipe de onboarding do operador ou comprador de procurement, a decisão é se o pacote está completo e coerente antes do início dos testes independentes. O artefato útil é um índice controlado de submissão e uma matriz de escopo que identificam cada item, versão, responsável, dependência e requisito aplicável do mercado.

Escolha o mercado e a rota de testes antes de fechar o pacote

O preparo da submissão começa com a jurisdição-alvo, o licenciado responsável e a rota de testes autorizada. Essas escolhas determinam quais normas se aplicam, quem pode testar, quais relatórios precisam ser apresentados e se uma avaliação existente pode ser reutilizada.

O procedimento de testes da UK Gambling Commission exige que licenciados e o laboratório aprovado escolhido concordem com um escopo suficiente para as normas da Comissão. A Comissão mantém uma lista de laboratórios aprovados, mas ela se aplica ao próprio marco de testes. Não é um diretório universal para todos os mercados.

Ontário oferece outro exemplo. A política de certificação de tecnologia da Alcohol and Gaming Commission of Ontario atribui obrigações a operadores e fornecedores relacionados a jogos que executam sistemas críticos, e exige que jogos aplicáveis, geradores de números aleatórios e componentes de apostas sejam certificados por um laboratório independente registrado antes da implantação. Testes anteriores só podem ser considerados quando o laboratório determina que continuam relevantes para as normas de Ontário.

Escreva uma declaração de escopo de uma página antes de empacotar arquivos. Identifique versões do jogo e da tabela de pagamentos, canais, mercados-alvo, configuração do operador, dependências de plataforma e RNG, tipo de submissão, normas aplicáveis, contato do laboratório, responsável pelo protocolo e limite pretendido do release. Marque cada desconhecido como decisão aberta, em vez de escondê-lo em um checklist genérico.

Crie um único índice controlado da submissão

O índice da submissão deve ser o inventário autoritativo de tudo o que o laboratório recebe e de cada item ainda pendente. Ele conecta o escopo de negócio às evidências técnicas e impede que uma conversa por e-mail ou pasta de upload se torne o registro acidental.

Dê a cada item um identificador, título, revisão, responsável, localização de origem, nome do arquivo enviado, resumo criptográfico quando apropriado, data de entrega, tratamento de confidencialidade e relação com o candidato de release. Inclua código-fonte, binários compilados, instruções de build, assinaturas, documentos matemáticos, regras, arte, configuração, ambientes suportados, utilitários de teste, relatórios anteriores, registros de mudança e exceções conhecidas somente quando pertencerem ao escopo acordado.

Os Requisitos Compostos de Submissão, versão 2.0 da GLI descrevem documentação e materiais que podem ser solicitados para avaliações e alertam expressamente que requisitos específicos de uma jurisdição podem acrescentar itens. Trate o documento como referência prática para a submissão, não como promessa de que um pacote satisfaz todas as autoridades.

Defina um responsável único pela submissão e um responsável técnico para cada família de evidências. O índice também deve informar quem pode responder às perguntas do laboratório, aprovar material corrigido e decidir se uma consulta revela mudança do produto ou apenas esclarecimento da evidência.

Vincule código, binários e identidade da build

A identidade da build deve permitir rastrear o executável enviado até o código revisado e o candidato pretendido para release. Um nome de arquivo ou versão semântica, isoladamente, não prova essa relação.

Registre a revisão do repositório, estado do lockfile de dependências, ambiente de build, versões do compilador ou ferramentas, comando de build, entradas geradas, resumos de artefatos e estado de assinatura. Preserve os binários enviados como artefatos imutáveis. Se o laboratório fizer uma compilação independente ou testemunhada, registre o método e explique como o objeto resultante é comparado ao candidato entregue.

Os requisitos da GLI pedem código completo, arquivos compilados, documentação arquitetural, assinaturas de software e ferramentas necessárias para o teste. Também dizem que o código deve estar completo e ser compilável, e que o objeto compilado precisa ser idêntico ou verificavelmente equivalente do ponto de vista funcional à mídia submetida por um método acordado.

O guia de segurança de fornecedores de jogos de cassino explica as evidências adjacentes de SBOM e proveniência. O preparo para certificação usa esses controles para responder uma pergunta mais estreita: quais componentes e qual build exata o laboratório avaliou? Um SBOM apoia essa resposta, mas não substitui revisão de código, teste do jogo ou o processo de aprovação do mercado-alvo.

Faça matemática, regras e arte descreverem o mesmo jogo

A matemática do jogo, as regras para o jogador e a arte devem usar um vocabulário controlado e apontar para a mesma tabela de pagamentos e configuração de recursos. O laboratório não deveria precisar inferir se o nome de um símbolo, tabela de prêmios ou condição de bônus em um arquivo corresponde a uma etiqueta diferente no cliente.

Envie o modelo matemático aplicável, cálculos de retorno teórico, mapeamento da entrada aleatória, tabelas de prêmios, lógica de recursos, instruções de emulação e métodos para resultados raros junto com as regras visíveis e toda arte que contenha regras ou informações de pagamentos. Cruze cada regra material com sua definição matemática, comportamento em runtime e teste esperado.

Os requisitos da GLI para submissões de jogos pedem arte legível, descrições completas, combinações vencedoras, pagamentos, esquemas de aposta, detalhes de bônus e instruções de emulação conforme o tipo de jogo. O mesmo documento observa que traduções independentes da arte podem ser exigidas. Esses são insumos para uma submissão à GLI, não substitutos das regras de conteúdo e idioma do mercado-alvo.

Use o guia do modelo matemático para estruturar a PAR e as evidências de teste, e o guia da especificação de regras para manter as informações ao jogador alinhadas ao código e à matemática. O índice deve referenciar essas fontes controladas em vez de copiar valores para um resumo separado que pode divergir.

Reproduza a configuração operacional pretendida

A configuração de teste deve reproduzir cada escolha de produção que possa alterar o comportamento ou a equidade do jogo. Testar um pacote flexível sem a tabela de pagamentos, RNG, plataforma, canal e recursos reais do operador pode deixar o produto avaliado diferente daquele destinado aos jogadores.

A GLI-19, versão 3.0 afirma que a configuração de produção deve ser informada ao laboratório independente para que ele crie um ambiente de teste funcionalmente equivalente. O procedimento britânico também espera testes com o software e o ambiente destinados à operação, incluindo testes de integração quando as diferenças puderem afetar a equidade.

Crie um manifesto de configuração com IDs do jogo e da tabela de pagamentos, versões do RNG e RGS, canais e dispositivos suportados, perfil de moeda e denominação, chaves de recursos, pacote de localização, endpoints de serviços, fonte de tempo, controles de segurança e contas de teste necessárias. Substitua segredos por um mecanismo seguro acordado com o laboratório. Nunca inclua credenciais no índice comum.

Documente diferenças deliberadas entre teste e produção com motivo e consequência. Um stub, modo acelerado ou ferramenta de emulação pode ser necessário, mas o pacote precisa explicar sua relação com a lógica de produção e o que ele não consegue provar.

Separe uma nova submissão de uma modificação

Uma submissão de modificação deve identificar a versão avaliada anteriormente, a mudança exata e as evidências que continuam válidas. Reenviar todos os arquivos históricos sem um limite de mudança torna a revisão mais lenta e pode ocultar quais premissas precisam ser testadas novamente.

Os requisitos da GLI distinguem protótipos iniciais de modificações. Para alterações de software, pedem a versão anterior, uma descrição em linguagem comum com cenários de teste, módulos afetados e código novo, permitindo referenciar documentos inalterados. O procedimento britânico usa outro marco: mudanças que afetam a equidade exigem novos testes externos, enquanto todas as atualizações continuam sujeitas a registros e responsabilidades de controle de mudança.

Não transforme nenhum desses marcos em uma etiqueta universal de mudança maior ou menor. Crie uma matriz de impacto para o mercado e a rota de laboratório reais. Para cada mudança, avalie matemática e equidade, uso do RNG, regras e arte, estado do jogo, apresentação ao jogador, canal, integração da plataforma, segurança, design responsável, localização e referências a relatórios anteriores. Registre quem aceitou a classificação e qual conjunto de regressão se aplica.

Resolva consultas do laboratório sem desvio de versão

As perguntas do laboratório devem atualizar um registro controlado de consultas antes de atualizar qualquer arquivo enviado. Um anexo substituído rapidamente pode criar em silêncio um pacote com duas versões diferentes da mesma evidência.

Registre a pergunta, data, item afetado, responsável, interpretação, resposta, versão revisada, novo resumo e impacto no escopo ou em testes anteriores. Se a resposta mudar o comportamento do produto, deixe de tratá-la como esclarecimento documental. Crie um novo candidato ou limite aprovado de modificação e permita que o laboratório decida quais testes precisam ser repetidos.

Separe perguntas em evidência ausente, evidência ambígua, defeito de produto, problema de ambiente e decisão de escopo. Essa classificação permite corrigir a causa sem apresentar cada consulta como certificação reprovada nem tratar uma mudança real como limpeza administrativa.

Transforme o resultado do laboratório em aceitação do release

O relatório final deve ser reconciliado com o candidato exato, o escopo e as condições não resolvidas antes que um operador aceite o jogo. Um título de relatório, carta de aprovação ou resumo positivo não bastam quando a build ou a configuração diferem do pacote preparado para lançamento.

Confira versões testadas, resumos, normas, jurisdição, autoridade do laboratório, configuração, ambiente, exclusões, observações abertas e referências a relatórios anteriores com o índice. Confirme que o candidato de release é o candidato testado ou percorreu a rota aprovada de mudança. Preserve relatório e índice com a autorização de implantação e as evidências do release.

O pacote não garante certificação, não substitui regulador ou laboratório e não prova que o jogo serve para todos os mercados. Ele oferece ao estúdio e ao comprador um registro inspecionável do que foi enviado, testado, alterado por consultas e se o release pretendido ainda corresponde à avaliação.

Para equipes que encomendam um novo jogo de cassino, o desenvolvimento de jogos da Wizards pode transformar requisitos do mercado-alvo, ativos do jogo e critérios de aceitação em uma build controlada e um pacote pronto para laboratório.

Perguntas frequentes

O que faz parte de uma submissão para certificação de jogo de cassino?

A submissão deve incluir escopo acordado, código e binários exatos, identidade da build, matemática, regras, arte visível, configuração, ambiente, utilitários de teste, mudanças, referências a relatórios anteriores e exceções exigidas pelo mercado e laboratório.

Quem decide o escopo de testes de um jogo de cassino?

A autoridade aplicável, o licenciado responsável e o laboratório autorizado determinam a rota e o escopo necessários. Um checklist do fornecedor organiza evidências, mas não estabelece requisitos universais.

Como um estúdio prova qual build foi testada?

O estúdio deve vincular revisão do repositório, ambiente de build, estado de dependências, binários, assinaturas ou resumos e evidências a um candidato imutável, usando compilação independente ou testemunhada quando o processo acordado exigir.

Um relatório anterior de teste pode ser reutilizado?

Ele pode ser referenciado quando a autoridade e o laboratório aceitarem sua relevância e o produto, as normas e a configuração afetados continuarem aplicáveis. Mudanças devem ser classificadas para o mercado-alvo antes da reutilização.

O que acontece quando uma pergunta do laboratório muda o jogo?

A equipe deve criar uma nova build controlada ou um limite de modificação, atualizar o índice e permitir que o laboratório determine o novo escopo de testes. Não deve substituir um arquivo silenciosamente dentro do pacote original.

Um relatório de laboratório garante aprovação em todos os mercados?

Não. Cada jurisdição define requisitos próprios, pode autorizar laboratórios diferentes e exigir submissões, testes ou controles adicionais. O relatório vale somente para seu escopo, normas, configuração e identidade de release declarados.