Da ideia ao ar no Stake Engine: como um slot independente é aprovado

O Stake Engine permite que estúdios independentes publiquem jogos na Stake. A documentação resume assim: crie um jogo, publique no Studio e lance na Stake e na rede do Engine (documentação do Stake Engine). Pitch simples; revisão minuciosa.

Foi assim que o nosso slot Vampir: Graveyard Shift saiu de um pitch de uma página e chegou ao ar. Todos os detalhes do caso abaixo vêm do nosso próprio design doc, da especificação de matemática, das notas para os revisores e da revisão pré-envio.

Primeiro, entenda o que você está entregando

Um jogo do Stake Engine é um conjunto de arquivos estáticos: a matemática, com todos os resultados gerados de antemão, e um front-end que reproduz esses resultados. O RGS da plataforma sorteia uma simulação na proporção do seu peso e entrega o "book" dela (uma lista JSON de eventos do jogo) ao seu front-end. Como todo resultado possível já existe num arquivo, os revisores conseguem conferir a matemática com exatidão (documentação do Math SDK).

Isso define todo o resto:

• A matemática é um conjunto de arquivos, não reel strips rodando num servidor. Por modo: uma tabela de consulta em CSV (número da simulação, peso, pagamento) e um arquivo de eventos compactado, além de um index.json. Os pagamentos ficam em centésimos (formato de arquivo).
• Os jogos são stateless. Sem jackpots, sem gamble, sem continuidade entre rodadas, sem cash-out antecipado (diretrizes de aprovação).
• O front-end não decide nada. Ele lê o book e faz o show.
• Depois da aprovação, a matemática fica congelada. Só são permitidas pequenas atualizações visuais.

Passo 1: um conceito que sobrevive à checagem de título

O pitch do Vampir cabe em duas linhas. Tio Vlado, um vampiro balcânico boa-praça, pegou o único emprego compatível com o horário dele: vigia noturno do cemitério da vila. Quem trabalha de verdade são os morcegos.

A originalidade tem que estar na mecânica, porque tema de vampiro, sozinho, não tem nada de original:

• Grade 6×5 pay anywhere com cascatas (tumbles).
• Os wilds Bat (morcegos) carregam um multiplicador que cresce +1 a cada cascata em que sobrevivem. No fim da sequência, o ganho é multiplicado pela soma de todos os multiplicadores Bat. Os Bats se somam; nunca se multiplicam entre si.
• Vlado's Bite: depois de um ganho no jogo base com Bats no tabuleiro, o Vlado pode dar uma mordida e dobrar todos os Bats (cerca de 1 em 80 rodadas do jogo base).
• Rodadas grátis como um turno da noite: dez rodadas mostradas como as horas das 21:00 às 07:00. À meia-noite, todos os Bats dobram; às 03:00, chega voando um Bat novo com ×2. Quatro, cinco ou seis Coffins (caixões) ativam três níveis do Shift.

Depois, a checagem de título. Pesquisamos os slots existentes antes de fechar um nome. "Night Shift" caiu porque já existe um "Knight Shift". Também deixamos "Count" fora de todos os nomes, porque The Count, da Hacksaw, já usa morcegos wild, e mantivemos os nossos morcegos com um visual só nosso. O Stake Engine exige um título único, sem termos restritos, e os revisores verificam se o jogo se diferencia dos títulos existentes. Uma hora de pesquisa no primeiro dia sai bem mais barata que um rebranding no dia da revisão.

Passo 2: a matemática, em books

As verificações críticas de matemática do Stake Engine bloqueiam o envio se falharem (verificação de matemática). Entre elas: RTP de cada modo entre 96,0% e 96,7%, ganho máximo de até 1.000.000×, custo máximo de até 50.000×, um modo mais barato custando 1,0× e um desvio padrão mínimo para os modos de 1×. As verificações não críticas não bloqueiam o envio, mas falhar nelas reduz o nível de exposição do jogo e a aposta máxima.

Nossas escolhas de design, feitas pensando nesses níveis:

Todos os modos têm teto de 25.000×, e a rodada termina no instante em que o teto é atingido. Isso mantém o jogo dentro dos limites de 3 estrelas da documentação (pagamento máximo de 100.000×, custo máximo de 5.000×, desvio padrão de 60), e assim o jogo se qualifica para o nível de exposição mais alto.

Algumas coisas que aprendemos na marra:

• Faça o ganho máximo ser alcançável. A documentação diz que ele deve ser realisticamente atingível, em geral com frequência maior que 1 em 10.000.000. Os 25.000× do Vampir saem em cerca de 1 em 6,25 milhões de rodadas do jogo base.
• De olho nas migalhas. A documentação avisa que uma taxa de acerto (hit rate) mais rara que 1 em 50 apostas, ou uma parcela muito alta de resultados sem pagamento, pode ser motivo de rejeição. O jogo base do Vampir acerta 1 em 3,21, e 1 rodada em 4,50 devolve a aposta ou mais.
• Reproduza todos os books. Geramos 100.000 books por modo e reproduzimos cada um contra as regras e o contrato de eventos, com zero falhas. Se um book consegue quebrar o seu front-end, um revisor vai achar.

