Aceitação do frontend no Engine: as verificações antes de submeter

Um front build é julgado pelo que um jogador consegue realmente fazer com ele. A revisão do Engine inspeciona o jogo quanto a funcionalidade, clareza, comunicação e desempenho técnico, e o pedido de aprovação abrange uma versão de frontend e uma versão de matemática revistas em conjunto. Essa frase é todo o contrato de aceitação: a versão que se submete é a versão que é examinada, e o frontend é metade dela.

Este artigo transforma as diretrizes públicas de aprovação do Engine numa lista de validação para o cliente. Cobre o que a revisão inspeciona, que recursos são rejeitados antes de se ler uma linha de código, o que a interface tem de revelar, os controlos que a plataforma espera, as condições de vista reduzida e de telemóvel, os níveis de aposta que vêm da sessão e não do design, o comportamento de rede que os revisores observam e o nível de qualidade que se situa acima da simples conformidade. Assume que quem lê está a encomendar um jogo original para o Engine e quer que o front build chegue à revisão já terminado.

A revisão inspeciona um front build e uma versão de matemática em conjunto

As diretrizes de aprovação do Engine descrevem com precisão o objeto da revisão: cada pedido abrange uma versão de frontend e uma versão de matemática, revistas em conjunto. A equipa inspeciona o jogo quanto a funcionalidade, clareza, comunicação e desempenho técnico, e comunica os problemas caso a caso, com as alterações pedidas e o raciocínio por trás da aprovação ou da rejeição.

Daí decorrem duas consequências para o briefing de encomenda. Primeiro, o front build não pode ser um alvo móvel enquanto a revisão está em curso; o que é submetido é o que é examinado. Segundo, um front build que apresenta resultados que a versão de matemática aprovada não contém não é uma discrepância menor. O que incluir num pacote de envio Engine cobre o empacotamento; este artigo cobre o que o próprio cliente tem de demonstrar antes de apresentar o pedido.

As diretrizes são também explícitas quanto ao facto de a aprovação ficar ao critério do revisor. Um jogo considerado ofensivo, explícito, de mau gosto ou de qualidade insuficiente pode ser rejeitado independentemente da correção técnica. A conformidade é o piso, não o alvo.

Os recursos têm de ser originais e servidos pela CDN da plataforma

A primeira categoria de rejeição não é funcional. Os jogos têm de usar recursos de áudio e visuais próprios: os fundos, símbolos e animações fornecidos com os jogos de exemplo do SDK web não são aprovados para publicação. Um build montado com arte de exemplo falha antes de alguém o jogar.

Os jogos têm também de ser designs originais. Não são permitidos jogos pré-comprados ou licenciados que já existam em sites de terceiros, e os nomes de equipa, títulos e recursos têm de cumprir a lei de propriedade intelectual e direitos de autor. Os recursos não podem incluir a marca ou os temas da Stake. A revisão procura um jogo que exista apenas nesta plataforma.

A entrega tem uma restrição equivalente. Os jogos do Engine têm de ser carregados como ficheiros estáticos, e todas as imagens e fontes têm de ser carregadas da rede de distribuição de conteúdos do Engine. A política rigorosa contra cross-site scripting significa que o build não pode aceder a fontes externas. Descarregar uma fonte de um servidor externo é o caso comum, e aparece como erros na consola durante a revisão em vez de uma degradação silenciosa. O alojamento de fontes e imagens pertence ao pipeline de build, não à última semana antes da submissão.

A interface tem de responder às perguntas do jogador

Os requisitos de frontend tratam a informação do jogo como parte do jogo. Tudo o que se segue tem de estar acessível a partir da interface:

• Uma descrição detalhada de todas as regras do jogo.
• Quando existe mais do que um modo, uma descrição do custo de cada aposta e das ações que estão a ser compradas.
• O RTP do jogo, indicado para cada modo quando os modos diferem.
• O valor máximo de prémio de cada modo, claramente apresentado.
• Os valores de pagamento de todas as combinações de símbolos.
• Todos os valores obteníveis de símbolos especiais, como prémios em dinheiro ou multiplicadores.
• Para os modos de funcionalidade, como se chega à funcionalidade; por exemplo, três dispersores concedem dez rodadas grátis e quatro concedem quinze.

