O protótipo de mecânica: o que provar antes da arte final

Um protótipo num projeto de slot por encomenda costuma ser apresentado como uma demo: uma build tosca que mostra a mecânica a funcionar. É essa forma de apresentar que faz com que a aprovação do protótipo se transforme tantas vezes numa discussão três meses depois. Uma demo responde a “isto sente-se como alguma coisa?”. Um portão de protótipo tem de responder a uma pergunta mais estreita e muito mais cara: o conjunto de resultados que esta mecânica produz é aquele em que estamos dispostos a investir arte, som e uma submissão?

Numa plataforma que exige que todos os resultados sejam conhecidos no momento da publicação, essa pergunta não é retórica. O conjunto de resultados da mecânica é o produto. A arte é uma camada de representação por cima, e o custo de mudar o conjunto de resultados depois de a arte existir é o custo de refazer o jogo.

Este artigo é para as duas pessoas que assinam esse portão: o operador ou publisher que decide se liberta o orçamento de produção, e o produtor do estúdio que decide o que o protótipo tem de conter para poder ser dado como terminado. A evidência de entrega que vem depois é tratada em o guia de paridade entre matemática e cliente; esta é a decisão anterior.

Porque o que se aprova é o conjunto de resultados e não a arte

A documentação pública de matemática da Engine é invulgarmente direta sobre a restrição. Uma máquina de slot física pode escolher uma posição de rolo para cada rolo no momento do giro, mas um jogo de cinco rolos com cem símbolos por tira tem dez mil milhões de tabuleiros possíveis, e calcular prémios exatos sobre esse espaço não é prático. Por isso a plataforma segue outro caminho: gera-se antecipadamente um subconjunto de resultados que define o jogo, e todos os resultados têm de ser conhecidos no momento da publicação.

Isso produz uma estrutura de dois ficheiros. Os ficheiros de lógica de jogo — os livros — contêm uma lista ordenada do que acontece: nomes de símbolos, posições no tabuleiro, montantes de prémio e posições vencedoras. Um resumo de pagamentos em CSV à parte contém uma linha por simulação com o número de simulação, o seu peso de seleção e o pagamento. Quando é pedida uma ronda, o RGS escolhe um número de simulação dessa tabela e devolve a carga de eventos correspondente, e a carteira é atualizada com o pagamento.

A consequência para um protótipo é brutal. O protótipo não é uma pré-visualização do jogo; é o primeiro rascunho do conjunto de resultados de que o jogo publicado vai consistir. Se a distribuição da mecânica está errada — demasiados giros mortos, uma função que aparece com demasiada pouca frequência para ser vista, uma cauda que paga mais do que o mercado tolera —, isso não é um problema de afinação a resolver no polimento. É um redesenho daquilo que a arte está construída para representar.

O que o protótipo tem de produzir

Um protótipo que pode ser aprovado produz quatro artefactos, e cada um responde a uma pergunta diferente.

O conjunto de resultados em si. Os livros, numa forma que um revisor possa ler. O próprio início rápido da Engine sugere começar com um lote pequeno — cem simulações por modo, sem compressão — precisamente para poder inspecionar os eventos a olho. É o primeiro passo correto e o último errado: cem resultados não se aproximam da estatística em larga escala, e a documentação di-lo.

A divisão por modo. Os modos são simulados em separado, com as suas próprias contagens de simulação, as suas próprias tabelas de consulta e os seus próprios livros. Um jogo base e um modo de bónus são duas distribuições que têm de ser equilibradas entre si, não uma distribuição com uma função anexada.

A folha PAR. Executar o passo de análise gera um documento que resume as estatísticas-chave do jogo e as taxas de acerto, derivadas das tabelas de consulta, da tabela de pagamentos e dos registos de forçagem. É o artefacto que um comprador deve ler no portão, porque é o único que enuncia o comportamento da mecânica em números e não em sensações.

A saída da verificação de formato. O passo de verificação revê os livros comprimidos e as tabelas de consulta otimizadas antes do upload: os pagamentos têm de coincidir entre os dois ficheiros, e as estatísticas de cada modo — RTP e medidas de volatilidade — são escritas num ficheiro de resumo. Também avisa quando um modo excede os limites de volatilidade verificados para aprovação, e quando os RTP de modos diferentes diferem em mais de cinco por cento.

