Como se constrói um jogo Stackwell
Matemática primeiro.
Arte no fim.
Um jogo Stackwell é construído numa só direção. A máquina é concebida, medida e provada antes de se desenhar um único símbolo — para que o que sai seja um instrumento medido a vestir uma carcaça bonita, e não uma carcaça bonita à espera de vir a ser um instrumento.
Matemática
A tabela de pagamentos, as faixas de rolos, a curva de volatilidade — escritas como um modelo versionado antes de se desenhar um único símbolo. O manifesto que o estúdio publica é o contrato exato que o servidor avalia, despachado por versão, para que a matemática de um jogo antigo nunca seja reinterpretada em silêncio por um motor mais recente.
Simulação
O modelo é corrido num banco de ensaio Monte-Carlo até o RTP que declara e o RTP que paga serem o mesmo número. Já apanhámos o nosso próprio afinador a mentir — é esse o objetivo do passo. Os designers afinam contra uma leitura de RTP do servidor em tempo real, com um veredicto: no alvo, paga a mais, paga a menos.
Arte
Mundos originais, heróis com rig, animação de performance a sério. Gerados, compostos e dirigidos à mão — nunca um re-skin do título anterior. A arte chega no fim, por cima de um jogo que já funciona, para que um jogo bonito nunca seja desculpa para um jogo por medir.
Interface
A barra de controlo é um instrumento impresso encaixado num palco iluminado. Os jogadores reconhecem um jogo Stackwell antes de lerem o nome — e o mesmo sistema de design corre o estúdio, os jogos e este site.
Cada mecânica existe duas vezes: uma no motor de estúdio, onde os designers afinam faixas de rolos, tabelas de pagamentos e funcionalidades contra uma leitura de RTP em tempo real — e outra no motor de servidor, escrito em Go, que é a única autoridade sobre os resultados quando há dinheiro em jogo. O browser apresenta; nunca lhe é confiada a decisão.
Os dois são mantidos juntos por um manifesto de jogo versionado — o contrato exato que o estúdio publica e o servidor avalia — e por testes de paridade que fazem falhar o build se a declaração do estúdio e a medição do servidor divergirem. Uma mecânica que só existe do lado do cliente não é lançada num jogo a dinheiro real, ponto final.
"Simulado milhões de vezes" é uma afirmação concreta, não um slogan. Estas barreiras correm em infraestrutura real, e um jogo que falhe uma delas não avança.
- Auditoria contínua da frota. O manifesto de cada jogo publicado é remedido a cada push de código — 200,000 rodadas simuladas por jogo em CI — para que uma alteração em qualquer ponto do motor não possa mexer em silêncio no RTP de nenhum jogo.
- A barreira de ativação. Antes de um jogo poder ser ligado para um operador, o seu RTP medido no servidor tem de ficar dentro de ±1.5 pontos percentuais do alvo declarado. Os jogos de variância alta correm com mais de 200,000 rodadas, porque uma estimativa ruidosa não é uma estimativa.
- Auditorias à frota em produção com 300,000 rodadas contra a base de dados de produção — os manifestos que os operadores lançam de facto, não aqueles que nos lembramos de ter publicado.
- Nunca lançar acima de 100%. Um jogo que paga a mais faz o operador perder dinheiro; um que paga a menos é um problema de equidade. Ambos bloqueiam o lançamento, não geram um ticket.
É também por isto que as demos deste site valem o seu tempo: jogam a partir do mesmo motor, com um saldo de demonstração. Medimos um jogo antes de o promovermos.
Veja o resultado no palco — todos os títulos jogáveis no browser — ou leia como chega ao seu lobby.