Esta é uma lista de divulgação, não uma lista de marketing. Cada item é um facto que o jogador tem direito a encontrar antes de apostar, e cada um tem de coincidir exatamente com a versão de matemática aprovada. Uma tabela de pagamentos copiada de um build anterior, ou um RTP declarado uma única vez para um jogo cujos modos têm valores diferentes, é uma falha de apresentação que a revisão foi concebida para detetar.

Os controlos que se esperam de um front build

Os componentes de interface estão especificados um a um, o que facilita validá-los individualmente:

• Um guia de interface que descreva brevemente o que faz cada botão.
• A possibilidade de alterar o tamanho da aposta, cobrindo todos os níveis de aposta devolvidos na resposta de autenticação da sessão.
• O saldo atual do jogador, apresentado.
• Os valores de prémio finais, claramente apresentados em todos os pagamentos diferentes de zero.
• Quando um resultado contém várias ações vencedoras, um pagamento que suba progressivamente até ao multiplicador final em vez de saltar para ele.
• Uma opção para desativar o som.
• A barra de espaço associada ao botão de aposta.
• Se existir autoplay, um passo de confirmação: os jogos não podem colocar apostas consecutivas automaticamente com um único clique.

Nenhum destes pontos é acabamento opcional. São a diferença entre uma demo e um cliente que um jogador consegue operar sem adivinhar, e cada um é barato de testar e caro de refazer depois de a versão de frontend ter passado por revisão.

A vista reduzida e o telemóvel são condições de aceitação

Duas condições de visualização são apresentadas como requisitos e não como recomendações. A plataforma oferece aos jogadores um modal mini-player para que um jogo possa correr em segundo plano, e o jogo tem de suportar essa vista pequena sem que o tabuleiro ativo fique visivelmente distorcido. O jogo tem também de suportar a vista de telemóvel nos dispositivos de uso comum, com toda a funcionalidade de interface utilizável durante o escalamento do ecrã.

Ambas são falhas de maquetagem, não de lógica, pelo que raramente aparecem num teste funcional. Um build que se joga corretamente à largura de ambiente de trabalho e perde os controlos de aposta no mini-player não passou os requisitos de frontend. O passo prático de aceitação é carregar o build na vista pequena e em larguras de telemóvel e operar cada controlo, em vez de verificar que a página é renderizada.

Os níveis de aposta vêm da sessão, não do design

A resposta de autenticação da sessão devolve os níveis de aposta predefinidos, os níveis suportados para uma determinada moeda e os valores mínimo e máximo. O frontend tem de respeitar esses valores. As diretrizes apresentam diretamente o modo de falha: se o tamanho de aposta predefinido é uma unidade mas a sessão usa uma moeda cujo mínimo são dez unidades, o pedido de jogo falha.

Os incrementos de aposta têm de refletir os valores permitidos dentro da configuração autenticada, e os níveis mínimo e máximo têm de poder ser selecionados. Uma escala de apostas fixada no código que funciona numa moeda é um risco de aceitação em todas as outras. O parâmetro de consulta rgs_url determina a que servidor o cliente chama, pelo que o build tem também de ler esse parâmetro em vez de assumir um endpoint.

A localização pertence ao mesmo teste. O inglês é o único idioma obrigatório, mas se o build só suporta inglês, o texto no ecrã não pode corromper-se quando são passados outros parâmetros de idioma. A revisão testa combinações de moedas e idiomas, e o modal de jogo oferece uma definição de modo social para testar idiomas sociais, porque os jogos são considerados para publicação na stake.us sujeitos a requisitos de idioma rigorosos.

O separador de rede faz parte da revisão

As verificações publicadas incluem inspecionar o separador de rede à procura de erros e de informação do jogo que fique registada. Um build que escreve dados de ronda ou identificadores de jogador na consola deixa-os no navegador, e a revisão lê a atividade de rede como parte da avaliação técnica.

O playtest segue a mesma lógica: o revisor joga para verificar que o jogo se comporta como as regras descrevem, incluindo a validação de combinações de pagamento. Isso torna o texto das regras e o build num único artefacto. Se as regras prometem um comportamento que o cliente não produz, a discrepância é encontrada durante a revisão e não num ticket de suporte.

Quando existe uma opção de jogo rápido, os valores de prémio, as combinações de símbolos vencedoras e a informação emergente têm de continuar legíveis para o jogador. As definições de velocidade são um dos pontos em que a divulgação se degrada sem aviso.

A qualidade está acima da conformidade

