Ler uma demo de estúdio: o que um protótipo de slot prova antes de você pedir um orçamento

A primeira coisa que a maioria dos publishers vê de um jogo encomendado é um link. Ele abre um slot jogável numa aba do navegador, gira, paga e parece pronto. Esse link é o artefato sobre o qual uma lista curta costuma ser construída e um orçamento costuma ser pedido, e é rotineiramente lido como mais do que é.

Uma demo de estúdio numa plataforma como a Engine não é um vídeo nem um mock-up. É um front end real carregado de uma URL versionada, conversando com um servidor de jogo remoto numa sessão de dinheiro fictício. Isso a torna evidência genuína para um conjunto de perguntas — se o cliente foi construído corretamente — e nenhuma evidência para outro conjunto, que é se o jogo será certificado, aprovado ou performará.

Este artigo separa os dois. Ele expõe o que uma hora com uma demo pode realmente resolver, o que a mesma demo não pode, e o que um comprador deve pedir ao lado do link para que um orçamento se baseie em algo que sobreviva ao contato com a produção.

O lançamento de uma demo é uma sessão real com um flag alterado

A URL de lançamento documentada da Engine é um conjunto de parâmetros de query que o jogo lê quando carrega: um identificador de sessão, o host do RGS, o idioma, a moeda, a classe de dispositivo, um flag de cassino social e um flag de demo. O flag de demo é documentado como true para um lançamento de dinheiro fictício, e a sessão é autenticada pela mesma chamada de carteira que uma sessão de dinheiro real usa.

Duas consequências decorrem diretamente. A primeira é que o front end que você está clicando é o front end que um operador receberia, apontado para uma sessão de demo em vez de uma carteira de operador. A segunda é que o host do RGS chega como parâmetro e a documentação da plataforma é explícita ao dizer que ele nunca deve ser hardcoded, porque pode mudar a qualquer momento.

Então uma demo é um teste justo do cliente e um teste injusto de tudo por trás dele. O caminho do dinheiro é simulado; a matemática é a configuração que o estúdio publicou para a demo; nada sobre o status de certificação está sendo demonstrado. Ler esses limites corretamente é a maior parte da habilidade.

O que uma hora com a demo resolve

O ciclo de rodada se comporta como o fluxo documentado

O fluxo básico da plataforma é curto: autenticar, fazer uma aposta que abre uma rodada, jogar a rodada, liquidá-la. Uma rodada que não paga nada é fechada pela própria chamada de aposta, com a rodada retornada marcada como inativa, e não há nada a encerrar. Uma rodada com prêmio permanece ativa até que a chamada de fim de rodada a pague. Apenas uma rodada pode estar ativa por vez, e uma segunda aposta enquanto uma está aberta é rejeitada.

Isso dá três observações que um comprador pode fazer em cinco minutos. Um giro perdedor deixa uma rodada aberta para trás? Um giro vencedor liquida através de uma chamada explícita de fim, em vez de silenciosamente? A interface bloqueia uma segunda aposta enquanto uma sequência de feature ainda está rodando? Um cliente que chuta qualquer uma das três vai reconciliar mal contra uma carteira de operador, e a falha aparece como fila de suporte em vez de relatório de bug.

O cliente lê seus parâmetros de lançamento

Abra a demo com a query string visível e verifique o que o build faz com cada parâmetro. A classe de dispositivo é documentada como desktop, mobile ou tablet, e uma demo que só é aberta num desktop não foi exposta ao valor que um operador realmente enviará. O parâmetro de idioma é um código ISO 639-1 que carrega o que o operador enviou, incluindo um valor vazio ou um código fora da lista suportada, com o inglês como fallback documentado.

Esse último ponto decide uma questão específica na fase de orçamento. A lista documentada de idiomas suportados cobre dezessete idiomas; o italiano não está entre eles, e o português está. Um estúdio que diz que o italiano está resolvido porque a plataforma lista idiomas não olhou a lista. Se o texto em italiano existe no build entregue é um item de escopo, não uma suposição.

O caminho de retomada funciona

Desconecte no meio de uma feature, recarregue e veja o que volta. A plataforma registra até onde um jogador assistiu a uma rodada de várias etapas através de uma chamada de bet-event, e a autenticação retorna a rodada inacabada com esse último passo registrado, para que o front end possa retomar a sequência em vez de reiniciá-la. Uma demo que nunca foi interrompida não foi testada no único caminho que gera reclamações.

A camada de exibição aceita dinheiro incomum

