6 meses, 3 projetos de jogos, 0 publicados

Eu queria ter escrito este post algumas semanas atrás. Mas acho que ainda estava esperando que, quando eu finalmente sentasse para escrever, pelo menos um dos três jogos que eu estava construindo estivesse pronto.

Nenhum está.

Então é aqui que estamos: 684 commits em três projetos ao longo de seis meses, e nada que você possa baixar, jogar ou mandar para um amigo. Se você já aprendeu algo novo fora de um trabalho em tempo integral — algo realmente difícil, algo em que você ainda não era bom — provavelmente sabe exatamente como isso se sente.

Estou escrevendo mesmo assim, porque acho que a história de por que nada foi publicado é mais útil do que um anúncio polido de algo pronto.

O contexto inicial

Por 18 anos trabalhei em advertising. É um bom trabalho, é desafiador, e eu sei fazê-lo. Já lancei campanhas, construí times, escrevi livros, subi em palcos. Nesse mundo, eu sei como "pronto" se parece.

Então, no fim de 2025, decidi que queria aprender game development. Não game marketing. Não game strategy. Construir jogos de verdade — o código, a arte, os sistemas, a sensação de um personagem se movendo na tela.

Eu não tinha experiência com game engines. Nunca tinha riggado um modelo 3D. Não sabia o que era uma state machine no contexto de animação. Já programo há alguns anos, principalmente web apps e produtos de AI, mas jogos são uma disciplina completamente diferente. (Por favor, me corrija se eu estiver errado em qualquer parte disso — ainda estou aprendendo.)

A primeira coisa que aprendi: publicar um jogo é difícil. A segunda: você não consegue raciocinar seu caminho até um bom game loop a partir de um documento.

Você precisa vê-lo se mover. Precisa jogar, ou pelo menos colocá-lo no runtime do Godot e observar se o personagem, a câmera, os controles e o feedback realmente criam alguma sensação. Depois precisa estar disposto a construir, deletar, cortar e reconstruir até que algo interessante apareça.

Foi isso que aconteceu.

---

Projeto 1: The AI Pet Sanctuary (288 commits)

Dezembro de 2025 – Fevereiro de 2026

O primeiro projeto começou com uma ideia simples: e se você pudesse ter um pet que vive no seu computador e conversa com você usando AI? Não um chatbot com avatar de pet — um pet de verdade, com comportamentos, habitat e personalidade.

Construí uma aplicação full-stack. React no frontend, FastAPI no backend, Supabase para o banco de dados. Usei Gemini para conversas e Cloudflare Stream para vídeo.

A parte ambiciosa era o sistema de animação. Eu queria 18 tipos de pets em seis grandes categorias — cães, gatos, pássaros, animais pequenos, peixes, répteis. Cada um precisava se mover, piscar e parecer vivo.

Comecei com animações em Rive. Elas não funcionaram para esse caso. Então as substituí por animações em CSS e JavaScript. Depois construí uma pipeline usando Google Veo 3.1 para gerar conteúdo de animação — geração de vídeo com AI para os movimentos dos pets. Funcionava, mas era frágil. A API falhava, a iluminação era inconsistente, a escala mudava entre gerações. Passei mais tempo lutando contra a pipeline de geração do que desenhando a experiência real do pet.

Também construí um sistema de habitat com ambientes imersivos em tela cheia — um quarto chamado "The Study" onde o pet vivia. Care screens. Memory screens. Integração conversacional. Um redesign completo "Quiet Luxury" no meio do caminho porque a primeira versão parecia um prototype. (Porque era.)

Então eu pivotei.

288 commits depois, decidi que a web app era a plataforma errada e comecei a planejar uma versão nativa para iOS. Ainda não sei se essa foi a decisão certa ou apenas tédio vestido de estratégia. Parte de mim acredita que um pet no celular é mais íntimo do que um pet no navegador. Parte de mim acha que eu só estava cansado de React.

