Antes de um slot por encomenda entrar no catálogo: os testes de integração de um agregador

A decisão de um agregador sobre um slot por encomenda costuma ser descrita como uma decisão de qualidade: este jogo é suficientemente bom para o catálogo? Essa formulação produz a lista de testes errada. A pergunta do catálogo é mais estreita e mais comercial: em que mercados é que este título pode ser ligado, e o que se parte pelo caminho?

Um título pode ser excelente e falhar a segunda pergunta. Pode ser excelente e trazer escrita no código o endereço do servidor de jogo contra o qual foi construído, funcionando para o primeiro operador e para mais nenhum. Pode ser excelente e mostrar um saldo em reais brasileiros com o número errado de casas decimais. Pode ser excelente e não ter strings em italiano, porque a lista de idiomas da plataforma nunca incluiu um código que a build reconhecesse.

Estas falhas não são problemas de arte nem de matemática. São problemas de integração, e são baratos de encontrar antes da exposição e caros de encontrar depois. Este artigo organiza os testes que valem a pena e o que um estúdio deve entregar para que possam ser executados sem uma chamada.

## O contrato de lançamento é a primeira superfície de teste

O URL de lançamento da plataforma é o contrato entre quem abre o jogo e o próprio jogo. A documentação do RGS da Engine define-o como um conjunto de parâmetros de consulta que o frontend lê ao carregar: um identificador de sessão, o host do RGS, o idioma, a moeda, a classe de dispositivo, um indicador de casino social e um indicador de demo.

Dois desses parâmetros concentram quase todo o risco de integração.

O host do RGS é passado no URL e a documentação é explícita: nunca deve ser fixado no código, porque pode mudar a qualquer momento. Uma build que o lê dos parâmetros de lançamento pode ser apontada a outro ambiente; uma que o traz fixo, não. Quando um agregador pergunta se um título é portável entre operadores, essa única linha é muitas vezes a resposta.

O indicador social avisa o jogo de que está a correr para um operador social ou de sweepstakes, e espera-se que coincida com um indicador de jurisdição devolvido pela chamada de autenticação da carteira. Um título que o ignora mostrará um enquadramento de dinheiro real a um jogador cuja conta não é de dinheiro real. Não é uma diferença cosmética, e é invisível numa revisão de secretária do jogo no ambiente de staging do próprio estúdio.

O indicador de demo é o terceiro. Um lançamento de demo é uma sessão de dinheiro de jogo, e o comportamento do jogo nela — o que mostra, o que desativa — faz parte do que a equipa comercial do agregador usará para vender o título aos operadores.

O ciclo de ronda é onde as integrações falham de facto

O fluxo básico da Engine é curto: autenticar a sessão, colocar a aposta e abrir uma ronda, reproduzir as animações da ronda e liquidá-la a seguir. O comportamento interessante está nos estados intermédios.

Uma ronda que não paga nada é fechada pela própria chamada de aposta; a ronda devolvida fica inativa e não há nada a terminar. Uma ronda com prémio mantém-se ativa até a chamada de fim de ronda a liquidar. Um jogo que assume que todas as rondas precisam de um fecho explícito, ou que nenhuma precisa, vai reconciliar mal contra a carteira do operador mesmo que cada giro pareça correto no ecrã.

Só pode haver uma ronda ativa de cada vez. Uma segunda aposta com uma ronda aberta é rejeitada. É essa única regra que torna o teste de desconexão útil: corta a sessão a meio de uma função, volta a lançar o jogo e confirma que a ronda inacabada regressa da autenticação com o último passo registado intacto. A API existe exatamente para isso: uma chamada de evento de aposta registra até onde o jogador chegou a ver, e a autenticação devolve esse valor para o frontend retomar a sequência em vez de a reiniciar.

Um agregador que integrou um título cujo caminho de retoma nunca foi exercitado integrou uma fila de suporte. O teste custa uma sessão de navegador.

O dinheiro é inteiro e a moeda é apenas uma camada de apresentação

Os montantes no RGS são inteiros com seis casas decimais de precisão. Uma unidade da moeda principal é um milhão. Isso não tem nada de especial até uma build tratar o montante como um número de vírgula flutuante e o saldo do jogador derrapar uma fração de cêntimo ao longo de uma sessão.

