Pular para o conteúdo
Carregando página…
Myths' Valley

Direção · 7 de 7

Concluir uma experiência pequena de ponta a ponta antes de ampliar — e registrar cada mudança com o seu impacto no prazo.

O protótipo 3D nasceu em 23/09/2026 com um objetivo escrito: entregar uma demonstração jogável para Windows em dois finais de semana (26–27/09 e 03–04/10), usando Godot, modelos produzidos no Tripo e animações humanas, com meta interna de conclusão em 04/10 e submissão ao Tripothon S1 em 05/10. A ordem de prioridade definida pelo produto foi velocidade de desenvolvimento, depois qualidade gráfica, depois capacidade de expansão técnica; a referência visual é My Time at Evershine — direção artística, não compromisso de reproduzir escala ou acabamento.

Duas decisões mudaram o rumo depois disso. Em 29/09, o autor decidiu que o 3D vira o jogo completo, que o 2D passa a ser a referência de regras e que a migração é a prioridade: o plano virou 32 issues em dois marcos, Jam 04/10 e Pós-jam. Em 01/10, decidiu manter os jogos 2D e 3D em repositórios independentes, com o projeto Godot na raiz e sistemas locais. O board é a fonte dos critérios de aceite; a issue é a unidade de trabalho, e o documento é o porquê dela.

9 princípios

O que não se negocia

Pequeno e inteiro antes de grande

Concluir uma experiência de ponta a ponta antes de ampliar o número de sistemas, personagens ou cenários. A visão completa de gameplay (plantio, criação, coleta, mineração, pesca, crafting, economia, combate, quests, amizade, história) não se confunde com o conjunto comprometido para quatro dias de produção. Funcionalidade nova deve substituir esforço equivalente ou permanecer fora do compromisso da jam.

Manter Godot; Windows; single-player; terceira pessoa

Godot Standard e GDScript, sem migrar para Unity ou Unreal; Forward+ como primeira opção, condicionado a teste no computador-alvo. Windows como plataforma, Steam como destino posterior sem integração obrigatória; navegador, mobile e consoles fora do escopo; sem multiplayer nem arquitetura de rede; câmera em terceira pessoa com SpringArm3D.

Tripo para praticamente todos os modelos, sem Blender

Personagens, casas, objetos, equipamentos e vegetação vêm do Tripo; não depender de Blender, retopologia ou modelagem manual para concluir a entrega. O primeiro teste obrigatório foi um personagem completo funcionando numa build fora do editor: um protótipo de 65 ossos (23/09) e a casa de Carro Quebrado (24/09) validaram o pipeline antes da produção em volume. O rig acabou saindo do próprio Tripo (Auto Rig humanoide com esqueleto Mixamo), e não do Mixamo.

29/09: o 3D vira o jogo completo

O 2D passa a ser a referência de regras, a migração é a prioridade e a jam entra com o que estiver de pé. O que o 3D já tem fica. Três itens do documento original ficaram fora do marco da jam e foram para o Pós-jam: a conversa por LLM com memória e o plantio; o save ligado às vagas acabou saindo ainda em 29/09. Se algum precisar voltar, a decisão é do autor e o marco da issue muda junto.

01/10: repositórios independentes

O 3D está na raiz de acentauric/myths-valley-3d, na branch main; o 2D segue a própria linha em acentauric/myths-valley. Nenhum comando de desenvolvimento ou teste exige o checkout do outro; não há sincronizador de regras, dados ou áudio. Os quatro arquivos compartilhados que bifurcaram (o machado como item de encaixe) esperam uma decisão do autor: promover a regra ao 2D ou declarar a bifurcação.

Dois estilos visuais, e depois um só

Até a Build 10, AJUSTAR → Cenário e tempo escolhia como o vale inteiro era construído: Tripo (linha mestra) ou Procedural (prova inicial), nunca misturados, para decidir a linha mestra olhando os dois no mesmo lugar. O procedural não recebeu arte nova nem foi removido numa mudança incidental: a retirada foi uma tarefa própria, com portões, e aconteceu em 10/10/2026, na Build 11. Hoje o vale é só Tripo.

O corte da jam: o que entra e o que fica para depois

