A página documenta não só o que foi criado, mas como se chegou às decisões: qual era o problema de cada etapa, como a IA foi usada como colaboradora, o que foi escolhido ou corrigido por orientação humana e que evidências ficaram no projeto. A sequência abaixo é editorial e cronológica; não substitui os documentos de especificação nem afirma que todas as propostas foram implementadas.
Capítulo 01 · Da ideia ao recorte do produto
Encontrar uma ideia que pudesse ser testada
Ponto de partida. O projeto começou com a intenção de criar uma aventura 2D em Pixel Art sobre exploração, memórias e uma civilização desaparecida. A primeira tarefa foi transformar esse tema amplo em uma experiência que coubesse em uma entrega inicial.
Trabalho com IA. A colaboração em conversa ajudou a decompor a ideia em pilares de produto, universo narrativo e possibilidades de jogo. A narrativa passou a girar em torno de Avelora, dos cristais que preservam memórias e do evento chamado O Silêncio.
Decisão humana. Para evitar começar por um jogo grande demais, foi escolhido um arco planejado de dez fases, mas um MVP limitado à Floresta Esquecida. Exploração, alternância temporal, enigma e conclusão formariam o recorte a validar; combate e sistemas extensos ficariam fora dele.
Resultado documentado. A visão do jogo, a narrativa e a especificação do MVP registram conceito, pilares, sequência da fase, limites e critérios de aceite. O conteúdo futuro aparece como planejamento, não como funcionalidade entregue.
Capítulo 02 · Da proposta à documentação
Registrar decisões antes de ampliar o escopo
Pergunta desta etapa. Como manter alinhados produto, história e implementação sem transformar cada nova ideia em requisito automático? A resposta foi separar os assuntos em documentos com responsabilidades distintas.
Trabalho com IA. Agentes de IA apoiaram a redação, a organização de requisitos, a exploração de alternativas técnicas e a decomposição do plano. As conversas foram convertidas em artefatos que podiam ser relidos e revistos, em vez de permanecerem apenas como decisões implícitas.
Decisão humana. O escopo e as prioridades foram direcionados pelo usuário. Sugestões foram tratadas como opções: a arquitetura proposta não era prova de implementação, e os requisitos precisavam caber no MVP.
Resultado documentado. Foram estruturados seis arquivos Markdown: visão, narrativa e fases, especificação do MVP, arquitetura técnica, plano de desenvolvimento e plano técnico detalhado, com etapas, testes, riscos e critérios de conclusão.
Capítulo 03 · Preparar a colaboração com agentes
Usar especialização sem abrir mão de direção
Problema observado. Um único perfil genérico tende a misturar decisões artísticas, de game design e de engenharia. O fluxo precisava preservar contexto do projeto e, ao mesmo tempo, carregar conhecimento específico apenas quando necessário.
Trabalho com IA. Foi configurado o agente Game Design & Pixel Art Expert para inspecionar o repositório, identificar a engine, preservar escopo, implementar e validar. O perfil reúne desenvolvimento de jogos, arte, UX, arquitetura, performance, testes e web. O Tech Lead apoia tarefas de arquitetura e engenharia.
Skills sob demanda. Workflows independentes cobrem Pixel Art, precisão de pixels, gameplay, UI/UX, animação, level design, arquitetura, performance, QA, pipeline de assets e desenvolvimento web. A seleção depende da tarefa; não se carrega todo o repertório em toda interação.
Responsabilidade e limite. Os agentes propõem, analisam e executam tarefas delegadas; a direção do projeto continua sendo humana. Código, assets, decisões de produto e resultados de testes precisam ser inspecionados. Não se presume que uma API, ferramenta ou validação exista sem evidência.
Resultado documentado. Os perfis e skills ficaram em arquivos reutilizáveis, com descrições e instruções especializadas, e são disponibilizados na seção de agentes.
Capítulo 04 · Prototipar, observar e reavaliar
De um protótipo simples a uma base técnica mais rica
Primeiro experimento. A V1 foi construída como um único HTML com Canvas, CSS e JavaScript, para abrir diretamente no navegador sem instalar dependências. A intenção era testar rapidamente o fluxo central antes de assumir uma stack mais complexa.
Iteração visual. Nas V1.1, V1.2 e V1.3, o feedback se concentrou em iluminação, vegetação, resolução, caminho, rochas e arquitetura. A história e o enigma foram preservados enquanto a apresentação e a densidade visual evoluíam.
Reavaliação técnica. Para sustentar arte e sistemas mais elaborados, a fase foi reconstruída em Phaser e TypeScript, com Vite. Scripts em Python com Pillow passaram a gerar tiles, sprites e decoração de forma repetível, reduzindo trabalho manual em assets.
Iteração da V2. A direção visual avançou para cenários escuros iluminados por lanterna, texturas mais densas e árvores orgânicas. Cada pedido de refinamento foi aplicado ao gerador e conferido no jogo, mantendo os identificadores de assets e os dados de mapa.
Resultado documentado. V1.0–V1.3 registram a exploração inicial de forma independente; V2.0–V2.2 mostram a reconstrução e refinamentos técnicos e visuais. As capturas abaixo são evidências de versões, não uma afirmação de que o projeto completo planejado já esteja pronto.
Capítulo 05 · Validar, corrigir e registrar limites
Fechar o ciclo com testes e evidências
Problema reproduzido. Na V2.2, após ativar Sol, Lua e Ondas, o personagem não conseguia passar pelo acesso do templo. A sequência do enigma concluía, mas os pedestais das runas deixavam uma passagem estreita demais para a colisão do jogador.
Correção e validação. A largura das colisões dos pedestais foi reduzida sem alterar sua arte. A sequência foi testada no navegador: ativação da última runa, travessia até a câmara e interação com o núcleo. Build e testes automatizados existentes também foram executados.
Aprendizado sobre IA. A utilidade não esteve em aceitar uma primeira resposta, mas em encadear inspeção, hipótese, reprodução, mudança pequena e verificação. O agente deve relatar o que realmente testou e explicitar o que não cobriu.
Estado e continuidade. Builds, testes, capturas, arquivos-fonte e planos preservam rastreabilidade. Questões em aberto e diferenças entre planejado e implementado continuam explícitas, para que próximos passos partam de evidências e não de suposições.
Os documentos são numerados e se complementam: visão e narrativa definem o produto; a especificação delimita o MVP; a arquitetura explica como organizá-lo; e os planos detalham etapas, testes, riscos e critérios de conclusão. Eles registram decisões e propostas, não significam que todo o conteúdo planejado tenha sido implementado.
Os arquivos abaixo são o material de planejamento usado na construção. Cada um pode ser aberto no navegador ou baixado.
