Um modo de editor obtém seu roteiro + o mecanismo se prepara para edição visual

Definir direção, estabelecer bases e subtrair – tudo em um dia

Os itens do dia parecem dispersos, mas orbitam em torno de um objetivo: desenvolver uma nova perna de “editor” para o Studio. Crescer requer três coisas ao mesmo tempo. Primeiro, “definir a direção” – transformar “adicionar um modo de edição” da discussão falada em um projeto de design formal para que o próximo trabalho tenha algo a seguir. Em segundo lugar, "estabelecer as bases" - o mecanismo preenchendo, na camada inferior, os recursos que um editor realmente precisa; sem eles, a interface superior é um castelo no ar. Terceiro, "subtrair" — convergir dois kernels de tempo de execução historicamente paralelos em um, para que a carga de manutenção não o esmague antes mesmo de o novo recurso aparecer. Quando um projeto atinge o limite de adicionar uma capacidade importante, o que é mais testado não é a velocidade de escrever novo código, mas se você pode simultaneamente pensar na direção, firmar a base e se livrar da bagagem – este dia fez todos os três.

Um roteiro do modo editor: de apenas reproduzir a editar e reproduzir

Até agora, o Studio tem sido principalmente o lugar para executar e testar um jogo: você conversa com a IA, ela escreve o código e o lado direito executa o jogo para você. Este dia começou formalmente com "adicionar um modo de edição", capturado como um conjunto completo de documentos de design e status - comparando os recursos existentes do mecanismo, anotando as especificações de recursos do modo de edição, avaliando o quão longe a implementação chegou e oferecendo uma proposta de design concreta. O objetivo é claro: você não apenas assiste ao jogo, mas pode posicionar objetos diretamente, ajustar propriedades e construir cenas em uma interface visual - verdadeiro editar e jogar, onde uma mudança mostra seu efeito ao seu lado de uma só vez. Escrevê-lo primeiro como um documento, em vez de mergulhar diretamente no código, é porque ele afeta o mecanismo, o front-end e o tempo de execução em vários lugares e merece um plano claro antes da ação; todo o trabalho do editor nos próximos dias segue esse modelo. É um sinal para a mudança do Studio da visão do jogador para a visão do criador - de "a IA constrói para você e você joga" em direção a "a IA e você edita juntos e pode intervir a qualquer momento".

Terras de reflexão de campo: o painel de propriedades pode ser construído sozinho

A principal etapa do mecanismo neste dia foi adicionar “metadados de reflexão” aos campos dos componentes. A reflexão, dito claramente, permite que um programa "descreva a si mesmo": o sistema não precisa mais ser informado - ele pode ler, para cada propriedade em cada componente, o nome e o tipo - este é um número, aquele é uma cor, outro é uma alternância. Por que isso importa? Porque o trabalho mais pesado em um editor visual é desenhar um controle de entrada para cada uma das centenas de tipos de propriedades: um controle deslizante para números, um seletor de cores, uma caixa de seleção para alternar. A escrita à mão de cada um não termina nem acompanha as mudanças do motor. Com a reflexão de campo, o painel de propriedades do editor pode “construir-se a partir dos metadados” – adicione uma nova propriedade no mecanismo e o controle correspondente aparece no painel automaticamente, sem nenhum trabalho manual extra. Esta é exatamente a pré-condição subjacente que permite que o projeto do editor realmente chegue: primeiro torne os dados autodescritivos e só então a interface poderá ser automatizada.

O pipeline de renderização torna-se trocável, portanto o estilo visual não fica bloqueado

O mecanismo também tornou o “pipeline de renderização” trocável neste dia. O pipeline de renderização é toda a linha de montagem pela qual o mecanismo transforma uma cena 3D em cada quadro da tela – decidindo como a luz incide, como as sombras são calculadas, como os pós-efeitos se acumulam. Esse pipeline costumava ser codificado no mecanismo: você só podia usar o estilo visual que ele fornecia. Este dia expôs a “costura” do pipeline, para que um projeto com necessidades visuais especiais possa entrar em seu próprio fluxo de renderização e obter uma aparência distinta além do padrão do mecanismo. Mais importante ainda, a capacidade foi validada "usando-a nós mesmos primeiro" - a própria renderização do motor começou a correr através deste pipeline trocável, garantindo que não fosse decorativo, mas genuinamente utilizável. Abrir proativamente a junção de uma capacidade central significa que o mecanismo muda de uma caixa preta de “aceitar como dado” para uma plataforma onde “usuários avançados podem personalizar profundamente” – especialmente crucial para criadores que buscam uma identidade visual distinta.

Um manual de uso do motor, escrito para a IA