Mas, se eu for honesto, o verdadeiro motivo pelo qual nunca publiquei foi mais simples: era chato. Eu construí tudo isso — habitats, sistema de animação, integração conversacional — e quando chegou a hora de sentar e interagir com o pet, perdi o interesse em dois minutos. Não havia nada convincente o suficiente para segurar minha atenção. Jogo desde a secondary school, então confio nessa primeira reação, mesmo que ainda nem sempre saiba como consertá-la. Ainda jogo Mobile Legends com minha família e normalmente subo até Mystic. Esse não é um jogo que você joga por conforto passivo — ele exige habilidade e atenção. Este pet sanctuary não exigia nenhum dos dois.

Eu continuava dizendo a mim mesmo que o problema era a plataforma. Uma web app não poderia entregar a experiência imersiva que eu queria. Talvez iOS fosse diferente. Mas, no fundo, eu sabia que o problema não era React — era o design. Nenhuma troca de plataforma faria um game loop desinteressante parecer empolgante.

O que deu errado

Olhando para o repo, não acho que a lição certa seja "288 commits sem release é ruim". Se o core loop não é engaging, publicar antes só significa publicar uma coisa chata antes.

O problema real foi que eu continuei trocando o recipiente antes de provar o loop. O projeto foi de mecânicas merge/order, para pure companion, para habitats imersivos, para iOS. Cada pivot tinha um motivo. Mas a pergunta que eu não respondi com clareza suficiente era mais simples: eu gostaria de abrir isto todos os dias?

Eu poderia ter validado isso com um pet, um quarto, uma conversa e uma interação care/play. Em vez disso, construí 18 tipos de pets em 6 categorias de animais com um sistema completo de habitat antes de ter uma resposta runtime para a pergunta mais importante: este pet é interessante o bastante para eu voltar?

Animação gerada por AI é poderosa, mas frágil. Quando funciona, é incrível. Quando não funciona, você está debugging prompts e falhas de API em vez do produto. Você precisa de uma pipeline de fallback, e eu não a construí cedo o suficiente.

O que aprendi

O primeiro trabalho não é cortar scope. O primeiro trabalho é encontrar a parte interessante. Às vezes isso significa construir mais. Às vezes significa deletar o que você acabou de construir. O erro não foi explorar. O erro foi explorar por tempo demais sem uma prova jogável que me dissesse se a experiência central tinha vida.

---

Projeto 2: A raposa que virou um degrau (35 commits)

17 de abril – 12 de maio de 2026

Depois que o pet sanctuary pivotou para iOS, comecei um novo projeto em Godot 4.6. Desta vez eu queria construir um jogo do zero em uma game engine real, não uma web app fingindo ser um jogo.

O conceito inicial: um Spirit Fox Kit Sanctuary Sim. Uma pequena raposa vive em um quarto aconchegante, e você cuida dela. Simples, quente, contido.

Configurei o projeto Godot. Tentei desenhar uma personagem raposa com hidden tense silhouettes, twitch animations mais rápidas e micro-signals de stillness.

Mas essa frase faz o prototype parecer mais legível do que era. Na tela, a raposa não se lia como uma raposa. Era uma pequena massa redonda. Eu não conseguia ver uma forma utilizável, muito menos julgar o restante do ambiente em volta.

Construí um draft room loop com cobertura de testes GUT. Placeholder audio. Hover cues para interactables. Room scene layout. Um cold-start playtest harness para que eu pudesse realmente jogar aquilo.

E então eu joguei.

A verdade honesta é mais visual e menos filosófica: a raposa falhou na primeira leitura. O room prototype tinha um caminho mecanicamente verificado, e o repo até registra um abbreviated solo gate pass para o build com placeholder art. A stillness, o emergence beat, a touch distinction e o room problem eram aceitáveis para aquela etapa.

Mas aceitável para um pequeno authored beat não é o mesmo que visualmente forte o bastante para carregar um jogo inteiro. Esse projeto dependia da raposa carregando a experiência. Se eu não conseguia ver sua forma, postura e appeal, então o sanctuary loop ainda não tinha chance.

Então, em 20 de abril — apenas três dias depois de começar — escrevi uma pivot spec completa. O fox sanctuary sim virou algo completamente diferente: um landscape action-adventure com um safehouse acolhedor e território hostil para explorar. Pausei os planos fox-first e comecei a desenhar uma nova direção.

35 commits. Um beat validado. Um pivot. Nada publicado.

