Registro de uma edição anterior. A direção atual usa histórias reais NASA e IPÊ somente como nome da equipe. Consulte o handoff R18 e os dados reais e fontes atuais. Propostas e estados abaixo conservam o corte original.

29 — Game Design: a missão termina quando a ciência chega

Implementação R14: a entrega das três missões concretiza a reprodução temporal na cena, os quatro segmentos, Bennu/Telescópio com narrativa e revisão de equipe local. Quatro modelos NASA foram integrados como referências. As cinco cenas e demais ideias abaixo conservam o desenho original R13; nem toda proposta virou funcionalidade.

Revisão R13 · 14/11/2026 · proposta de evolução sobre o beta 0.4.0-beta.2.

Explorar a proposta interativa · Jogar a base atual · Acervo NASA 3D · Handoff da dupla.

1. Proposta e diferencial

PROJETO IPÊ é um jogo de engenharia de missões em que você constrói uma nave para responder a uma pergunta científica, acompanha o caminho dos dados e redesenha a missão quando a ciência não chega.

O propósito vem antes da peça. A pergunta inicial é sobre vegetação do Cerrado; o jogador precisa entregar seis registros históricos válidos, respeitando os limites do projeto. A experiência desejada conecta cinco cenas 3D: uma mesa científica, o hangar, a integração ao lançamento, a órbita e a estação de recepção. O mesmo registro acompanha essa viagem: pedido, processado, armazenado, recebido e validado.

O diferencial proposto é a revisão causal da missão. Ao encontrar uma falha, o jogador volta ao instante relevante, vê qual componente e recurso estavam envolvidos, declara uma hipótese, altera uma escolha e compara a nova tentativa. A cena mostra a evidência produzida pelo motor. Cada tentativa conserva seu projeto e suas entradas.

Essa combinação é uma hipótese de diferenciação do Ipê, ainda a avaliar com jogadores; não é uma alegação de novidade mundial. Uma animação convincente ajuda a compreender, mas não comprova que uma missão é viável.

2. O que já existe e o que esta revisão propõe

A página interativa desta revisão é um estudo de experiência, com esquemas SVG e comparação qualitativa. Ela não implementa as cinco novas cenas, não altera a pontuação e não executa GMAT. O jogo atual continua sendo a referência para resultados numéricos.

3. Quatro segmentos, uma cadeia de decisões

A apresentação NASA Design and Develop Science Missions orienta a leitura da missão como um sistema completo. A aplicação abaixo é uma proposta de game design do Ipê.

O segmento de usuário abre e fecha a experiência. Não basta mostrar um foguete decolando: o jogador deve terminar capaz de explicar o que foi recebido e por que uma mudança ajudou ou prejudicou a missão.

4. Jornada de uma partida

1. Entender. Um pedido científico apresenta a pergunta, os seis registros e o critério de sucesso. Um exemplo mostra a diferença entre arquivo recebido e evidência válida.
2. Construir. No hangar, escolher componentes por botões e fichas; a geometria acompanha a configuração. Inspecionar uma peça revela W, Wh, capacidade ou taxa com unidade explícita.
3. Prever. Registrar a hipótese antes da execução. O pré-voo aponta restrições, sem revelar automaticamente a solução.
4. Preparar o lançamento. Mostrar a checagem de integração e a transição para a missão. No primeiro recorte, esta etapa é uma representação dos requisitos existentes, sem física de subida inventada.
5. Executar. Assistir ou avançar por eventos. Pausar, voltar e escolher um instante não recalculam a missão nem mudam seu resultado.
6. Investigar. Selecionar um evento de perda ou atraso e seguir o registro entre processamento, memória e recepção. Texto e diagrama apresentam a mesma restrição observada; a comparação ajuda a investigar a hipótese causal.
7. Redesenhar e comparar. Alterar preferencialmente uma escolha, formular nova hipótese e executar outra tentativa. Comparar ciência válida e margens de recursos sob o mesmo cenário.

Meta de produto para uma demonstração: tornar esse ciclo legível em poucos minutos, sem exigir domínio prévio de astrodinâmica. O tempo real de uso deve ser medido; não está estabelecido nesta revisão.

5. Onde o 3D tem função