Passar as verificações técnicas não garante a aprovação. Os jogos submetidos recebem uma classificação de qualidade de zero a três estrelas, avaliada por três revisores anónimos que escolhem cada um numa escala fracionária fixa, em passos de cerca de um terço de estrela. A média das três pontuações é calculada e arredondada, e uma média abaixo de uma estrela é tratada como inferior ao limiar mínimo, independentemente do arredondamento: uma média de 0,67 não se torna um.

A consequência de ficar abaixo do limiar é processual: o tópico de aprovação é fechado e bloqueado, o jogo tem uma janela de melhoria de sete dias e pode ser resubmetido para um novo ciclo de revisão depois. Essa política está em vigor desde março de 2026. Não é uma rejeição permanente, mas é um custo de sete dias que um briefing pode evitar se tratar o acabamento como parte da aceitação e não como uma passagem posterior.

O que validar antes de apresentar o pedido

A conversa de aceitação pertence ao momento anterior ao pedido, não ao comentário de revisão. Um briefing deve fechar:

• O par de versões submetido: que front build e que versão de matemática vão para revisão, e quem confirma que são o par que está a ser descrito.
• A proveniência dos recursos: confirmação de que não resta arte, áudio ou fonte dos jogos de exemplo no build, e de que cada imagem e fonte é servida pela CDN da plataforma.
• O conjunto de divulgação: regras, custo de aposta por modo, RTP por modo, prémio máximo por modo, a tabela de pagamentos completa e as condições de acesso de cada modo de funcionalidade.
• O inventário de controlos: cada componente de interface enumerado, com os níveis de aposta lidos da sessão autenticada em vez de uma lista fixa.
• As condições de visualização: vista reduzida do mini-player e escalamento de telemóvel, cada uma operada e não apenas renderizada.
• O estado de rede: sem erros de consola e sem informação de jogo ou de jogador registada.
• O nível de qualidade: sobre o que o build será julgado para além da conformidade e quem assina esse juízo.

Nada disto exige engenharia nova. Exige que a lista de aceitação seja escrita enquanto o build ainda pode mudar. Um estúdio que desenvolve jogos para o Engine já estará a testar a maior parte destes pontos; a diferença está em saber se o operador recebe os resultados como evidência ou descobre as lacunas num tópico de revisão.

Perguntas frequentes

O que é que a revisão do Engine inspeciona realmente num jogo?

As diretrizes de aprovação do Engine indicam que cada pedido abrange uma versão de frontend e uma versão de matemática, revistas em conjunto, e que a equipa inspeciona o jogo quanto a funcionalidade, clareza, comunicação e desempenho técnico. A aprovação fica ao critério do revisor, pelo que cumprir os requisitos técnicos é necessário mas não suficiente.

Um front build pode ser publicado com os recursos de exemplo do SDK web?

Não. Os jogos submetidos têm de usar recursos de áudio e visuais próprios, e os fundos, símbolos ou animações fornecidos com os jogos de exemplo do SDK web não são aprovados. Além disso, os jogos têm de ser designs originais e não jogos pré-comprados ou licenciados já disponíveis em sites de terceiros.

Porque é que uma escala de apostas fixada no código falha na revisão do Engine?

A resposta de autenticação da sessão devolve os níveis de aposta predefinidos, os suportados para uma moeda e os valores mínimo e máximo, e o frontend tem de os respeitar. Se o tamanho predefinido é uma unidade mas a sessão usa uma moeda com um mínimo de dez unidades, o pedido de jogo falha. Os incrementos têm de seguir a configuração autenticada.

O que acontece se um jogo do Engine pontuar abaixo de uma estrela?

Os jogos recebem uma classificação de zero a três estrelas de três revisores anónimos, com a média calculada e arredondada. Uma média abaixo de uma estrela é tratada como inferior ao limiar mínimo, pelo que o jogo não é aprovado. O tópico de aprovação é fechado e bloqueado durante uma janela de melhoria de sete dias, após a qual o jogo pode ser resubmetido para um novo ciclo.

São permitidas alterações de frontend depois de o jogo ser aprovado?

Só são permitidas atualizações menores que corrijam problemas visuais após a aprovação, salvo se a equipa do Engine pedir outra coisa. Não são permitidas alterações ao modelo matemático subjacente, novos modos de jogo nem modificações de mecânicas. O que muda após aprovar um jogo Engine cobre esse limite em detalhe.