Valores no RGS são inteiros com seis casas decimais de precisão, e a moeda afeta apenas a camada de exibição, não a lógica de gameplay. A tabela documentada de moedas mistura moedas de duas casas, moedas de três casas e moedas de zero casas, como o iene e o won. Um build que formata qualquer código que a carteira retorne, sem fallback para um código fora das tabelas do runtime de idioma, quebra no primeiro operador cuja moeda é incomum — e uma demo que só renderizou euros não lhe mostrou o fallback.

A escada de apostas é o mesmo tipo de observação. Aposta mínima, aposta máxima e passo são retornados na autenticação, e a plataforma recomenda denominações-base pequenas. Se a escada, os multiplicadores de custo de cada modo de aposta e a precisão de exibição de prêmio não concordam entre si, os tamanhos de moeda da demo são decoração em vez de plano.

A superfície de ajuda existe antes do primeiro giro

A demo também é o lugar mais barato para verificar a superfície de divulgação. Na Grã-Bretanha, os padrões técnicos remotos exigem que uma explicação das regras aplicáveis esteja facilmente disponível antes de o cliente se comprometer a jogar, informação que razoavelmente lhes permita entender o estado atual de um jogo multiestado, informação suficiente para julgar as chances de ganhar, incluindo a vantagem da casa ou o retorno ao jogador, e os prêmios potenciais ou os meios pelos quais são calculados. Em Portugal, o quadro correspondente exige que os jogos de demonstração tenham as mesmas características do jogo de dinheiro real e apresentem a chance de ganhar corretamente e em equilíbrio.

Uma demo cuja tela de ajuda é um stub está lhe dizendo algo sobre o build, não sobre o mercado. As regras do mercado estão resumidas no nosso guia de evidência de certificação localizada, e a regra portuguesa de demonstração no conjunto de requisitos de Portugal.

O que a demo deve divulgar, e o que perguntar se não divulgar

Os padrões técnicos remotos do GB tratam os jogos gratuitos como uma superfície de justiça em vez de uma superfície de marketing. Jogos gratuitos devem implementar as mesmas regras que os jogos correspondentes de dinheiro real oferecidos nas mesmas instalações, e os operadores devem tomar todas as medidas razoáveis para garantir que os jogos gratuitos representem com precisão a probabilidade de ganhar e a distribuição de prêmios do jogo de dinheiro real. A orientação de implementação acrescenta que o jogo gratuito deve usar o mesmo gerador de números aleatórios que o jogo de dinheiro real, ou outro que atenda aos requisitos dos próprios padrões, ou um gerador publicamente disponível sem viés sistemático.

A mesma orientação então aborda o caso que um publisher tem mais chance de encontrar durante a aquisição: quando um site não-consumidor — o próprio site de um fornecedor, por exemplo — demonstra um jogo com retornos acima do normal, deve ficar claro que se trata de um jogo de demonstração especificamente projetado para demonstrar as features de bônus.

Essa é a pergunta a fazer a qualquer estúdio cuja demo pagou generosamente. Este build de demonstração está configurado para mostrar features, ou é a configuração de entrega? Uma demo de fornecedor com retornos elevados não é automaticamente um problema; uma não explicada é, no mercado que escreveu a regra, e uma base ruim de avaliação em qualquer lugar. Peça a resposta por escrito, junto com o retorno ao jogador com que a demo foi configurada.

O que a demo não pode resolver

Aprovação. Uma revisão de plataforma se anexa a uma versão de front submetida e a uma versão de matemática submetida, como um par. Uma URL de demo não é esse par, e uma sessão de demo limpa não é um resultado de revisão. O caminho de avaliação para um build existente e o guia do pacote de submissão cobrem o que uma revisão realmente examina.

A matemática. Uma sessão de demo é uma amostra, e uma amostra não pode estabelecer um retorno ao jogador. O artefato que pode é um par sheet com evidência de simulação, que é um documento que você solicita em vez de uma coisa que você joga — o guia do modelo matemático expõe o que deve estar nele, e o guia de paridade cobre a questão separada de se o cliente apresenta os resultados acordados.

Originalidade e proveniência. Você pode ver a arte. Você não pode ver a posição de licença de uma fonte, de uma biblioteca de som ou de um conjunto de símbolos a partir de uma aba do navegador, e uma demo é um lugar comum para encontrar assets provisórios que não sobreviverão à produção.

Comportamento em escala de portfólio. Carregamento, memória e comportamento térmico em um catálogo é um programa de testes, não uma primeira impressão.

O código que você receberia. Uma demo prova que um build roda; não prova que o repositório entregue, os scripts de build e o código-fonte da versão que você jogou são os mesmos objetos.

