Contratar um estúdio para terminar um jogo de Engine já iniciado: o que avaliar primeiro

Um jogo que precisa de ser terminado chega como uma pasta e um acesso, não como um plano. O briefing diz que está oitenta por cento feito. A compilação abre. Alguns modos funcionam, outros falham. Os ficheiros de matemática estão algures, o acesso ao repositório do estúdio anterior é do operador se o contrato o disser, e ninguém consegue afirmar que versão a plataforma já viu.

É nesse momento que se toma a decisão de retomar o projeto, e normalmente toma-se mal, porque a pergunta é formulada como «quanto falta». A pergunta melhor é «qual é a base». Um jogo de Engine não é um artefacto único que um segundo estúdio continua; é uma versão de cliente e uma versão de matemática que foram revistas em conjunto, mais as regras, os textos e os recursos que as descrevem. Até saber qual dessas peças a plataforma aprovou, «oitenta por cento feito» é uma sensação, não uma medida.

Este artigo expõe o que fixar antes de acordar um âmbito de retoma e como classificar o trabalho pendente em defeitos herdados, âmbito inacabado e âmbito novo. Os três orçamentam-se, planeiam-se e revêem-se de forma diferente, e confundi-los é como uma retoma se transforma numa reescrita com a data original ainda em cima.

## A aprovação está ligada a um par, não a um projeto

As diretrizes de aprovação da Engine dizem-no com clareza: cada pedido de aprovação cobre uma versão de cliente e uma versão de matemática, revistas em conjunto. A revisão examina funcionalidade, clareza, comunicação e desempenho técnico, e a Engine comunica os problemas e o seu raciocínio caso a caso. A aprovação fica ao critério do revisor, o que descreve o processo e não o teu jogo.

Para uma retoma, essa única frase reorganiza toda a avaliação. Não existe «o jogo aprovado» em abstrato. Existe um par aprovado, com uma versão de cliente e uma de matemática, e a compilação que tens na pasta é esse par ou não é.

A regra seguinte importa tanto. Uma vez aprovado um jogo para publicação, a orientação publicada permite apenas atualizações menores que corrijam questões visuais, salvo se a equipa da Engine indicar outra coisa; alterações ao modelo matemático, novos modos de jogo e modificações de mecânicas não são permitidas. Lidas em conjunto, as duas regras definem a restrição real da retoma: o trabalho adicional que compras tem de ser classificado antes de ser orçamentado, porque grande parte do que um operador entende por terminar pode não estar permitida sobre o par aprovado.

O que a plataforma não te vai deixar terminar

Parte do trabalho descrito num briefing não pode ser entregue nesta plataforma, seja qual for o estúdio. Descobri-lo depois de assinar é caro e evita-se numa hora de leitura.

Os jogos da Engine são estritamente sem estado. Cada aposta tem de ser independente dos resultados anteriores, e as restrições publicadas excluem jackpots, funções de dobrar, continuação e levantamento antecipado. Um briefing que herda um jackpot comunitário, uma ronda de dobrar ou um respin que guarda estado entre apostas não é um trabalho de acabamento; é um jogo que tem de ser redesenhado antes de poder ser submetido.

As regras de originalidade são igualmente concretas. Nomes de equipa, títulos e recursos têm de cumprir a lei de propriedade intelectual e direitos de autor, e a infração é motivo de rejeição. Os jogos têm de ser desenhos originais, e jogos comprados ou licenciados que já existem noutros sites de terceiros não são permitidos. Os recursos não podem incluir a marca ou os temas da Stake. Um jogo pode ter no máximo 20 modos, com exceções tratadas pelo suporte.

Uma compilação herdada pode falhar qualquer destes pontos antes de se escrever uma linha de código novo, e nenhum deles é questão de gosto. O teste prático é uma lista, não uma opinião: conta os modos, lê o título e a proveniência dos recursos, e verifica se alguma mecânica depende de um estado que o modelo da plataforma não guarda.

A matemática é o jogo e tem de se reproduzir

Cada jogo da Engine é um conjunto de ficheiros estáticos carregados em duas partes. A parte de matemática contém todos os resultados possíveis, gerados antecipadamente e comprimidos por modo; cada resultado é uma linha de um CSV com um número de simulação, a sua probabilidade de seleção e o multiplicador de pagamento final. Quando um jogador aposta, o RGS escolhe um número de simulação em proporção ao seu peso, devolve os eventos desse resultado e o cliente reprodu-los.

