O que deve conter um pacote de envio Engine

Um envio ao Engine não é apenas um jogo funcional — é um pacote que uma equipa de revisão pode avaliar sem precisar de pedir elementos em falta. Um envio incompleto não falha imediatamente; fica à espera na fila até que os problemas sejam resolvidos, e essa espera pode prolongar-se de horas para semanas. Preparar o pacote de forma completa antes de fazer o upload é a única decisão que controla a duração da revisão.

Para um estúdio que desenvolve um jogo original ou para um editor que o encomenda, a decisão de preparação acontece antes do fim da produção. O estúdio que chega à etapa de envio com todos os elementos necessários já organizados atinge um estado revisável; o que depende de correções de última hora chega a um atraso.

O requisito de formato de ficheiro estático

Os jogos Engine devem ser enviados como ficheiros estáticos. Todos os resultados possíveis do jogo são armazenados dentro dos ficheiros comprimidos do jogo, normalmente divididos por modo. Cada resultado corresponde a uma linha num CSV que regista uma ronda simulada por número de simulação, probabilidade de seleção e multiplicador de pagamento final. Quando uma ronda começa, a plataforma seleciona um número de simulação de forma proporcional ao seu peso e devolve os eventos correspondentes na resposta da API de jogo.

Os estúdios que trabalham com o SDK do Engine produzem estes ficheiros diretamente: o Framework Matemático gera a configuração do backend, as tabelas de consulta e a saída de simulação a partir de regras do jogo escritas em Python, e o Framework de Frontend — construído em PixieJS e Svelte — lê esses resultados para que o cliente permaneça sincronizado com a matemática. As equipas que utilizam o seu próprio frontend ou stack matemático também podem enviar num formato compatível através do Painel de Controlo de Administração.

O requisito de ficheiro estático existe por razões de verificação, testes e segurança. Um jogo que gera resultados em tempo de execução não pode ser completamente revisto antes de ser lançado; um jogo cujos resultados são pré-computados pode ser auditado em relação às suas regras e documentação matemática de forma completa antes de qualquer jogador o ver.

A descrição do jogo no formulário de envio

O formulário de envio tem um campo de descrição para uma breve apresentação sobre o tema e a mecânica do jogo. Não é um parágrafo de marketing; é a primeira orientação do revisor sobre o que o jogo deve fazer.

Uma descrição útil nomeia o género, a mecânica principal, os modos de bónus se existirem e a direção de volatilidade pretendida. Não precisa de ser longa, mas deve tornar a intenção do jogo inequívoca para alguém que ainda não abriu o cliente. Um revisor que tem de inferir o comportamento pretendido apenas a partir dos ficheiros trabalha mais do que um que pode verificar se os ficheiros correspondem a uma descrição explícita.

O que a revisão avalia

Três revisores independentes são atribuídos a cada envio. Cada revisor classifica o jogo de zero a três estrelas em três dimensões: design, jogabilidade e conformidade matemática. As classificações individuais ficam ocultas até que os três revisores tenham enviado as suas, e a média determina o resultado. Uma média de uma estrela ou superior resulta em aprovação para produção; abaixo de uma estrela resulta em rejeição, com feedback que o estúdio pode abordar antes de reenviar.

A estrutura de três revisores é importante na preparação do envio. Design, jogabilidade e conformidade matemática são avaliações separadas. Um jogo que passa a conformidade matemática mas oferece uma experiência de jogo fraca pode ter uma média abaixo do limiar; um jogo com apresentação visual sólida mas documentação matemática incompleta enfrenta o mesmo risco. Preparar as três dimensões em vez de apenas aquela em que a equipa tem mais confiança é a decisão de preparação.

O Engine comunica o seu raciocínio sobre aprovações e rejeições caso a caso. A plataforma pode solicitar alterações específicas e explicá-las antes de emitir uma decisão final.

Construir o jogo em torno de mecânicas revisáveis

Uma mecânica é revisável quando a sua máquina de estados completa pode ser rastreada do documento de regras através da saída matemática até ao cliente. O revisor deve poder acompanhar o que acontece após um gatilho, através de todos os estados da funcionalidade, até ao resultado final e à sua comunicação ao jogador.

Isto significa definir a condição de entrada de cada modo, todos os caminhos possíveis através da funcionalidade e a condição de saída. Significa acordar o que acontece após uma reconexão e como o jogo comunica o resultado da ronda. Uma mecânica que funciona na prática mas cujos estados não estão documentados deixa o revisor a inferir a correção; uma mecânica documentada cujo cliente corresponde à documentação é verificável.

Para um estúdio que trabalha com o briefing de um editor, o âmbito da mecânica pertence ao briefing escrito antes do início da produção. Chegar ao envio com uma mecânica que o briefing nunca especificou completamente cria rondas de correção que a fase de briefing poderia ter evitado.

Documentação matemática e coerência das regras

