Definir um modo bônus personalizado para um slot: o brief antes da arte e da engenharia

Um modo bônus não é uma animação que começa quando caem três símbolos. Na plataforma para a qual este site é construído, ele é uma entrada separada no índice matemático do jogo, com seu próprio nome, seu próprio multiplicador de custo e seus próprios arquivos de lógica de jogo e de tabela de consulta, avaliado como sua própria rodada. O jogador vê um recurso; a plataforma vê um segundo produto com uma segunda economia. O brief precisa descrever esse segundo produto, ou o estúdio construirá a animação e deixará a economia para ser descoberta durante a certificação.

Este artigo apresenta o que um brief de contratação de um modo bônus personalizado para slot precisa resolver antes de a arte e a engenharia começarem: o limite do modo e a decisão do jogador dentro dele, a representação do custo e a participação do modo na matemática, os estados de entrada, saída e erro que o front precisa implementar, e a evidência de aceitação que mantém a versão front entregue e a versão matemática aprovada descrevendo o mesmo jogo. Ele segue as diretrizes de aprovação e o formato de arquivo matemático publicados pela Engine, e assume que o leitor já decidiu contratar um jogo original em vez de comprar um licenciado.

O modo é uma aposta separada com seu próprio custo

O formato de arquivo matemático da Engine é construído em torno de modos. O index.json de um jogo lista cada modo com seu nome, seu multiplicador de custo e os nomes de seus arquivos de lógica de jogo e de tabela de consulta. As regras são explícitas: um jogo precisa ter pelo menos um modo, pode ter no máximo vinte, os nomes dos modos precisam ser únicos ignorando maiúsculas e minúsculas, e o multiplicador de custo precisa ser maior ou igual a 1. Cada modo adicional acrescenta uma tabela de consulta e um arquivo de lógica de jogo, embora os modos possam compartilhar arquivos. O RTP de um modo é seu pagamento esperado dividido por seu custo.

Essa estrutura importa antes de alguém desenhar um símbolo. Um modo bônus pelo qual o jogador paga para entrar é um modo com multiplicador de custo acima de 1, e sua economia é declarada separadamente da do jogo base. Um modo acionado sem pagamento adicional também precisa de seu próprio nome, seu próprio conjunto de resultados e sua própria contabilização, porque seu RTP é medido contra seu próprio custo. O brief não pode descrever o recurso apenas em termos do que o jogador vê na tela; precisa indicar a qual modo do índice o recurso corresponde, qual é seu multiplicador de custo e se entrar nele é uma compra do jogador, um gatilho aleatório ou um evento determinístico.

É também aqui que o brief de contratação se separa da mecânica de compra. Se o modo pode ser comprado diretamente em um determinado mercado é uma decisão de produto separada, com sua própria barreira jurisdicional e obrigações de divulgação, tratada no brief de compra de função. A questão de escopo aqui é mais estreita e anterior: o que é o modo, quanto custa entrar nele e o que o jogador decide quando entra.

A ausência de estado descarta famílias inteiras de design antes da arte

As diretrizes de aprovação da Engine estabelecem que os jogos da Engine são estritamente sem estado: cada aposta precisa ser independente dos resultados anteriores, e os jogos não podem incluir jackpots, recursos de aposta dupla, continuação ou opções de saque antecipado. A restrição não é uma preferência estilística. Ela remove uma família de designs bônus do brief antes de a arte conceitual ser contratada.

Um modo não pode carregar progresso de uma rodada paga para a seguinte. Mecânicas de coleta que pedem ao jogador acumular fichas entre giros, metaprogressão que desbloqueia um modo melhor após várias sessões e estados bônus que persistem depois de fechar uma rodada entram em conflito com o requisito de ausência de estado. Dentro de uma única rodada paga o modo pode conter vários passos, decisões e eventos de resultado — uma sequência de escolha, uma série de giros grátis, um multiplicador que avança — porque esses eventos se resolvem dentro de uma mesma aposta. O que ele não pode fazer é deixar um estado que altere a próxima aposta.

O brief deve enunciar a vida inteira do modo em uma frase: começa quando este evento ocorre, contém estas decisões e eventos de resultado, e termina quando esta condição é satisfeita, sem reter estado depois. Um design que não pode ser enunciado assim ainda não está definido, e o custo de descobrir isso depois de construir o front é um redesenho da máquina de estados, não uma mudança de arte.

Definir a decisão do jogador e o limite do modo