Essa arquitetura é o que torna uma retoma avaliável e também o que a torna perigosa quando é feita sem cuidado. Os resultados são dados, pelo que a tarefa do cliente é a apresentação, e o cliente pode ser substituído sem tocar na matemática. Mas a matemática também é o produto: o retorno, a volatilidade, o ganho máximo e a frequência de cada função já estão codificados em ficheiros. Um estúdio que aceita um modelo matemático sem o regenerar a partir da fonte aceita números que não consegue defender.

O segundo ponto da avaliação é, portanto, a reprodutibilidade. Se a fonte de matemática existir, deve regenerar os ficheiros publicados e a saída deve coincidir com o que está na pasta. Se não existir, quem constrói adota um conjunto de dados fixo e qualquer alteração futura será um modelo novo, não uma edição. Ambas são posições legítimas; só uma costuma ser o que o operador pensa estar a comprar.

Ler o cliente como um revisor o lê

O cliente é onde uma retoma encontra a maioria dos seus defeitos, porque é a peça que toca a plataforma de formas que uma demo nunca mostra. A Engine publica a lista de verificação que usa nas revisões, e essa lista serve como guião de avaliação de uma compilação herdada.

Os níveis de aposta devem vir da resposta de autenticação, não de uma escada codificada. Uma ronda ativa tem de ser recuperada com a aposta original após uma reconexão. Uma ronda que não paga nada não deve ser fechada com uma chamada de fim de ronda, e não se deve enviar um pedido de jogo quando o saldo é insuficiente. A apresentação da moeda tem de cobrir símbolos, decimais e colocação, incluindo pagamentos abaixo do cêntimo.

Há mais do mesmo nas orientações de cliente e de regras: barra de espaço para apostar, sem deslocamento da página, som desligado em todo o lado, quatro tamanhos de ecrã de revisão, RTP e ganho máximo indicados por modo, pagamentos de símbolos e combinações que coincidam com a matemática, cada controlo explicado e uma alternativa para códigos de idioma não suportados.

É aqui que uma retoma se separa de um novo projeto. Um projeto novo pode ser escrito contra estes requisitos desde o primeiro commit. Uma compilação herdada tem de ser medida contra eles, e essa medição é o entregável que decide o âmbito.

Usa a revisão que a própria plataforma publica

A Engine publica uma revisão em forma de ficheiro Markdown que um agente de código executa dentro da pasta do jogo. É apenas de leitura até pedires correções. Mapeia o framework e a compilação, encontra onde são lidos os parâmetros de lançamento, enumera cada chamada ao RGS e de onde vêm os níveis de aposta, recolhe os textos visíveis e lê os ficheiros de matemática se estiverem presentes.

Com um URL de sessão do painel do Studio, ou com um RGS simulado, também pode abrir o jogo num navegador sem interface e reproduzir o que os revisores testam: níveis de aposta reescritos, uma ronda interrompida, saldo zero, um rgs_url inválido e os quatro tamanhos de ecrã de revisão. Cada diretriz recebe um veredicto — PASS, FAIL, AT RISK, NEEDS A HUMAN ou N/A — e os achados levam os identificadores da lista de verificação de submissão, para que o mesmo vocabulário sobreviva à correspondência com a revisão.

Dois limites devem ser ditos. A execução acontece na tua máquina, com o teu fornecedor de modelo, e nada é enviado para a Engine. E um relatório limpo não é uma aprovação: os revisores continuam a jogar cada submissão e julgam originalidade, qualidade e sensação de jogo. O que a revisão dá a uma retoma é algo mais estreito e mais útil: uma lista partilhada e detalhada do que a compilação herdada faz e não faz, produzida antes de alguém pôr um preço.

Classificar o trabalho restante em três grupos

Com o par aprovado identificado, a matemática reproduzida e o cliente medido, o trabalho restante cai em três grupos que um briefing deve manter separados.

Defeitos herdados. A compilação não cumpre a base aprovada ou falha um requisito que o revisor levantaria. São correções sobre algo já acordado. Pertencem ao âmbito da retoma com a evidência da avaliação anexada, e são a parte do trabalho que um âmbito fechado consegue orçamentar.

Âmbito inacabado. O briefing anterior prometia-o e a compilação não o faz. Aqui a classificação é decisiva: se o trabalho em falta toca o modelo matemático, acrescenta um modo ou modifica mecânicas, o par aprovado não pode simplesmente ser ampliado. Precisa de uma nova submissão, com a revisão que a acompanha. Se for uma correção visual, a orientação publicada é mais permissiva. O grupo, não o esforço, determina o processo.

Âmbito novo. O operador mudou de ideias, ou o mercado mudou. É um novo projeto dentro de uma base de código existente e deve ser orçamentado como tal, não absorvido numa linha de «terminar».