A folha de observação

Oito observações, cada uma registrada como vista ou não vista, em vez de como uma nota de zero a dez:

1. A query string com que a demo foi lançada, e se o build lê o host do RGS a partir dela.
2. O que uma rodada perdedora retornou, e se uma rodada ativa ficou aberta.
3. O que uma rodada vencedora fez antes e depois da liquidação.
4. Se uma segunda aposta foi aceita enquanto uma sequência de feature estava rodando.
5. O que voltou depois de um recarregamento no meio de uma feature, e se a sequência retomou no passo registrado.
6. Se a superfície de ajuda estava acessível antes da primeira aposta, e se ela declarava regras, estado atual, chances de ganhar e prêmios.
7. As moedas e faixas de aposta que uma sessão de operador retornou, e a contagem de casas decimais renderizada para cada uma.
8. A classe de dispositivo sob a qual a demo foi aberta, e uma repetição num celular se a demo é voltada para mobile.

Depois, as perguntas, que importam mais que a folha: que versão é esta, que configuração de matemática está rodando, é um build de demonstração de features, para quais mercados se destina, e o que mudaria entre este build e o entregue.

O que pedir ao lado do link

Uma demo mais cinco documentos tornam um orçamento defensável. A demo, como acima. O par sheet que o build deve implementar. Os identificadores de versão para o front end e a matemática, para que “a demo” tenha um nome. Uma declaração de quais assets são protótipo e quais são finais. O conjunto de mercados pretendidos, porque decide quais superfícies de divulgação e certificação estão no escopo — o guia de submissão é o mapa para esse trabalho. E o alvo de integração, já que um cliente que nunca leu um parâmetro de lançamento é um projeto de portabilidade em vez de uma entrega.

Nada disso substitui o trabalho de aceitação que segue um contrato, e nada disso prevê uma aprovação. É a diferença entre uma lista curta construída sobre um build e uma lista curta construída sobre uma primeira impressão.

Se você está preparando um briefing e quer que a demo, a evidência matemática e o conjunto de mercados sejam avaliados juntos, solicite um orçamento de projeto. O guia de contratação cobre como esse briefing é montado, e os critérios de aceitação de front end pegam onde a revisão da demo para.

Perguntas que compradores fazem

Uma demo que joga bem significa que o jogo será aprovado?

Não. Uma revisão de plataforma se anexa a uma versão de front submetida e a uma versão de matemática submetida como um par, e uma URL de demo não é nenhuma das duas. Uma sessão de demo limpa mostra que um cliente roda e que seu ciclo de rodada se comporta como documentado; ela não diz nada sobre o resultado da revisão, a posição de certificação ou a configuração matemática final.

Por que a demo de um estúdio pagaria mais que o jogo real?

Porque uma demo de fornecedor costuma ser configurada para mostrar features de bônus em vez de representar o retorno de entrega. Os padrões técnicos remotos da Grã-Bretanha exigem que os jogos gratuitos implementem as mesmas regras que o jogo correspondente de dinheiro real e representem a probabilidade de ganhar com precisão, e sua orientação de implementação diz que, quando um site não-consumidor demonstra um jogo com retornos acima do normal, deve ficar claro que é um jogo de demonstração projetado para demonstrar as features de bônus. Pergunte qual configuração você está jogando.

Posso julgar o retorno ao jogador a partir de uma sessão de demo?

Não. Uma sessão é uma amostra, e o retorno ao jogador é uma propriedade do modelo matemático, estabelecida por evidência de simulação. Os artefatos a solicitar são o par sheet e o relatório de simulação para a versão em consideração — a demo só lhe diz o que o cliente faz com os resultados que recebe.

O que devo verificar num celular em vez de num desktop?

A classe de dispositivo que o lançamento envia, porque os valores documentados são desktop, mobile e tablet e um build pode se comportar de forma diferente em cada um; os alvos de toque nos controles de aposta e giro; a legibilidade do conjunto de símbolos e da apresentação de prêmio no tamanho menor; e se uma feature interrompida retoma quando a aba do navegador é descartada e reaberta.

A demo de um estúdio é a mesma coisa que um protótipo de mecânica?

Não. Um protótipo existe para provar que uma mecânica é compreensível e vale a pena produzir, geralmente antes da arte final. Uma demo é um front end versionado servido pela plataforma, com idioma, moeda, classe de dispositivo e flag de demo fornecidos no lançamento. O portão de protótipo é a decisão anterior; esta é sobre o build.