Cada modo deve existir porque o jogador toma uma decisão dentro dele. Em um recurso de escolha, a decisão é qual item revelar. Em uma sequência de giros grátis com multiplicador persistente, a decisão pode ser como usar um número limitado de opções. Em uma roleta ou escada, a decisão é quando parar. O brief deve nomear essa decisão, porque ela determina o que o front precisa apresentar, o que a matemática precisa modelar e o que o texto das regras precisa divulgar.

O limite é o complemento da decisão: o que o modo decide pelo jogador. Resultados aleatórios, o conjunto de escolhas disponíveis e a condição de término pertencem ao lado do modo. Se o brief deixa o limite vago, o front e o modelo matemático farão suposições diferentes sobre quem controla o quê, e a discrepância aparece na certificação como falha de apresentação, não como desacordo de design.

O limite de vinte modos é uma restrição de escopo que pertence à mesma conversa. Um jogo com um modo base e quatro modos bônus usou cinco dos vinte; os quinze restantes não são capacidade livre para preencher depois. A aprovação cobre uma versão front e uma versão matemática revisadas juntas, e as diretrizes são explícitas: uma vez aprovado um jogo, não são permitidas alterações no modelo matemático subjacente, a adição de novos modos de jogo ou modificações nas mecânicas de jogo. Todo modo de que o jogo possa precisar algum dia faz parte da submissão, não de um incremento posterior.

Alinhar a matemática do modo e a apresentação

O formato de arquivo matemático fixa vários detalhes que a apresentação precisa respeitar. Os multiplicadores de pagamento são inteiros em centésimos da aposta base: 100 é um pagamento de 1x e 20 é 0,2x. Eles não são escalonados pelo custo do modo. O RTP de um modo é seu pagamento esperado dividido por seu custo. O arquivo de eventos é o que o RGS devolve ao front quando a rodada é jogada, então a apresentação é construída a partir dos eventos que a matemática realmente emite, não de uma narrativa escrita independentemente deles.

Isso tem uma consequência prática para o brief: a animação e o esquema de eventos do modo precisam ser acordados juntos. Se a matemática emite um evento para cada item revelado em uma sequência de escolha, o front precisa apresentar cada um e distinguir uma revelação que encerra o modo de outra que continua. Se a matemática emite um único evento agregado ao final de uma sequência de giros grátis, o front não pode mostrar resultados por giro que o fluxo de eventos não contém. Decidir a granularidade dos eventos é uma decisão de escopo, não um detalhe de implementação, porque mudá-la depois de a versão matemática ser aprovada é uma alteração no modelo matemático aprovado.

A representação do custo também pertence à apresentação. Um modo com multiplicador de custo acima de 1 precisa mostrar ao jogador quanto custa entrar antes de ele se comprometer. O brief deve especificar onde esse custo é exibido, em que unidade e como é distinguido da aposta base. Também deve especificar como o resultado do modo é apresentado ao final: como multiplicador da aposta base, como retorno total ou como ambos. Essas escolhas afetam o texto das regras e a divulgação do RTP, e são mais baratas de resolver no brief do que em um comentário de revisão.

Especificar os estados de entrada, saída e erro

O front precisa de um modelo de estados para o modo, e o brief deve fornecê-lo. A entrada tem pré-condições: o evento gatilho, saldo suficiente quando o modo tem custo e a disponibilidade do modo no mercado. A saída tem uma condição: a última decisão tomada, o último giro grátis resolvido ou a chamada de fim de rodada emitida. Entre elas o modo pode conter vários passos, e o brief deve indicar o que o jogador pode fazer em cada um.

O formato matemático da Engine dá a cada modo um campo opcional endRound que controla quando uma rodada fecha: no_change fecha automaticamente rodadas com pagamento zero e deixa abertas as rodadas com pagamento até a chamada de fim de rodada, never nunca fecha automaticamente e always fecha todas as rodadas qualquer que seja o pagamento. O brief deve indicar qual comportamento o modo usa, porque determina quando o front precisa oferecer a próxima ação e quando a rodada está completa na perspectiva do jogador. Um modo que deixa aberta uma rodada com pagamento sem uma chamada de fim de rodada se apresenta como um jogo travado.

Os estados de erro fazem parte do mesmo modelo. Um modo que não pode começar porque o saldo é insuficiente para seu custo, um modo desabilitado no mercado atual e um modo cuja chamada de fim de rodada falha precisam de um comportamento definido para o jogador. O brief deve nomear cada um e dizer o que o jogador vê. Não são casos extremos a serem resolvidos por diálogos de erro padrão; são os pontos em que os limites comerciais e regulatórios do modo se tornam visíveis para o jogador.

Acordar a evidência necessária para a aceitação