O dado mais útil para uma decisão de catálogo é que a moeda afeta apenas a camada de apresentação e não a lógica do jogo. A matemática do jogo não muda entre moedas; a apresentação muda. E isso importa porque a apresentação é onde estão as falhas: o mesmo título tem de mostrar um saldo em reais brasileiros, um saldo em euros e um saldo em ienes japoneses, e só um dos três leva duas casas decimais.

Aqui há uma armadilha que um estúdio que teste com códigos de três e quatro letras encontra depressa. A lista de moedas documentada inclui códigos com mais de três letras, e passar um deles a uma função padrão de formatação numérica lança um erro em vez de formatar. Uma build que formata qualquer código devolvido pela carteira, sem salvaguarda, parte com o primeiro operador cuja moeda não esteja nas tabelas do ambiente de execução. A orientação documentada é tratar códigos desconhecidos com elegância e mostrar o código depois do montante: uma decisão de uma linha que pertence à build, não a um ticket de suporte.

A escada de apostas tem de encaixar no mercado, não na demo

As apostas devem situar-se entre um mínimo e um máximo e ser divisíveis por um passo, os três devolvidos na autenticação. É oferecida uma escada recomendada de níveis de aposta como orientação, não como requisito, e a própria documentação da plataforma pede às novas submissões que suportem denominações pequenas — a partir de um cêntimo — porque isso ainda não é padrão no mercado.

Esse único requisito arrasta outros dois. Com apostas base muito pequenas, um multiplicador de prémio abaixo de um produz um prémio menor do que a unidade mínima representável, pelo que são necessárias mais casas decimais nos valores de prémio: três quando o prémio mínimo do jogo é igual ou superior a um décimo da aposta, quatro quando é inferior. O saldo em si não precisa de mais de duas casas decimais; os prémios em jogo precisam.

Os modos de aposta acrescentam uma segunda camada. Quando um jogo define vários modos, o jogador é debitado da aposta base multiplicada pelo multiplicador de custo desse modo, e cada modo tem o seu próprio máximo de aposta. Uma listagem de catálogo que publica um único máximo para um jogo com vários modos publica um número verdadeiro para um deles.

Para um agregador, a pergunta prática não é se a escada é generosa. É se a escada, os multiplicadores de custo e a precisão dos prémios são coerentes entre si no mercado onde o título é exposto. Uma escada em euros com mínimo de um cêntimo comporta-se de forma diferente da de um mercado onde a aposta mínima sensata se aproxima mais de uma unidade inteira.

O idioma é fornecido pelo operador e pode ser qualquer um

O parâmetro de idioma é um código ISO 639-1, e a documentação admite que transporta o que o operador tenha enviado: pode estar vazio e pode ser um código fora da lista suportada. A instrução é recorrer ao inglês para qualquer valor não suportado.

Isso produz um teste concreto e uma resposta concreta a uma pergunta que os agregadores fazem constantemente. A lista documentada cobre árabe, dinamarquês, alemão, inglês, espanhol, finlandês, francês, hindi, indonésio, japonês, coreano, polaco, português, russo, turco, vietnamita e chinês. O italiano não está lá.

A leitura correta não é que uma versão italiana seja impossível. É que um lançamento italiano chegará ao jogo como um código não suportado e a salvaguarda do próprio jogo decidirá o que o jogador vê. Se a encomenda inclui o mercado italiano, as strings italianas e o caminho de salvaguarda italiano fazem parte da build entregue e do teste de integração, e não de uma suposição herdada da lista da plataforma.

O ecrã de ajuda é um artefacto de mercado

No Reino Unido, o material que um jogador pode ler antes de se comprometer a apostar é uma superfície regulatória, não copy de marketing. Os padrões técnicos remotos da Gambling Commission exigem uma explicação das regras facilmente disponível e exata, uma indicação do estado atual do jogo à medida que avança, informação suficiente para avaliar as possibilidades de ganhar — incluindo a margem da casa ou o retorno ao jogador — e os prémios potenciais ou o modo como são determinados.

Para um estúdio, isso significa que o ecrã de ajuda e a tabela de pagamentos são saídas de integração que variam por mercado. Um título exposto em várias jurisdições arrasta várias expectativas de divulgação, e a versão que satisfaz o mercado mais exigente dos que se oferecem costuma ser a que vale a pena construir em vez de manter variantes.