O que deu errado

O problema real é que tratei sinais de animação como se pudessem compensar uma forma base ilegível. Não podiam. Um twitch não importa se o corpo por baixo não tem silhueta.

O pivot não foi prova de que o primeiro trabalho foi desperdiçado. Ele transformou o primeiro trabalho em fundação. O que eu ainda não tinha era evidência de que a direção maior de Hearthkeeper funcionaria, ou de que eu conseguiria tornar seu personagem central legível o suficiente para alguém se importar.

O que aprendi

Playtesting cedo revela o que um prototype realmente está provando. O room prototype provou tom, ritmo e um relationship beat. Não provou um jogo inteiro, e expôs imediatamente o problema de legibilidade visual. Essa é uma informação útil, mas aponta para um próximo passo diferente: resolver a leitura do personagem e construir o menor loop safehouse -> run -> return antes de polir a raposa de novo.

Game 1 me ensinou que um loop tecnicamente completo ainda pode ser chato. Game 2 me ensinou que um conceito de personagem documentado e testado ainda pode falhar visualmente em segundos. Essas duas falhas são parte do motivo pelo qual Game 3 fez progresso mais real: estou prestando muito mais atenção a readability, motion, weapon feel e se o playable slice funciona na tela.

Pivotar a partir de evidência é diferente de ficar à deriva. A raposa não se lia no runtime, então mudar de direção não era automaticamente falta de disciplina. A parte que preciso melhorar é o feedback loop: colocar a pergunta visual ou de gameplay mais arriscada na tela mais rápido, e então decidir com evidência em vez de ficar no concept mode.

---

Projeto 3: O projeto em que a pipeline começou a funcionar (361 commits)

21 de abril – 13 de maio de 2026

Este é o projeto em que ainda estou trabalhando. Também é o projeto em que o aprendizado dos dois primeiros finalmente começou a se compor.

É um jogo de mech tactics. Você controla um squad de mechs em combate, e depois de cada batalha um LLM analisa o que aconteceu e entrega um debrief. Pense em análise pós-jogo, mas escrita por uma AI que tem acesso a todo o game state.

O repo tem três tracks, mas eles já não são iguais:

Track A — The LLM Debrief System: Foi o track inicial de validação AI. Ele me ajudou a testar structured debriefs, mas já não é o principal caminho do produto.

Track B — The 2D Phone Prototype: Foi aqui que finalmente encontrei uma pipeline viável para uma experiência 2D relativamente imersiva no celular. O runtime real em Godot tem lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, motivos VFX legíveis no telefone, enemy punish zones, um neutral relay objective, HUD feedback e fluxo de iOS export/testing. A art pipeline também começou a funcionar: Nano Banana 2 (Gemini 3.1 Flash Image) gerou imagens iniciais utilizáveis de heróis e personagens, e depois um workflow de pixel cleanup baseado em MCP e Aseprite transformou candidatos curados em sprites limpos, animation frames e sheets prontos para Godot. Não é um jogo acabado, e a aceitação em telefone ainda está pendente, mas está muito mais perto de "isto parece um jogo" do que os dois primeiros projetos.

Track C — The Campaign and 3D Path: Esta é a direção atual do produto. Ela mantém as lições úteis de Track B, adiciona um campaign memory loop e leva o production combat para 3D/2.5D. É um problema muito mais difícil do que a pipeline 2D. Em 2D, consigo controlar readability com sprite sheets, HUD tuning, procedural VFX e phone captures. Em 3D, cada decisão toca modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing e runtime performance.

Também integrei Blender para custom rigging work, trouxe dados de mocap da Rokoko para locomotion e construí o personagem hero mech com full rig, animation tree e weapon socket integration.

361 commits em três semanas. Uma pipeline 2D real. Um experimento 3D muito mais difícil. Ainda em território de prototype.

O que deu errado

Aqui está o que preciso admitir: a pipeline 2D está começando a funcionar, mas a pipeline 3D pode engolir o projeto inteiro se eu deixar.

Para Track B, o trabalho de pipeline não era progresso falso. O workflow Nano Banana 2 -> Aseprite, touch controls, HUD, ability motifs legíveis, module feedback, phone captures e export loop estavam tornando o produto mais jogável. Esse trabalho me ensinou o que um jogador precisa ver e sentir momento a momento.