O objetivo é usar 3D em toda a experiência espacial, mantendo leitura, unidades, fontes e decisões acessíveis em HTML. O usuário pode completar a partida com teclado e representação 2D. Evitar textos pequenos presos ao modelo, decisões dependentes de arrastar ou informação transmitida somente por cor.

Cada cena deve oferecer uma câmera inicial útil, seleção por botões, reposição da câmera, pausa e preferência por movimento reduzido. Não executar vários canvases pesados em paralelo: a comparação pode reutilizar uma cena com alternância A/B e gráficos comuns.

Linguagem visual

Manter a identidade Ipê: cobre para construção, azul para comunicação, papel claro para estudo e fundo espacial para operação. A marca vetorial permanece sem caixa no cabeçalho claro. Bricolage Grotesque organiza títulos e Plus Jakarta Sans sustenta leitura e controles, com arquivos locais. As fotografias têm legenda e crédito; um modelo de uma missão NASA aparece identificado como referência, não como projeto original do Ipê.

Os modos de visualização devem informar sua fidelidade: conceitual, resultado do motor didático ou trajetória de referência importada. São camadas distintas. A aparência realista de um GLB não fornece massa, potência, trajetória ou desempenho de engenharia.

6. Mecânicas e equilíbrio

Condição atual de sucesso: seis registros válidos e atendimento às restrições da missão. Preservar esse contrato; não acrescentar um score secreto ou pontuação calculada na cena.

Conflitos produtivos: capacidade versus massa/custo, transmissão versus disponibilidade de energia, processamento versus volume de dados, memória versus duração do contato. A explicação precisa vir dos eventos registrados e das unidades corretas; não concluir causalidade apenas porque dois indicadores mudaram juntos.

Progressão sugerida: primeiro aprender a cadeia de dados no cenário de contatos longos; depois enfrentar contatos curtos; por fim comparar projetos. Semente e Raízes podem nomear esses percursos já fundamentados. Campanhas sobre tempestades solares, asteroides e telescópios são expansões com objetivos próprios, posteriores ao ciclo completo do Cerrado.

Ajuda gradual: começar com uma pergunta orientadora; depois indicar um evento; só então oferecer uma alternativa explicada pelo motor. Registrar se a comparação usou ajuda, sem apresentar esse registro como certificado de aprendizagem.

Sem sorte oculta no recorte inicial: o cenário e as entradas ficam conhecidos e preservados. Eventos solares futuros devem usar snapshot identificado, regras explícitas e possibilidade de repetir a partida.

7. Ferramentas NASA como oportunidade concreta

As descrições da página do desafio enviadas pelo usuário foram usadas como briefing. O endereço oficial do desafio não pôde ser lido integralmente nesta consulta; as fontes acima foram procuradas individualmente. Recursos encontrados não confirmam inscrição, elegibilidade nem situação atual do evento.

8. Contrato entre simulação, cena e dados

O motor existente continua sendo a única fonte de resultados. A futura camada de apresentação recebe configuração preservada, cenário, resultado e instante selecionado. Ela deriva qual peça destacar e qual restrição e recurso explicar; não substitui equações ou cria eventos de sucesso.

A inspeção do código encontrou um ponto de integração preciso: MissionControl.tsx já reproduz a série trace; Scene.tsx aparece no briefing e no hangar, e seus consumidores atuais não passam o progresso da missão. O canvas também não aceita seleção direta de peças. Portanto, o primeiro ganho é conectar esses estados existentes, antes de acrescentar uma nova simulação.

Para o replay visual, Dev A deve primeiro definir um mapeamento dos campos existentes de resultado para tempo, eventos, energia, memória, transmissão e validação. Dev B implementa a cena sobre esse contrato. Se um estado não está registrado ou não pode ser derivado com fidelidade, a interface mostra ausência de informação.

Casos de aceite do adaptador: no eclipse, geração e bateria refletem o estado registrado; o enlace aparece apenas durante transmissão efetiva; um registro parcial continua incompleto ao fechar o contato; o par científico só fica disponível após as duas entregas válidas. Ao voltar na linha do tempo, não antecipar dados ou eventos futuros. Usar estados discretos do motor e identificar qualquer interpolação apenas visual.

A comparação A/B sincroniza por timeS, nunca pelo índice da trace: tentativas podem ter fronteiras temporais diferentes. O adaptador deve documentar se apresenta o estado anterior ou posterior à transição e conservar todos os eventos daquele horário. appendTrace substitui pontos com tempo igual, enquanto events pode manter vários eventos; uma amostra não deve apagar essa sequência.