O valor dos três grupos é que se comprovam com evidência em vez de se discutirem de memória. Um defeito tem um teste falhado associado. Um item inacabado tem uma linha no briefing anterior. Um item novo tem data de decisão e responsável.

O que o briefing de retoma deve conter

Um briefing que permite comparar orçamentos contém seis coisas.

Uma declaração de base. Que versão de cliente e que versão de matemática a plataforma aprovou, e se a compilação em mão é esse par. Se a resposta for desconhecida, o primeiro entregável é estabelecê-la, não terminar nada.

O conjunto de evidência. A execução da revisão, os ficheiros de matemática reproduzidos e a contagem de modos, anexados em vez de resumidos.

O registo dos três grupos. Cada item restante classificado, com a sua evidência e a sua consequência de processo: correção, âmbito inacabado ou nova submissão.

A posição de propriedade e acesso. Quem detém o código-fonte, quem detém o acesso ao Studio e o que acontece a ambos na entrega. A questão separada de quem é dono do código e da arte encomendados merece ser resolvida na mesma conversa e não depois.

A definição de aceitação. O que significa «terminado» em relação ao par: que verificações passam, que ecrãs coincidem com as regras e quem responde ao feedback de revisão quando chega.

As perguntas abertas. Os pontos que a avaliação não conseguiu resolver, enumerados em vez de assumidos. Um briefing de retoma sem perguntas abertas costuma ser um briefing escrito a partir do resumo do estúdio cessante.

Nada disto garante a aprovação e nada substitui a certificação num mercado onde o jogo venha a ser oferecido. Faz algo mais modesto e mais valioso: transforma uma pasta herdada num âmbito que pode ser orçamentado, planeado e revisto sem que as partes descubram a classificação do trabalho depois da fatura.

Se estás a decidir se terminas uma base existente ou encomendas uma nova, o serviço de desenvolvimento de jogos Engine cobre a avaliação e a produção como um âmbito por projeto. Pede um orçamento de projeto com o estado atual da compilação, a situação de aprovação que consigas comprovar e os modos que pretendes lançar. Os requisitos de submissão estão descritos em o que incluir num pacote de envio Engine, as regras de alteração após aprovação estão em o que muda depois de um jogo ser aprovado e a verificação de que o cliente continua a apresentar os resultados acordados está em o guia de paridade entre matemática e cliente.

Perguntas frequentes

Pode um segundo estúdio terminar um jogo que o primeiro já submeteu?

Pode, mas a aprovação está ligada a um par: cada pedido cobre uma versão de cliente e uma de matemática revistas em conjunto. Um segundo estúdio tem de estabelecer que par foi aprovado, se a compilação que recebeu é esse par e se o trabalho restante é uma correção visual ou uma alteração de matemática, modos ou mecânicas. A última categoria não pode ser acrescentada a um par aprovado; exige uma nova submissão.

Uma compilação terminada precisa de nova revisão se a matemática não mudar?

A orientação publicada diz que, uma vez aprovado um jogo para publicação, só são permitidas atualizações menores que corrijam questões visuais, salvo se a equipa da Engine indicar outra coisa. Alterações ao modelo matemático, novos modos e modificações de mecânicas não são permitidas. O que continua permitido é estreito, e vale confirmar a alteração concreta com a Engine em vez de a deduzir deste resumo.

O que deve ser avaliado antes de acordar o âmbito de uma retoma?

Cinco coisas: que versões de cliente e de matemática estão aprovadas, se a fonte de matemática reproduz os ficheiros publicados, como o cliente trata os parâmetros de lançamento, os níveis de aposta, a recuperação de uma ronda ativa, as rondas sem prémio e o saldo insuficiente, o que as regras indicam sobre RTP e ganho máximo por modo, e se alguma função herdada — um jackpot, uma ronda de dobrar, uma continuação — está excluída pelo requisito de ausência de estado.

Uma revisão automatizada limpa equivale a uma aprovação?

Não. A revisão publicada corre localmente contra as diretrizes de aprovação e reporta cada uma com evidência e uma correção, mas a Engine afirma que um relatório limpo não é uma aprovação. Os revisores continuam a jogar cada submissão e julgam a originalidade, a qualidade e a sensação de jogo. O relatório é um contributo para a avaliação, não uma decisão.

Que ficheiros deve receber o estúdio entrante?

No mínimo, o código-fonte do cliente e a sua compilação, a fonte de matemática e os ficheiros de publicação que gera, o texto de regras e tabela de pagamentos, as tabelas de textos, as fontes dos recursos com a sua proveniência, a lista de modos e a correspondência de aprovação do par atual. Sem a fonte de matemática, o estúdio adota um conjunto de dados fixo em vez de manter um modelo, e o briefing deve dizê-lo explicitamente.