A evidência de aceitação de um modo bônus não é um vídeo do recurso funcionando. É o conjunto de artefatos que permite a um revisor confirmar que a versão entregue corresponde à descrição aprovada. O brief deve nomeá-los antes de a produção começar: a entrada do modo no índice aprovado com seu multiplicador de custo, a versão matemática e a base de simulação por trás de seu RTP declarado, o esquema de eventos que o front consome, a versão front que será submetida e a evidência de teste de cada estado de entrada, saída e erro.

A Engine revisa uma versão front e uma versão matemática juntas, então as duas precisam ser entregues como um par combinado. Uma versão front que implementa um modo que a matemática aprovada não contém, ou uma versão matemática cujos nomes de eventos diferem dos que o cliente manipula, não é uma pequena discrepância a ser corrigida depois da aprovação: é uma submissão que não pode ser aprovada como apresentada. O brief também deve registrar quem é o responsável pela aceitação no lado do operador e o que essa pessoa vai inspecionar, para que a evidência seja produzida para um leitor e não montada depois do fato.

O que o brief deve registrar

Antes de a arte e a engenharia começarem, o brief deve resolver:

• O lugar do modo no índice: seu nome, seu multiplicador de custo, se compartilha arquivos com outro modo e quantos dos vinte modos disponíveis o jogo usará.
• A decisão do jogador e o limite do modo: o que o jogador escolhe, o que o modo decide e a condição de término.
• O esquema de eventos: o que a matemática emite, com que granularidade e como cada evento mapeia para um estado de apresentação.
• A exibição do custo: onde e como o multiplicador de custo do modo é mostrado, e como é distinguido da aposta base.
• O comportamento de fim de rodada: qual ajuste endRound o modo usa e o que o jogador vê quando a rodada fecha.
• Os estados de erro: saldo insuficiente, indisponibilidade no mercado e falha de fim de rodada, cada um com um comportamento definido para o jogador.
• A evidência de aceitação: a versão front e a versão matemática combinadas, a base de simulação, o esquema de eventos e o responsável de aceitação nomeado.

Nenhum destes é um problema incomum de engenharia. Modos bônus estão em mercados regulados há anos, e um estúdio que constrói jogos da Engine reconhecerá cada pergunta. O que os torna caros quando adiados é que cada um é resolvido em um documento diferente — o índice matemático, o esquema de eventos, o texto das regras, a submissão de certificação — e o brief é o único lugar onde são resolvidos juntos. Chegar a essas respostas antes de a arte começar é o que evita que um modo bônus personalizado se torne um redesenho.

Perguntas frequentes

Quantos modos bônus um jogo da Engine pode conter?

Um jogo precisa conter pelo menos um modo e pode conter no máximo vinte. São feitas exceções para jogos fantásticos, e o Suporte deve ser contatado se forem necessários mais. Cada modo adicional acrescenta uma tabela de consulta e um arquivo de lógica de jogo, embora os modos possam compartilhar arquivos. Os nomes dos modos precisam ser únicos ignorando maiúsculas e minúsculas, e o multiplicador de custo de cada modo precisa ser pelo menos 1.

Um modo bônus pode carregar progresso de um giro pago para o seguinte?

Não. Os jogos da Engine são estritamente sem estado: cada aposta precisa ser independente dos resultados anteriores. Um modo pode conter vários passos, decisões e eventos de resultado dentro de uma única rodada paga, mas não pode deixar um estado que altere a próxima aposta. Mecânicas de coleta, metaprogressão e estados bônus que persistem depois de fechar uma rodada entram em conflito com esse requisito.

O que significa o multiplicador de custo de um modo bônus?

O multiplicador de custo é quanto custa entrar no modo em relação à aposta base. Um modo com multiplicador de custo 1 é acessado com a aposta base; um modo com multiplicador maior é uma entrada paga. Os multiplicadores de pagamento são expressos em centésimos da aposta base e não são escalonados pelo custo do modo. O RTP de um modo é seu pagamento esperado dividido por seu custo, e por isso a economia de cada modo precisa ser declarada separadamente no brief.

Um modo bônus pode ser adicionado depois que o jogo é aprovado?

Não. As diretrizes de aprovação da Engine estabelecem que, uma vez aprovado um jogo para publicação, não são permitidas alterações no modelo matemático subjacente, a adição de novos modos de jogo ou modificações nas mecânicas de jogo; apenas atualizações visuais menores são permitidas, salvo se a equipe da Engine solicitar de outra forma. Todo modo de que o jogo possa precisar deve ser definido e submetido antes da aprovação.