O que pode mudar depois que um jogo da Engine é aprovado? Brief de escopo pós-lançamento

Uma aprovação costuma ser tratada como a linha de chegada de um projeto de jogo. Na Engine, ela funciona mais como um bloqueio de versão. O envio que vai para revisão não é a ideia, a direção de arte ou o tema; é um build de front e um build de matemática, inspecionados juntos como um único objeto. Depois que esse objeto é aprovado, a pergunta comercial deixa de ser “o que mais este jogo poderia fazer?” e passa a ser “o que ainda pode ser mudado sem quebrar o par aprovado?”

Este artigo expõe como as diretrizes de aprovação da Engine definem essa fronteira: o par de versões que é de fato aprovado, a única categoria de mudança pós-lançamento que as diretrizes permitem, as três categorias que elas excluem, por que o formato do arquivo de matemática torna essas exclusões estruturais e não burocráticas, e como uma publisher deve delimitar o roteiro de atualizações de um título antes que o build seja bloqueado. O texto parte do princípio de que o leitor já decidiu encomendar um jogo original da Engine em vez de comprar um licenciado.

A aprovação cobre, juntos, um build de front e uma versão de matemática

As diretrizes de aprovação da Engine são explícitas sobre o que um pedido de revisão contém: cada pedido cobre uma versão de front e uma versão de matemática, revisadas juntas. A equipe inspeciona o jogo quanto a funcionalidade, clareza, comunicação e desempenho técnico. O campo de descrição no formulário de envio fornece um breve resumo sobre o tema e as mecânicas, que pode ser usado em material promocional e na tag de descrição do jogo.

Essa estrutura tem uma consequência prática para o brief e para o handoff. O objeto aprovado é um par de identidades de build, não uma permissão geral para operar um jogo. A publisher deve registrar qual build de front e qual versão de matemática foram revisados, manter esses artefatos arquivados e imutáveis e tratar o par como ponto de referência para toda mudança posterior. Se qualquer lado do par se mover, o objeto aprovado deixa de existir na forma que foi inspecionada.

As diretrizes também orientam quem envia a garantir que o jogo esteja finalizado e pronto para publicação no momento do pedido. A aprovação não é um ambiente de staging para design iterativo. Uma equipe que envia cedo, planejando corrigir a matemática ou adicionar um modo depois do lançamento, está tratando a revisão como um checkpoint de design; as diretrizes a tratam como um portão de publicação.

O que a regra pós-lançamento permite e o que exclui

A regra pós-lançamento é curta. Depois que um jogo é aprovado para publicação na Stake ou na Stake.us, só são permitidas atualizações menores para corrigir problemas visuais, a menos que a equipe da Engine solicite o contrário. Mudanças no modelo matemático subjacente, o acréscimo de novos modos de jogo ou modificações nas mecânicas de gameplay não serão permitidos.

Leia isso como uma permissão estreita e três exclusões nomeadas:

• Permitido: atualizações menores que corrigem problemas visuais.
• Excluído: mudanças no modelo matemático subjacente.
• Excluído: o acréscimo de novos modos de jogo.
• Excluído: modificações nas mecânicas de gameplay.

A distinção entre uma correção visual e um recurso visual importa. Corrigir um asset quebrado, um rótulo ilegível ou um defeito de layout é o tipo de mudança que a frase descreve. Substituir o conjunto de símbolos, adicionar uma introdução animada ou redesenhar a apresentação de um recurso é uma mudança visual de outra ordem, e pode alterar o que o jogo comunica. Como a revisão cobre clareza e comunicação além de funcionalidade, uma mudança de texto ou de apresentação que afete o que é dito ao jogador deve ser levada ao suporte da Engine antes de ir ao ar, em vez de presumida como cosmética.

A mesma cautela vale para textos de regras e traduções. Corrigir um erro de digitação é uma coisa; uma regra alterada, uma qualificação alterada ou uma nova alegação localizada é outra. São questões a resolver antes do envio, não depois.

Por que o modelo matemático fica dentro da fronteira

As exclusões não são arbitrárias. Elas decorrem de como um jogo da Engine é montado. O formato de arquivo de matemática da Engine descreve um jogo por meio de um arquivo de índice que 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. Os multiplicadores de pagamento na tabela de consulta CSV devem corresponder exatamente aos valores da lógica do jogo, porque esses valores são hasheados durante a verificação. A própria lógica do jogo é JSON-lines comprimido, em que cada rodada carrega um id, uma lista de eventos e um payoutMultiplier.

Uma mudança de matemática, portanto, não é uma edição de texto em um documento que o revisor leu. É uma mudança na evidência hasheada que foi revisada. Um novo modo é pior que isso: ele adiciona uma entrada de índice, uma tabela de consulta e um arquivo de lógica de jogo, e o índice aprovado deixa de descrever o produto. É por isso que “mudanças no modelo matemático e novos modos” não podem ser liberados como atualizações menores — a aprovação foi concedida a um índice específico e a um conjunto específico de hashes.