O risco agora é diferente. Em Track C, 3D exige muita pipeline antes de parecer qualquer coisa: model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX e runtime inspection. Esses não são detalhes opcionais. Se o personagem não se lê, a cena inteira falha em segundos.

Mas o playable encounter ainda precisa liderar. Caso contrário, posso passar semanas melhorando weapon fit, jump compression, left-hand IK e mocap cleanup do hero mech sem responder à pergunta simples do jogador: isso é divertido de controlar?

O que aprendi

Trabalho de pipeline só é útil quando continua servindo ao playable slice. Track B me ensinou que a pipeline certa pode criar uma experiência 2D mais imersiva. Track C está me ensinando que 3D aumenta o custo de cada melhoria. Preciso manter o acceptance gate concreto: o jogador consegue ler o hero mech, movê-lo, mirar, atirar, entender o hit e querer fazer isso de novo?

Tracks precisam de gates. Track A cumpriu seu papel. Track B produziu lições reutilizáveis de 2D game feel e presentation. Track C é a aposta atual. O problema não é ter explorado múltiplos caminhos. O problema é reabri-los sem uma pergunta clara de runtime e uma regra clara de decisão.

Game development 3D é um skill gap enorme. Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing e readable motion são disciplinas em que tenho zero experiência profissional. Estou aprendendo isso enquanto também aprendo Godot, game design e campaign architecture. A learning curve não é íngreme — é vertical. Acho que essa foi a parte que mais me surpreendeu. Em web development, consigo construir algo funcional em um dia. Em 3D game dev, passei uma noite inteira tentando fazer o braço de um personagem dobrar corretamente. (Esse é o tipo de frase que eu não teria entendido seis meses atrás.)

---

O que esses três projetos têm em comum

Se eu for honesto comigo mesmo — e este post só funciona se eu for — o padrão não é "scope creep". Isso é fácil demais, e neste caso acho que está errado.

Não acho que jogos funcionem como business decks — pelo menos foi isso que esses três projetos me ensinaram. Você não sabe se uma ideia funciona porque a premissa soa boa. Você sabe quando pode jogá-la, ou pelo menos vê-la rodando no engine e sente se o personagem, a câmera, a interação e o feedback estão fazendo algo.

1. O runtime é a verdade

O pet sanctuary soava bem até eu interagir com o pet e ficar entediado. A raposa soava bem até eu vê-la no Godot e não conseguir ler a forma. Track B começou a funcionar porque o loop chegou a um runtime parecido com telefone: touch controls, HUD, VFX, shop, XP, motivos legíveis e capture feedback.

Esse é o padrão real. A verdade útil só apareceu quando a ideia se tornou visível e jogável.

2. Exploração é necessária, mas precisa de evidência

Não acho que a lição correta seja "pare de adicionar coisas". Game development precisa de exploração. Você constrói, testa, deleta, corta, reconstrói e testa de novo porque está procurando a parte interessante.

A parte que precisa de disciplina não é a quantidade de trabalho. É o evidence loop. Cada pedaço de trabalho deveria responder a uma pergunta: isto torna o jogo mais legível, mais engaging, mais controlável, mais digno de replay?

3. Pipelines são boas quando tornam o jogo mais jogável

O workflow Nano Banana 2 -> MCP cleanup -> Aseprite não foi distração. Ele me ajudou a colocar personagens 2D e animações melhores no jogo. O trabalho de HUD e VFX em Track B também não foi progresso falso. Tornou o runtime mais claro.

O risco aparece quando a pipeline para de responder a uma pergunta voltada ao jogador. Em Track C, tooling 3D é necessário, mas precisa voltar sempre para uma coisa: o jogador consegue ler o hero mech, movê-lo, disparar a arma, entender o hit e querer fazer de novo?

4. A lacuna não é coding skill. É playable judgment.

Consigo construir uma aplicação full-stack com Supabase, FastAPI e React. Consigo riggar um modelo 3D, escrever testes GUT e construir custom debugging tools. O que ainda estou aprendendo é julgar se algo é realmente interessante como jogo. Track B me aproximou em 2D. Track C está mostrando o quanto isso fica mais difícil quando motion, camera, lighting, weapons e animation precisam funcionar juntos.