Trajetórias GMAT/SPICE futuras precisam declarar: ferramenta e versão, arquivo de entrada, época, unidade, referencial, passo temporal, hipóteses e hash. O consumidor rejeita unidades ou referenciais incompatíveis. Interpolação visual deve ser identificada e não alimentar regras de missão sem validação específica.

APIs externas entram por coleta controlada, com cache e snapshots; chaves ficam fora do cliente. A missão demonstrada deve funcionar com os dados locais publicados. Antes de prometer operação offline, testar também a recarga e o primeiro acesso sem rede.

9. Ativos 3D e desempenho

Usar o catálogo curado, sem importar o acervo inteiro. Priorizar Earth/terreno como contexto e nave procedural como projeto interativo. Uma antena de espaço profundo é referência de uma expansão; não substituir a estação didática LEO pela DSN como se fossem equivalentes.

Para cada ativo adotado: guardar URL oficial, autoria, condições de uso, arquivo original, data de obtenção, hash, tamanho, e registrar alterações de materiais/escala/geometria. Modelos STL voltados à impressão podem precisar de conversão, materiais e redução de geometria; não supor que todos são GLB prontos para web.

Metas propostas, ainda não medidas: cena essencial sob demanda; até 5 MB adicionais comprimidos para o primeiro pacote 3D; texturas iniciais até 2K; resolução de renderização limitada conforme dispositivo; tentar 30 quadros/s estáveis no dispositivo móvel escolhido para ensaio. Se a medição falhar, reduzir geometria/textura/efeitos e manter alternativa 2D. Um limite de bytes não garante fluidez.

Evitar pós-processamento e partículas sem função de leitura. Suspender renderização contínua quando não houver movimento ou quando a cena estiver fora de vista. Preservar geometria procedural para partes que mudam com as escolhas; não trocar um hangar funcional por uma nave pronta e indivisível.

10. Plano para dois desenvolvedores

Sequência por entregas, sem inventar prazo ou velocidade da dupla. Antes de iniciar, ambos confirmam o commit-base, um responsável por arquivo compartilhado e o cenário de demonstração.

Na primeira rodada, concluir E0–E2 antes de ampliar o número de cenas. Isso entrega um diferencial observável sobre a base atual. E3–E4 ampliam presença espacial com o contrato estável. GMAT e novas campanhas entram depois da demonstração completa; não bloqueiam o núcleo educativo.

Arquivos: Dev A assume experiments/mission-design-lab/src/core/, src/lab/ e testes de domínio; Dev B assume src/ui/, src/ui/OrbitalScene.tsx, src/ui/Scene.tsx, estilos, testes de interface e ativos. src/App.tsx, contratos e versão têm um editor por vez. Consultar o handoff para o mapa completo.

11. Critérios de avaliação e roteiro de apresentação

1. O jogador identifica o objetivo científico antes de escolher peças.
2. Uma escolha muda a configuração visual e a ficha correta, sem resultado paralelo.
3. Uma falha é explicada por evento e unidade, com caminho do registro visível.
4. Uma nova tentativa usa sua própria hipótese e suas próprias entradas.
5. A comparação mantém ciência válida, restrições e origem dos dados legíveis.
6. O percurso essencial funciona por teclado, sem arrastar o canvas e com alternativa 2D.
7. Ativos NASA têm crédito e função pedagógica; limites do modelo estão próximos da visualização.

Pitch proposto: “Projetar uma missão é fazer a ciência chegar. No Ipê, você constrói um CubeSat, acompanha os dados do Cerrado e descobre por que uma escolha falhou. Volta à evidência, muda o projeto e vê a diferença. O espaço em 3D torna visível a engenharia que conecta uma pergunta científica à sua resposta.”

Na demonstração, mostrar objetivo → projeto → falha explicada → uma mudança → resultado comparado → dado com procedência. Usar somente casos reproduzidos na versão apresentada. A revisão R13 publica esta especificação e seu estudo interativo; o aceite das novas mecânicas depende das próximas entregas e de verificações próprias.

Documento público. Ler o Markdown desta edição. Estado e curadoria no manifesto da publicação.