Passo 3: um contrato de eventos entre matemática e front-end

Antes de escrever código de front-end, documentamos todo evento que um book pode conter e o que ele carrega: os eventos padrão, como reveal e winInfo, e os próprios do jogo, como batUpdate, vladoBite, midnight e newBat. Cada valor de Bat, a mordida, o relógio e cada prêmio vêm do book. Nada é decidido no cliente.

Esse contrato também garante uma apresentação honesta:

• Uma rodada que devolve menos do que custou nunca dispara uma comemoração de ganho.
• As telas de big win dos recursos comprados mostram o resultado líquido, não o bruto.
• A antecipação só aparece quando falta um Coffin para ativar o Shift, conforme o book informa.

Passo 4: as verificações de front-end que os revisores fazem de verdade

Os requisitos de front-end parecem uma lista. Na prática, são cerca de quarenta verificações separadas. Rodamos todas nós mesmos no build de produção, com um RGS mock servindo os books reais. Agrupadas:

A primeira passada encontrou duas falhas: no popout de 400×225, um card de compra cobria o botão do menu, e o guia dentro do jogo não explicava a chave do Night Owl. As duas foram corrigidas e verificadas de novo. Placar final: 36 aprovadas, 0 reprovadas, 3 para avaliação humana (conteúdo, diferenciação e jogo por toque num celular de verdade), 1 não aplicável.

Passo 5: o padrão de acabamento

Passar no checklist não é o mesmo que passar na revisão. Três revisores dão de 0 a 3 estrelas cada um, o jogo precisa de pelo menos 6 de 9 pontos para ser publicado, e só jogos com 3 estrelas aparecem em seções como New Releases (rankings de qualidade de jogo).

Um jogo nosso anterior voltou com feedback sobre arte com cara genérica, fontes padrão, ícones de emoji, preenchimentos em degradê e animação travada ou ausente em momentos-chave. Então, antes de enviar o Vampir, auditamos o jogo em cada um desses pontos:

• Nada de UI desenhada em código. Toda superfície de controle virou arte pintada no estilo do jogo: o botão de girar, a placa de compra, os diálogos, as chaves, o mostrador do relógio.
• Letreiros pintados para cada grande momento (BIG BITE, MIDNIGHT, os nomes dos Shifts) e dígitos dourados pintados para os valores. A fonte simples ficou só para textos pequenos.
• Sem engasgos na primeira vez. O primeiro big win e a primeira explosão de efeitos custavam um frame de ~27 ms (upload de textura e compilação de shader), então tudo é pré-aquecido durante a tela inicial.
• Áudio limpo. Alguns arquivos tinham picos acima de 0 dBFS e podiam estalar em certos aparelhos. Tudo foi remasterizado para ficar abaixo de 0 dB de true peak depois da codificação.
• Um tabuleiro vivo. Os Bats brilham e batem as asas, as velas tremulam, de vez em quando uma aranha desce da moldura, e cada hora do Shift é marcada por um sino.

Passo 6: empacotar e enviar

O upload é mecânico, e é exatamente por isso que dá errado. O que foi enviado no Vampir:

• Matemática: 11 arquivos: index.json, um arquivo de books e uma tabela de consulta por modo. Cerca de 711 MB no total; só os books de bonus buy têm 210–230 MB cada. Conferimos a versão certa pelo tamanho exato dos arquivos antes de publicar.
• Front-end: index.html mais uma pasta de assets, 189 arquivos e cerca de 29 MB.
• Mídia: um tile 3:4 e uma capa 16:9. Sem eles, o Submit fica bloqueado. O título usa uma única fonte em no máximo dois tamanhos, dentro da área segura, sem textos extras como "25,000x", "NEW" ou "BONUS".
• Notas para os revisores: recursos, a tabela de matemática, notas sobre o jogo ser stateless, apresentação e vocabulário do modo social, além de IDs de eventos de replay por modo para uma perda, um ganho normal, uma ativação de bônus, um big win e o ganho máximo.
• Distribuição: o Vampir é Only on Stake. A documentação descreve a participação nos lucros em 10% do GGR real para esses jogos e 5% para os jogos da rede (pagamentos).

Uma regra pesa no seu planejamento mais que qualquer outra: até o seu primeiro jogo entrar no ar, você pode ter uma revisão aberta por vez, e um jogo que não atinge a nota mínima fica bloqueado por três dias (checklist de envio). Jogue no preview do Studio num celular e num computador antes de apertar Submit.

Resumo da ópera

Mais um motivo para acertar: a documentação de distribuição diz que a rede do Engine abre para todos os operadores em 13 de outubro de 2026, então os jogos da rede podem chegar a lobbies além do da própria Stake. Veja o resultado na nossa página de jogos e na página de lançamento do Vampir.

18+Conteúdo sobre jogos de azar para leitores do setor. Todas as demos que linkamos rodam com dinheiro fictício. Se apostar deixar de ser diversão, há ajuda gratuita e confidencial: BeGambleAware (Reino Unido), 1-800-GAMBLER (EUA), Gambling Therapy (no mundo todo).