Esse último aviso merece uma pausa. É uma verificação do lado da plataforma, não uma opinião de design, e existe porque um jogo cujos modos se separam em RTP é um jogo cujo retorno anunciado não descreve o que um jogador experimenta no modo a que realmente chega.

Os três números que decidem se a mecânica sobrevive

Uma revisão de protótipo que só fala de “como se sente” não reviu a mecânica. Três números carregam a decisão.

O RTP, declarado por modo e como divisão de contribuição. A saída de simulação informa o RTP total a par da parte que vem do jogo base e da que vem da função. Um jogo a 96,7 por cento global pode ser 4,3 por cento de base e 158,8 por cento de função num lote forçado, o que diz de imediato onde vive o retorno. Um comprador que só vê o número de topo não consegue saber se a mecânica é um jogo de base ou um jogo de função, e essa distinção determina o orçamento de arte, o design de som e o gancho de marketing.

A frequência de acerto, e o que conta como acerto. A folha PAR informa frequências de eventos e combinações concretas, não uma única taxa agregada. A “frequência de acerto” como número único esconde a diferença entre muitos retornos pequenos e poucos retornos grandes, e esses dois jogos precisam de arte de símbolos diferente, comportamento de antecipação diferente e expectativas de jogador diferentes.

A volatilidade, face ao limite que a plataforma verifica. A volatilidade é medida por modo e comparada com os limites de aprovação. Um protótipo que fica fora deles não é candidato a polimento; é candidato a outra tabela de pagamentos.

Nenhuma destas ideias é nova. O que é novo, num contexto de encomenda, é pedi-las no portão do protótipo e não no portão da submissão, que é a diferença entre uma decisão de design e uma reconstrução.

A cauda é uma decisão de design e tem de ser forçada

A parte de uma distribuição que um lote pequeno de simulações nunca mostrará é a cauda: o prémio máximo e as rondas que dele se aproximam. As ferramentas da Engine resolvem isto com registos de forçagem — ficheiros por modo que instruem a simulação a produzir resultados concretos, incluindo os de prémio máximo — para que a cauda exista no conjunto de resultados e possa ser medida em vez de esperada.

Isto importa no portão do protótipo por uma razão prática. Um prémio máximo não é apenas um número numa tabela de pagamentos; é uma peça de apresentação. Precisa de uma celebração de prémio, uma sequência, um design de som e uma duração, e tudo isso é trabalho de arte e engenharia que tem de ser delimitado. Um protótipo que nunca produziu o seu próprio prémio máximo não mostrou à equipa o que lhe é pedido construir.

O limite honesto é que forçar a cauda inflaciona o RTP do lote, e a documentação di-lo: um lote forçado pode informar um total bem acima do objetivo porque contém muitas mais simulações de prémio máximo do que as que serão concedidas naturalmente. O passo de otimização é o que reequilibra os pesos depois. Um comprador que lê o RTP de um lote forçado como o RTP do jogo leu mal o artefacto, e um estúdio que o apresenta assim apresentou o número errado.

O que o protótipo não pode demonstrar

Três coisas que muitas vezes se pedem a um protótipo e que ele não pode provar.

Não pode provar retenção. Um protótipo não tem jogadores, nem duração de sessão, nem coortes. O que pode fazer é enunciar uma hipótese testável — esta mecânica deveria produzir uma determinada frequência de entrada na função, e essa frequência é o que há a medir após o lançamento —, e isso é uma afirmação diferente e mais útil do que uma projeção.

Não pode provar adequação à marca. Se a mecânica se adequa à marca de um operador é um juízo sobre a audiência, e a contribuição do protótipo é mostrar a forma da mecânica com clareza suficiente para que esse juízo possa ser feito. Um protótipo que esconde um jogo base fraco atrás de uma apresentação de função forte torna esse juízo mais difícil, não mais fácil.

Não pode provar aprovação. Os limites de volatilidade e as tolerâncias de RTP são verificados pela plataforma, e um protótipo que passa uma verificação de formato local passou uma verificação de formato local. A distinção entre “a nossa simulação é internamente coerente” e “isto será aprovado” é a mesma que o guia do pacote de submissão traça para a fase de revisão.

O portão, escrito como lista de assinatura

Um portão de protótipo que pode realmente ser assinado tem seis pontos, e cada um é um documento e não uma opinião.