Acho que essa é a coisa mais importante que aprendi. Código é a parte em que sou bom. O difícil é decidir o que o jogo realmente é, torná-lo interessante e então ter disciplina para voltar à evidência do runtime até que valha a pena publicar.

---

O que aprendi no geral

Se eu tentar destilar seis meses em algo útil — para mim, ou para qualquer pessoa na mesma posição — isto é o que acho que sei agora e não sabia em dezembro:

1. A primeira versão deve responder à pergunta mais arriscada no runtime. Meu pet sanctuary precisava de uma interação com o pet que me fizesse querer voltar. Meu jogo da raposa precisava de uma silhueta legível em um quarto vazio antes de eu me preocupar com micro-signals. Meu jogo de mechs chegou mais perto por meio de Track B porque eu conseguia ver e sentir o loop na tela.

2. Playtesting não é opcional, e runtime review conta. No momento em que vi a raposa como uma massa sem forma, soube que o projeto ainda não funcionava. Esses foram os 30 minutos mais valiosos de todo o projeto. Eu deveria ter chegado a essa verdade visual mais cedo.

3. Aprender é um resultado válido, mesmo quando não era o planejado. Eu queria construir jogos. Não publiquei jogos. Mas aprendi Godot, LLM prompt engineering, Nano Banana 2 para character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability e a diferença entre construir tools e construir products. Isso não é nada. Também é por isso que Game 3 é melhor que Game 1 e Game 2, mesmo ainda não tendo sido publicado.

4. Ainda preciso definir uma finish line honesta. Parte de mim quer levar este projeto até o fim para poder dizer que publiquei um jogo. Parte de mim acha que o aprendizado foi o produto e que eu deveria aceitar isso. As duas respostas são honestas. Acho que a verdade está no meio: publicar um slice focado que respeite o que aprendi, em vez de recomeçar do zero.

O que vem a seguir

Ainda estou trabalhando no projeto de mech tactics. O conceito de LLM debrief é interessante, e acho que há algo genuinamente novo na ideia de AI-powered post-match analysis para um tactics game.

Mas estou tentando mudar minha abordagem: runtime proof primeiro, polish depois, publicar algo só depois que o playable slice tiver uma razão para existir. Os dois primeiros projetos não foram desperdiçados. Eles mudaram o que observo em Game 3: o personagem se lê, o motion parece bom, a arma parece certa, e alguém consegue entender o encounter sem eu explicar a arquitetura?

Se eu começasse um jogo novo hoje, não começaria com um grande architecture plan. Começaria com o runtime proof mais rápido que pudesse responder à pergunta que realmente me importa. Para Game 3 agora, a mesma disciplina precisa acontecer dentro do projeto: um personagem, uma arma, um encounter, um acceptance test claro.

Ainda não sei se vou levar um desses projetos até a conclusão ou aceitar que o aprendizado foi o produto. Posso estar errado sobre o timeline, mas acho que o padrão importa mais do que qualquer projeto individual.

Uma pergunta para você

Quero perguntar de verdade, não retoricamente: você já esteve aqui? (Suspeito que mais builders passaram por isso do que costumamos admitir.)

Você já passou meses construindo algo que nunca foi publicado? Você terminou no fim, ou foi embora? E se foi embora — foi a decisão certa, ou você ainda pensa nisso?

Já publiquei coisas na minha carreira. Campanhas, plataformas, produtos. Mas eram em um domínio em que eu tinha 18 anos de experiência. Game development é novo, e a distância entre "consigo construir isto tecnicamente" e "isto é um bom jogo" é muito maior do que eu esperava.

Se você já atravessou essa lacuna, eu adoraria saber o que impediu você de pivotar de novo. Pode responder no LinkedIn ou me escrever diretamente — estou realmente curioso.

---

É isso por hoje. Eu adoraria ouvir suas ideias — especialmente se você já passou por algo parecido. Fique à vontade para falar comigo no LinkedIn ou me mandar uma mensagem diretamente.

Abraços,

Chandler