Neste post
O estúdio é de Flutter. Quatro dos cinco jogos são Flutter, o restante do portfólio é Flutter, e a padronização é deliberada — o post Oito apps publicados, uma stack só explica por quê.
O Troll Quest BR é Godot 4.3, em GDScript.
Este post é sobre o que justifica quebrar a própria regra.
O que o jogo é
Platformer 2.5D mobile-first, no espírito dos jogos de armadilha injusta — onde a graça é justamente o bloco que cai onde você não esperava. Onze fases jogáveis em dois mundos, chefe na fase 10 e uma fase bônus.
A palavra que decide tudo nessa descrição é fases.
O critério: quem desenha a fase?
Em Flame ou widget puro o critério era se o estado muda por frame ou por evento. Aqui há um terceiro degrau, e ele não é sobre renderização:
O conteúdo do jogo é desenhado ou é gerado?
Jogo com conteúdo gerado — endless, procedural, aleatório — não precisa de editor. As regras produzem o conteúdo, e o trabalho é ajustar as regras.
Jogo com conteúdo desenhado precisa de alguém posicionando cada elemento. E posicionamento é trabalho visual e iterativo: você move a armadilha dois blocos para a direita, testa, move de volta, testa de novo. Cinquenta vezes por fase.
| Conteúdo | Ferramenta necessária |
|---|---|
| Gerado por regra | biblioteca de renderização |
| Desenhado à mão | editor de cena com visualização |
Sem editor, cada ajuste de posição é: alterar código, recompilar, abrir o jogo, jogar até a fase, ver o resultado. Com editor, é arrastar e ver. Numa fase de platformer isso acontece centenas de vezes — a diferença não é conveniência, é viabilidade.
O que o Godot dá que faltava
Editor de cena. Posicionar plataforma, armadilha e inimigo visualmente, com o jogo rodando ao lado. É a razão principal.
Tilemap. Construir cenário com paleta de blocos, com colisão vindo junto. Reimplementar isso é semanas.
Física com corpos. Personagem que cai, escorrega, empurra e colide com material tem comportamento que ninguém quer escrever à mão — e que precisa ser consistente entre onze fases.
Árvore de nós com herança de cena. Uma armadilha vira cena reutilizável; mudar a cena base atualiza todas as instâncias em todas as fases. Isso é o que torna ajuste tardio possível.
Iteração rápida. GDScript recarrega e o jogo continua. Num jogo cuja graça é o timing exato de uma armadilha, a velocidade do ciclo de teste é o próprio processo de design.
O que custou
Ser honesto aqui importa mais que a lista de vantagens.
Contexto duplicado. Duas linguagens, duas formas de organizar projeto, duas suítes de ferramentas. Trocar entre elas tem custo mental real, e ele aparece principalmente quando se volta ao projeto depois de semanas.
Publicação diferente. O fluxo de exportação, assinatura e envio para as lojas tinha automação pronta para Flutter. Para Godot, foi refeito. Não é difícil; é tempo que não estava no plano.
Binário maior. Motor completo empacotado junto pesa mais que um app comum. Em jogo casual, tamanho de download afeta instalação — é custo de produto, não só técnico.
Nada é reaproveitável. Componente, tema, utilitário, integração de anúncio: nada do que existia servia. Começar do zero num estúdio que padronizou justamente para não começar do zero é desconfortável.
O que justifica mesmo assim
Duas coisas.
A primeira é que a alternativa era pior. Construir um editor de fases dentro do Flutter é um projeto por si só — e um projeto que não é o jogo. Ou então escrever onze fases em código, o que teria transformado o design de nível numa tarefa de programação, feita pela pessoa errada, no ritmo errado.
A segunda é que platformer é categoria, não projeto. Se fosse um jogo isolado, o custo de contexto não se pagaria e a decisão certa seria outra. Como existe intenção de repetir o formato, o investimento tem onde se amortizar.
Adotar uma segunda stack se justifica quando ela resolve uma categoria de problema. Adotar por um projeto só é quase sempre prejuízo disfarçado de escolha técnica.
A regra que ficou
Escrita antes do próximo jogo, para não ser decidida no calor:
- 1. Conteúdo gerado por regra → Flutter. Com Flame se muda por frame, sem
Flame se muda por evento.
- 2. Conteúdo desenhado à mão → motor com editor.
- 3. Dúvida entre os dois → protótipo da mecânica em Flutter primeiro. Ele é
mais rápido de fazer, e se a mecânica não funciona, a ferramenta não importa.
O passo 3 é o mais valioso e o mais pulado. Escolher motor antes de saber se o jogo é divertido é otimizar a execução de uma ideia não validada.
Sobre o "mobile-first" no título do gênero
Um detalhe de design que vale registrar, porque quase virou problema: platformer de armadilha nasceu em teclado, e a precisão de teclado não existe em tela de toque.
Traduzir isso exigiu mudar o design, não só o controle — armadilhas com janela de reação maior, checkpoints mais próximos, morte barata e reinício instantâneo. Um jogo do gênero portado sem esse ajuste vira injusto no sentido errado: frustrante em vez de engraçado.
A ferramenta não resolve isso. Nenhuma resolve.
Resumo
- O critério não é gráfico: é se o conteúdo é gerado por regra ou desenhado à
mão. Desenhado exige editor.
- Godot entrega editor de cena, tilemap, física e herança de cena — os quatro
itens que faltavam.
- Custou contexto duplicado, publicação refeita, binário maior e zero
reaproveitamento.
- Justifica-se por resolver uma categoria, não um projeto isolado.
- Prototipe a mecânica na stack que você já domina antes de escolher motor.
- Portar gênero de teclado para toque é mudança de design, não de controle.
Perguntas frequentes
Não dava para fazer o platformer em Flame?
Dava, com um custo específico: construir um editor de fases ou escrever cada fase em código. Onze fases escritas à mão são administráveis; ajustar o posicionamento de uma armadilha em código, recompilar e testar, cinquenta vezes por fase, não é.
Godot exporta bem para mobile?
Exporta para Android e iOS. O binário é maior que o de um app comum e o fluxo de assinatura e publicação tem passos próprios — nada impeditivo, mas é processo diferente do que a equipe já tinha automatizado para Flutter.
Vale a pena manter duas stacks num estúdio pequeno?
Só quando a segunda resolve uma categoria inteira de problema, não um projeto. Se fosse um jogo isolado, o custo de contexto não se pagaria. Como platformer com fases é uma categoria que se pretende repetir, o investimento tem para onde se amortizar.
Por que GDScript e não C#?
Por proximidade com o ciclo de iteração. GDScript é a linguagem de primeira classe do editor, com recarga rápida e integração direta com a árvore de nós. Para um jogo de mecânica e não de performance bruta, o ganho de iteração vale mais que qualquer diferença de velocidade.