O conjunto de resultados, à escala de produção. Não cem simulações. A orientação da documentação para um jogo pronto para produção é da ordem de cem mil simulações por modo, que é o que dá ao otimizador um intervalo suficientemente diverso de multiplicadores de pagamento e reduz a probabilidade de um mesmo jogador ver a mesma ronda duas vezes.

A divisão de RTP por modo, com as contribuições de base e função declaradas em separado. Incluindo a ressalva do lote forçado, para que ninguém leia um número forçado como o número publicado.

A folha PAR, com frequências ao nível do evento. Taxa de entrada na função, frequências por faixas de prémio e as combinações concretas de que o design depende.

A medição de volatilidade por modo, face ao limite de aprovação. Com a divergência de RTP entre modos declarada, porque uma divergência superior a cinco por cento é um aviso que a própria plataforma emite.

A cauda, forçada e apresentada. O prémio máximo existe como ronda, e o trabalho de apresentação que implica está delimitado.

As perguntas abertas da mecânica, por escrito. O que o protótipo não resolveu e o que o resolveria. Um portão que fecha sem perguntas abertas normalmente não foi examinado com detalhe suficiente.

A razão para insistir nisto na fase de protótipo não é o processo pelo processo. É que o conjunto de resultados é a única parte de um slot que não pode ser mudada de forma barata depois. A arte pode ser revista, o texto pode ser reescrito, um front end pode ser refeito. Uma distribuição já construída numa versão matemática publicada, com a arte e as apresentações de prémio desenhadas em torno das suas frequências, é uma proposição completamente diferente.

Para um publisher, o pedido prático é simples: antes de libertar o orçamento de produção, solicita a folha PAR e a divisão por modo, e lê-os contra a mecânica que pensavas estar a comprar. O briefing do projeto Engine é onde esse âmbito é escrito, incluindo os modos que a encomenda cobre e a evidência que o portão do protótipo tem de produzir.

Perguntas frequentes

O que deve incluir um protótipo de slot antes de encomendar a arte final?

No mínimo: o conjunto de resultados a uma escala suficientemente grande para ser estatisticamente significativa, a divisão de RTP entre jogo base e função declarada por modo, uma folha PAR com frequências de acerto ao nível do evento, a medição de volatilidade de cada modo face aos limites de aprovação da plataforma, e uma ronda de prémio máximo forçada para que a cauda exista como resultado real. Cada um destes é um documento que um comprador pode ler, que é o que separa um portão de protótipo de uma revisão de demo.

Porque é que o conjunto de resultados tem de ser fixado antes de construir a arte?

Porque na Engine todos os resultados têm de ser conhecidos no momento da publicação. O jogo é definido por um conjunto gerado de resultados — os livros — mais um resumo de pagamentos em CSV que o RGS usa para selecionar um número de simulação e devolver os eventos correspondentes. A arte representa esses eventos. Se a distribuição mudar depois de a arte existir, as apresentações de prémio, o comportamento de antecipação e as sequências de função foram desenhados em torno de frequências que já não se aplicam.

Quantas simulações precisa um protótipo?

A documentação da Engine sugere começar com cerca de cem simulações por modo em formato sem compressão para poder inspecionar os eventos a olho, e afirma que um jogo pronto para produção costuma precisar da ordem de cem mil simulações por modo. O lote pequeno é um passo de depuração; o lote grande é o que dá ao otimizador intervalo suficiente de multiplicadores de pagamento e reduz a probabilidade de um jogador receber o mesmo resultado de ronda mais de uma vez.

O que verifica realmente a verificação de formato?

Revê os livros comprimidos e as tabelas de consulta otimizadas antes do upload: os pagamentos têm de coincidir entre os dois ficheiros, e as estatísticas de cada modo — RTP e medidas de volatilidade — são escritas num ficheiro de resumo. Também avisa quando um modo excede os limites de volatilidade verificados para aprovação, e quando os RTP de modos diferentes diferem em mais de cinco por cento.

Pode um protótipo demonstrar que um jogo vai reter jogadores?

Não. Um protótipo não tem jogadores nem dados de sessão, por isso não pode demonstrar retenção. O que pode fazer é enunciar uma hipótese testável sobre o comportamento da mecânica — por exemplo, a frequência com que se entra na função —, e essa frequência pode ser medida após o lançamento. Apresentar um protótipo como evidência de retenção exagera o que o artefacto contém.