Entram as missões nas âncoras que existem, a mochila, o fôlego no HUD, a tabela de teclas das telas novas, o primeiro lote Tripo de itens de mão e a tradução. Não entram a Fase 2.5 (estender a região é desenho de KML e importação), os bichos (pedem rig e clipes) nem os interiores (pedem cômodo, que é sistema e não peça). Tela nova a quatro dias de uma submissão é como se perde uma submissão. A regra do corte: nada entra na demo sem portão.

Tudo traduz, e a tradução é do autor

pt-BR, inglês e espanhol em todo texto de jogador, não só no menu — decisão tomada antes da Fase 3 para que o primeiro passo de missão já nascesse com _en e _es. O custo é o conteúdo triplicar; o ganho é o vale deixar de ter um teto de público. A migração entrega a estrutura e o portão; o texto traduzido é do Ramon.

O 2D é referência, não dono

O vale tem mecanismo próprio de missão (CadernoDoVale, uma linha de andamento, sem checklist) por decisão do autor: missão nova aqui pode ter padrão, formato e ordem diferentes. As obras saíram com efeito no corpo antes da arte ("efeito agora, arte depois"). O almanaque é a coleção (L), a teia de talentos fica no K, o arraial no P, a mochila no I e o painel no J, as mesmas teclas que o tutorial do 2D ensina.

8 regras

Na prática, no dia a dia

  • Registrar toda alteração de rumo no documento de decisões com o impacto no prazo; funcionalidade nova substitui esforço equivalente ou fica fora do compromisso.
  • Enquanto houver tarefa aberta no marco Jam 04/10, ela tem prioridade; o Pós-jam segue as dependências descritas em cada issue.
  • Quando uma fatia fecha uma issue, a fase correspondente é riscada no plano no mesmo commit: board e plano que discordam são dois planos.
  • Cada lote do Tripo é aprovado antes de rodar, com o custo mostrado pela interface na conversa antes do clique; as issues 'modelos-3d' gastam crédito e exigem custo aprovado.
  • Não tratar o documento de decisões como regulamento do Tripothon: prazo, fuso, formato, duração de vídeo, categorias e regras para projetos anteriores se conferem no formulário vigente antes de submeter.
  • Identificar claramente o que já existia na base 2D e o que foi produzido para o protótipo; não afirmar elegibilidade sem verificar as regras aplicáveis.
  • A entrega é uma build Windows empacotada em ZIP com todos os arquivos necessários, commit ou tag identificável, instruções de execução e a relação de assets e créditos.
  • A licença de redistribuição de cada modelo (inclusive os protótipos de teste e os modelos do Tripo após eventual cancelamento do plano) é confirmada antes de publicar.

Onde isso aparece

  • O primeiro teste local (23/09/2026)
    Projeto Godot independente, protótipo humanoide com 65 ossos (FBX sem clipes, depois GLB com clipes exportados no Tripo), controlador de 1,78 m com corrida, colisão e câmera; Forward+ iniciado na GTX 1660 Ti with Max-Q Design.
  • A primeira casa integrada (24/09/2026)
    O fluxo semiautomático Tripo Studio → GLB → Godot validado com a casa de Carro Quebrado: 65 créditos, tarefa fef21312-…, 1.915.732 → 273.548 triângulos.
  • O board (29/09/2026)
    32 issues com o rótulo 3d, divididas em Jam 04/10 e Pós-jam, com rótulos de área: sistemas, interface, conteudo, mapa, modelos-3d e qualidade.
  • A separação (01/10/2026)
    O projeto abre na raiz, com sistemas locais e testes sem checkout do 2D; modelos e WAVs em Git LFS; abertura e controles contam falhas e foram falsificados para conferir a reprovação por código de saída.
  • A identificação da build
    "v0.1.0-dev · Build #6" (28/09/2026), marco histórico desta derivação; a distribuição atual é a Build 12 (v0.12.0) para Windows; o 2D vai em 0.2.0-dev e Build 14.

De onde vem

Os documentos desta área

As orientações acima resumem estes documentos de direção do jogo.
  • Decisões do protótipo 3D — o que foi decidido e quando
  • Histórico do desenvolvimento — as etapas antes do repositório próprio
  • Do 2D ao 3D — por que os dois jogos seguem separados
  • Plano do 3D — o rumo do jogo e as próximas etapas
  • Composição autoral — como o vale é editado no Godot
  • Assets com o Tripo — o fluxo oficial dos modelos 3D
  • O vale vivo — dia e noite, moradores e som do vale
  • Changelog do 3D — o que mudou em cada build
  • Versão do jogo — o número que carimba cada build