O dia também fez algo diferenciado: escrever um manual de uso do motor especificamente para a IA. Nesta plataforma, a principal força que realmente escreve o código do jogo é o agente de IA, não uma pessoa - portanto, "tornar o mecanismo utilizável" deve primeiro significar "torná-lo legível e utilizável corretamente para a IA". Este manual não é uma prosa para humanos, mas uma especificação de uso estruturada para agentes, além de um conjunto de habilidades operacionais que podem ser seguidas diretamente: como criar entidades, anexar componentes, usar o sistema de ativos e a postura correta para tarefas comuns, tudo escrito de uma forma que um agente possa seguir com segurança. Seu significado: a “documentação” de uma ferramenta não é mais uma observação lateral para os humanos, mas um meio de produção que determina diretamente a qualidade da saída da IA ​​– quanto melhor a IA entende o motor, mais corretos e menos sujeitos a retrabalho serão os jogos que ela escreve para você. Tratar “o manual da IA” como um cidadão de primeira classe, escrito com seriedade, é uma diferença fundamental de mentalidade entre esta plataforma nativa de IA e um motor tradicional.

Dois kernels de tempo de execução convergem em um

O dia também realizou uma "subtração" pesada: aposentar formalmente e arquivar um kernel de tempo de execução autônomo historicamente remanescente, com todas as tarefas de tempo de execução que ele carregava já transferidas para o processo de back-end unificado. Esse único corte excluiu quase cento e cinquenta mil linhas de código, deixando apenas um shell vazio como marcador histórico. Por que isso é bom? Porque durante muito tempo o sistema teve dois kernels capazes de executar agentes ao mesmo tempo, então qualquer mudança tinha que ser sincronizada em ambos os lados, e um momento de desatenção deixava seu comportamento inconsistente – uma taxa de manutenção contínua e invisível. Uma vez convergidos em um único kernel, todos os fluxos de agentes, recursos e ferramentas são registrados e executados em um único local, sem mais “dois lados para manter alinhados”. Excluir cento e cinquenta mil linhas e ainda tornar o sistema mais robusto confirma um credo que permeia todo o projeto: o progresso não é medido pelas linhas escritas, mas por quantas coisas você deve ter em mente para compreender e manter o sistema — a complexidade que você pode eliminar é em si o resultado mais valioso.

O conteúdo do jogo passa para ativos + uma correção na ordem de repetição

O lado do conteúdo também deu um passo em relação à linha principal deste dia: os inimigos no jogo de tiro de amostra mudaram de “gerados um por um no código” para “instâncias de ativos de cena”. A diferença entre essas abordagens: os inimigos codificados em código só podem ser alterados por um programador, enquanto os inimigos transformados em ativos estruturados são mais fáceis de reutilizar e configurar, e mais fáceis de serem reconhecidos e colocados pelo próximo editor - portanto, isso também é uma base para a edição visual, permitindo que "coisas que serão editadas" existam na forma de ativos com antecedência. Além disso, as ferramentas de criação de conteúdo (edição de estilo de nó, construção de cena e similares) receberam um monte de polimento diário: ferramentas de pincel, uma tela ajustada à visualização, uma barra de ferramentas de cena, importação de correções de ida e volta e muito mais, tornando essas bancadas de trabalho mais fáceis de usar. Um problema de ordem de repetição do bate-papo também foi corrigido: mensagens entre agentes e do sistema agora são anexadas corretamente no final, portanto, a repetição de um trecho do histórico corresponde exatamente à ordem que você viu ao vivo – para que a reprodução seja confiável, a ordem deve ser precisa ao pé da letra.

O que este dia significa

Este dia é a aparência clássica de um projeto “preparando-se para girar”: antes de enfrentar uma grande coisa, primeiro estabeleça a direção, a base e a bagagem, tudo de uma vez. O projeto do editor fornece "para onde ir", a reflexão de campo do mecanismo, o pipeline trocável e o manual de IA pavimentam "uma estrada que você pode realmente percorrer", enquanto a convergência e a ativos do kernel eliminam "a velha bagagem que o atrapalha". Vale a pena lembrar: este dia não tinha um único botão novo e deslumbrante em que um usuário pudesse clicar e brincar naquele mesmo dia - seu valor está todo subjacente, o tipo de trabalho "se você não lançar as bases hoje, a torre de amanhã não poderá ser construída". Uma plataforma que evolui no longo prazo depende precisamente de estar disposto a fazer esse trabalho de base com seriedade quando não há aplausos instantâneos. A partir de hoje, a nova perna “editora” tem seus desenhos e seus fundamentos; o que se segue é construí-lo, camada por camada.