A Morte pelo Escopo: Por que 90% dos Idle Games nunca são lançados (e como blindar isso)
O Sintoma: A Engenharia do Caos
Todo desenvolvedor indie já viveu este ciclo: você tem uma ideia excelente para um Idle Game. Abre a Engine, cria a cena principal, monta o loop básico de clique e recompensa. Em três dias, você tem um protótipo divertido. A empolgação está no pico.
Então, as "boas ideias" começam a surgir.
Você decide que o jogo precisa de um sistema de crafting. Depois, adiciona um sistema de pets para automatizar a coleta. Na semana seguinte, pensa que um sistema de gacha para equipamentos seria perfeito para a retenção. Dois meses depois, o seu Player.gd tem 1.500 linhas de código acoplado, a economia está completamente quebrada e, o pior de tudo: você já não faz ideia de qual é o foco do seu próprio jogo.
O projeto se torna um fardo técnico e morre por exaustão antes mesmo de ver a luz de um lançamento alfa.
O Diagnóstico: A Ausência de Restrições
Quando um projeto chega a esse estado de "código espaguete" e inchaço de funcionalidades (o infame Feature Creep), é comum culparmos a nossa habilidade de programação ou a Engine. Mas o problema não está na Engine.
O erro fundamental é a ausência de restrições de design.
Na engenharia de software tradicional, você não constrói um banco de dados sem antes definir o modelo de negócios. No Game Dev Indie, nós frequentemente começamos a construir sistemas complexos sem um documento central que defina o que o jogo é e, mais importante ainda, o que ele não é.
Sem uma âncora arquitetural, qualquer ideia nova parece uma boa ideia. E quando todas as ideias entram no projeto, nenhuma delas funciona direito. Isso destrói a viabilidade de qualquer produção.
A Engenharia: O High Concept One-Pager
Para eliminar esse gargalo na produção do Apex Hunter, decidi tratar o game design estritamente como engenharia. Pausei o desenvolvimento na Engine e estruturei um framework de documentação no Notion.
A regra número um desse framework é que nenhum script é escrito sem antes passar pelo filtro do High Concept One-Pager.
O One-Pager não é um GDD (Game Design Document) de 50 páginas que ninguém lê. É um documento de uma única tela que atua como um "compilador de ideias". Se uma nova mecânica não compila com as regras desse documento, ela é sumariamente descartada.
Ele é dividido em três pilares técnicos:
- A Promessa Central (The Apex Promise): Qual é a fantasia de poder exata que o jogador está comprando? No caso do Apex Hunter, é a transição de um caçador miserável para uma entidade inalcançável. Toda mecânica, som ou UI deve reforçar essa transição. Se eu quiser adicionar um sistema de pescaria que não colabora com essa promessa, a ideia é vetada antes de virar código.
- Restrições de Design (Design Constraints): Regras rígidas e imutáveis gravadas em pedra. Exemplo prático:
- "O jogador nunca perde recursos acumulados ao morrer."
- "Toda a UI deve refletir o status atual do jogador (Mendigo/Barroso no early game)." Quando você trava essas restrições, as decisões de arquitetura de código (como estruturar os Data Contracts e o save system) tornam-se óbvias e previsíveis.
- O Core Loop Fechado: Uma visualização crua do ciclo infinito do jogador. Exemplo: Combate Automático -> Coleta de Ouro -> Upgrade de Status -> Retorno ao Combate. Se uma feature adicionada cria um desvio que tira o jogador desse loop por mais de 3 minutos, ela é um gargalo de design e deve ser cortada.
O Próximo Passo
A blindagem de escopo através do One-Pager é apenas o primeiro passo da nossa arquitetura. De nada adianta travar a visão do jogo se o fluxo de dados entre as telas ainda for caótico.
Atualmente, estou documentando em público toda a engenharia de sistemas do Apex Hunter e polindo este Framework de Arquitetura completo (estruturado em Notion) para desenvolvedores.
Se você quer acompanhar o desenvolvimento técnico diário, debater arquitetura de sistemas ou ter acesso a esse template de Notion quando eu finalizar a V1, estou documentando tudo no X (Twitter): @ZerionIndie.