A documentação matemática e as regras visíveis para o jogador devem usar o mesmo vocabulário e descrever o mesmo jogo. Um nome de símbolo, uma tabela de prémios ou uma condição de bónus que aparece sob rótulos diferentes no documento matemático e nas regras coloca ao revisor uma questão de coerência a resolver.

O pacote matemático deve nomear cada funcionalidade, descrever como cada resultado é produzido e tornar o valor de retorno teórico rastreável até à simulação. As regras devem descrever cada resultado visível para o jogador e a sua condição de ativação em termos que o jogador possa ler em relação ao que vê no ecrã.

Quando o jogo tem uma compra de bónus ou um estado que um jogador pode entrar diretamente, a documentação deve cobrir esse caminho especificamente, não apenas o fluxo do jogo base.

Preparar o envio antes da fila

Os envios incompletos causam atrasos porque ocupam tempo de revisão sem chegar a uma decisão. Um envio que não cumpre os requisitos quando entra na fila é retido até que os problemas sejam resolvidos, o que pode atrasar a data de lançamento significativamente. A fila de revisão partilhada significa que um envio incompleto afeta o desempenho de outras equipas, e o Engine pode dar menor prioridade a pedidos que chegam sem o pacote esperado.

A abordagem prática de preparação é trabalhar para trás a partir da lista de verificação de envio antes de fazer o upload. Confirmar que os ficheiros estáticos cobrem todos os resultados possíveis, que a descrição é precisa, que a documentação matemática e de regras é coerente e que o cliente corresponde a ambas. Um estúdio que verifica essas condições antes do envio não as descobre como feedback de rejeição.

O serviço de desenvolvimento de jogos Engine da Wizards cobre as linhas de trabalho de produção — matemática, cliente, documentação e apoio à revisão — como um âmbito específico de projeto. Solicite um orçamento de projeto com o seu conceito de jogo, os ativos existentes que tem e a fase de produção a partir da qual precisa de apoio.

Que formato de ficheiro o Engine requer para envios de jogos?

O Engine requer ficheiros estáticos: todos os resultados possíveis do jogo são pré-computados e armazenados em ficheiros comprimidos do jogo, normalmente divididos por modo. Cada resultado mapeia para uma linha CSV que regista um número de simulação, uma probabilidade de seleção e um multiplicador de pagamento. A plataforma seleciona resultados por peso em tempo de execução em vez de os calcular a pedido. As equipas podem produzir estes ficheiros com o SDK do Engine ou enviá-los no formato compatível usando o Painel de Controlo de Administração.

Como funciona o processo de revisão do Engine?

Três revisores independentes são atribuídos a cada envio. Cada um classifica o jogo de zero a três estrelas em design, jogabilidade e conformidade matemática, com as classificações ocultas até que os três tenham enviado as suas. Uma média de uma estrela ou superior significa que o jogo é aprovado para produção; abaixo de uma estrela resulta em rejeição com feedback para reenvio. O Engine comunica o seu raciocínio em cada decisão e pode solicitar alterações específicas antes de emitir um resultado final.

O que causa um atraso num envio ao Engine?

Os envios incompletos são a principal causa de atraso. Um jogo que não cumpre os requisitos quando entra na fila é retido até que os problemas sejam resolvidos, o que pode prolongar a revisão de horas para semanas. A fila de revisão é partilhada entre todas as equipas, pelo que um envio que requer ir e voltar retira tempo de revisão a outros jogos e pode ser dado menor prioridade. Completar o pacote antes de fazer o upload — ficheiros estáticos, descrição do jogo, documentação matemática e regras — é a decisão de preparação que controla a duração da revisão.

O que deve dizer a descrição do jogo no formulário de envio?

A descrição deve cobrir brevemente o tema do jogo, a mecânica principal, os modos de bónus se existirem e a direção de volatilidade pretendida. O seu propósito é dar aos revisores uma declaração inequívoca do que o jogo se destina a fazer, para que possam verificar os ficheiros em relação a uma intenção clara em vez de a inferir. Não é um argumento de marketing; uma declaração breve e precisa da estrutura do jogo é mais útil do que uma promocional.

Como é que encomendar através de um estúdio afeta o envio ao Engine?

Um editor que encomenda um jogo Engine original deve acordar o âmbito do pacote de envio com o estúdio antes do início da produção. O contrato deve nomear a versão do jogo, as regras, a evidência matemática e os registos de QA que o estúdio entregará, identificar quem é proprietário do envio e quem responde ao feedback de revisão, e clarificar o que conta como uma correção de implementação versus um pedido de funcionalidade alterado. A lista de verificação de envio do Engine é a referência da plataforma; o contrato do estúdio deve descrever a sua própria contribuição para esse processo. A aprovação da plataforma, a certificação independente e a permissão para operar num mercado específico são questões separadas da entrega de produção.