Os critérios de aceitação de frontend para uma submissão à plataforma cobrem a forma como se chega a essas superfícies e como a interface responde às perguntas do jogador; esta é a camada de baixo, fixada por mercado.

O que o dossiê deve conter

Um agregador pode executar tudo o acima como revisão, e um estúdio pode tornar a revisão curta entregando um dossiê. Sete itens:

O tratamento dos parâmetros de lançamento, declarado. Que parâmetros a build lê e o que faz quando falta um ou chega vazio.

A evidência do ciclo de ronda. Uma gravação do caminho de desconexão e retoma, não uma garantia de que funciona.

A tabela de dinheiro e moedas. Cada moeda que a build realmente mostrou, com o seu número de casas decimais, mais o comportamento perante um código desconhecido.

A escada de apostas por modo. Mínimo, máximo, passo e multiplicador de custo de cada modo, e a decisão de precisão de prémios que decorre da aposta mais pequena.

A matriz de idiomas. Que códigos são servidos com copy nativo, quais caem para a salvaguarda e para o quê.

As superfícies de divulgação por mercado. O conteúdo de ajuda e tabela de pagamentos, mapeado às jurisdições em que o título é oferecido.

As perguntas em aberto. O que a build ainda não resolve, por escrito. Um dossiê sem perguntas em aberto costuma ser um dossiê que não foi lido com atenção.

Nada disto substitui a certificação, e nada disto promete uma aprovação. É a diferença entre um título que entra num catálogo uma vez e um título que entra mercado a mercado, com a mesma conversa de cada vez.

Para um estúdio que encomenda ou adapta um título para vários operadores, o momento mais barato para fechar estas perguntas é o brief. O brief de projeto da Engine é onde se escrevem o conjunto de mercados, os modos e o destino de integração antes de a build existir, e a evidência de entrega anterior está em o guia de paridade entre matemática e cliente. Quando o catálogo é montado através de uma única passagem em vez de integrações diretas, o modelo de agregador explica o que essa passagem absorve e o que não absorve.

Perguntas frequentes

O que deve um agregador testar antes de acrescentar um jogo por encomenda?

Quatro coisas para além da qualidade do jogo: se a build lê os seus parâmetros de lançamento em vez de os fixar no código, se o ciclo de ronda sobrevive a uma desconexão a meio de uma função, se o dinheiro e a moeda são mostrados corretamente mesmo com códigos que a build nunca viu, e se a escada de apostas e o suporte de idiomas encaixam nos mercados em que o título vai ser exposto. Cada uma é verificável numa sessão de navegador ou numa revisão de código curta.

Por que razão a moeda importa se não altera a matemática?

Porque a moeda altera a camada de apresentação, que é onde um título falha de forma visível. Os montantes são inteiros com seis casas decimais, mas o saldo e os prémios mostrados seguem as convenções decimais de cada moeda, e códigos com mais de três letras não são aceites pelo formato numérico padrão. Uma build que formata qualquer código devolvido pela carteira sem salvaguarda parte com a primeira moeda desconhecida.

Um slot precisa das suas próprias traduções em italiano ou português se a plataforma suporta esses idiomas?

O português está na lista documentada de idiomas suportados e o italiano não. Um código de idioma fora dessa lista é passado ao jogo e espera-se que o jogo recorra ao inglês. Se uma encomenda cobre o mercado italiano, o copy italiano e o comportamento de salvaguarda fazem parte da build entregue e têm de ser testados nela, em vez de assumidos a partir da lista da plataforma.

O que acontece se um jogador se desligar a meio de uma ronda de bónus?

A Engine mantém a ronda aberta. Uma chamada de evento de aposta registra até onde o jogador chegou a ver, e a autenticação devolve a ronda inacabada com esse último passo registado, de modo que o frontend pode retomar a sequência em vez de a reiniciar ou abandonar. Uma build que nunca exercita este caminho continuará a parecer correta numa demo e continuará a produzir disputas em produção.

É opcional suportar apostas de um cêntimo?

A documentação da plataforma recomenda usar os níveis de aposta como orientação e afirma que as apostas devem cair dentro do mínimo, do máximo e do passo da sessão. Separadamente, pede às novas submissões que suportem denominações pequenas a partir de um cêntimo, o que por sua vez exige mais casas decimais nos prémios em jogo: três casas quando o prémio mínimo é igual ou superior a um décimo da aposta, quatro quando é inferior.