O requisito de ausência de estado reforça a mesma fronteira. Jogos da Engine são estritamente sem estado: cada aposta deve ser independente dos resultados anteriores, e os jogos não podem incluir jackpots, recursos de gamble, continuação ou opções de saque antecipado. Um design que depende de progresso carregado entre rodadas está fora do modelo aprovado, e nenhum patch pós-lançamento pode torná-lo compatível. A restrição pertence ao brief, antes da arte e da engenharia, não a um ticket de suporte depois do lançamento.

Há também um teto com o qual planejar. Um jogo pode ter no máximo vinte modos, com exceções para jogos fantásticos tratadas pelo Suporte. Como os modos não podem ser adicionados após a aprovação, o índice inicial precisa conter todos os modos que o título possa precisar ao longo de sua vida comercial. O limite de vinte modos não é apenas um máximo técnico; é um prazo de escopo.

Trate o primeiro envio como toda a vida comercial do título

A conclusão prática é desconfortável para equipes acostumadas ao pensamento de live service. Se a matemática, o conjunto de modos e as mecânicas ficam congelados na aprovação, então o primeiro envio não é a versão um de um produto em evolução. É o produto. Eventos sazonais, novos modos de bônus, variantes de mecânica e atualizações estruturais não podem ser aplicados por patch em um build aprovado; cada um vira um novo envio ou um título separado.

Isso não significa que o jogo não possa ser melhorado. Significa que a melhoria precisa ser planejada dentro do envelope aprovado. Polimento de arte, correções de apresentação, melhorias de clareza e correções visuais continuam disponíveis. Qualquer coisa que altere a economia, o conjunto de resultados ou o espaço de decisão do jogador, não. Um roteiro que assume o contrário não é um roteiro; é uma lista de envios futuros que nunca foram delimitados ou orçados.

O brief deve, portanto, separar dois tipos de mudança planejada antes do bloqueio de arte. O primeiro é a manutenção visual: correções e polimento que podem ir ao ar dentro do par aprovado. O segundo é a evolução estrutural: modos, matemática ou mecânicas que exigiriam uma nova aprovação. Itens estruturais pertencem ao primeiro envio ou a um plano de sequência, não a um backlog pós-lançamento. O brief do pacote de envio cobre o que a revisão inicial precisa, e o brief de escopo do modo bônus cobre como definir uma fronteira de modo antes de a engenharia começar.

Perguntas a resolver antes do pedido de aprovação

• O par de versões: o build de front e a versão de matemática exatos que serão enviados, e onde ambos estão arquivados.
• A lista completa de modos: cada modo que o título possa precisar, cada um com seu nome, multiplicador de custo e conjunto de arquivos, dentro do limite de vinte modos.
• O roteiro estrutural: quais atualizações planejadas mudam matemática, modos ou mecânicas e, portanto, não podem ser patches pós-lançamento.
• A lista apenas visual: as correções e o polimento que continuam permitidos após a aprovação.
• O estado de regras e localização: texto final de regras e traduções finais, com qualquer mudança que afete a comunicação levantada antes do envio.
• O responsável pela aceitação: quem aprova que as versões de front e de matemática enviadas descrevem o mesmo jogo.

Nenhuma dessas é uma pergunta de produção incomum. O que as torna caras quando adiadas é que a aprovação as responde uma vez, em conjunto, e não as reabre depois. Uma equipe que as resolve antes do bloqueio de arte obtém uma aprovação limpa e um plano de atualização realista; uma equipe que as deixa para o lançamento descobre que seu roteiro exige novos envios que nunca delimitou. Um estúdio que desenvolve jogos da Engine reconhecerá a sequência. O brief é onde ela se torna acessível.

Perguntas frequentes

Quais mudanças são permitidas depois que um jogo da Engine é aprovado?

As diretrizes de aprovação da Engine permitem, após a aprovação, apenas atualizações menores que corrijam problemas visuais, a menos que a equipe da Engine solicite o contrário. Mudanças no modelo matemático subjacente, o acréscimo de novos modos de jogo e modificações nas mecânicas de gameplay não são permitidas. A categoria permitida é estreita por design, porque a revisão cobre uma versão de front e uma versão de matemática como um par.

Um novo modo de bônus pode ser adicionado após a aprovação?

Não. Adicionar um modo significa adicionar uma entrada de índice, uma tabela de consulta e um arquivo de lógica de jogo, de modo que o índice aprovado deixaria de descrever o produto. Todo modo que o título possa precisar deve ser delimitado e enviado antes da aprovação. O teto de vinte modos transforma essa decisão em uma restrição de planejamento, não em uma opção posterior.

Uma mudança apenas na matemática exige um novo envio?

Sim. Um pedido de aprovação cobre uma versão de front e uma versão de matemática revisadas juntas, e os multiplicadores de pagamento na tabela de consulta são hasheados durante a verificação. Mudar o modelo matemático quebra o par revisado e fica fora da permissão pós-lançamento. Planeje a matemática antes do envio em vez de tratá-la como um ajuste de lançamento.

Um texto de regras ou uma tradução pode ser corrigido após a aprovação?

As diretrizes nomeiam as atualizações visuais menores como a categoria permitida, e a revisão cobre clareza e comunicação além de funcionalidade. Uma simples correção de erro de digitação é diferente de uma regra alterada, uma qualificação alterada ou uma nova alegação localizada. Leve mudanças de texto, regras e tradução ao suporte da Engine antes de publicar, em vez de presumi-las cosméticas.