Chega um aplicativo de desktop + uma biblioteca de jogos compartilhada

De “uma guia do navegador” a “um aplicativo real”

Antes disso, o Studio vivia em uma aba do navegador – o que significa que sua existência dependia dessa aba: fechá-lo, atualizar ou fazer com que o navegador travasse, e tudo em andamento acontecia com ele. A manchete do dia era torná-lo um aplicativo de desktop nativo independente, dando-lhe “sua própria janela, seu próprio processo” pela primeira vez. Em torno disso, as outras linhas tornaram a plataforma mais parecida com um produto maduro: vários jogos compartilhando conteúdo, capacidade de chamada de agentes mais diretamente, o mecanismo adicionando áudio e renderização multi-passagem, o repo diminuindo. Atualizar “pode ser executado em um navegador” para “pode permanecer aberto como um aplicativo por longo prazo” é a transformação pela qual este dia mais merece ser lembrado.

Um aplicativo de desktop: feche a janela frontal, os agentes não morrem

Este dia apresentou o shell completo para um aplicativo de desktop: o Studio pode abrir como uma janela nativa da área de trabalho pela primeira vez, não apenas como uma guia do navegador. Ele veio com processo keep-alive (mantendo os serviços de segundo plano ativos além da janela), gerenciamento de janelas e resolução correta da raiz do ativo ao empacotar a construção do desktop. Finalmente, ele oferece ao recurso anterior "agentes sobrevivem a um navegador fechado" uma entrada real na área de trabalho - aquele keep-alive costumava estar dentro do navegador e agora, com uma janela nativa, você pode mantê-la aberta como um aplicativo real por longo prazo: trabalho manual para os agentes, feche a interface frontal e eles continuarão executando em segundo plano; abra a janela quando quiser verificar o progresso. Um formulário que pode ser considerado um "aplicativo" sozinho é o salto fundamental do "projeto de demonstração" para a "ferramenta do dia a dia".

Vários jogos compartilham uma biblioteca

Vários jogos agora podem compartilhar uma biblioteca de jogos: coloque recursos e componentes comuns em uma biblioteca compartilhada, e cada jogo carrega seu próprio “índice” para referenciá-los – sem necessidade de copiar materiais em cada jogo. Para um criador que cultiva vários trabalhos a longo prazo, isso significa que uma série, ou vários protótipos, pode reutilizar de forma limpa os mesmos recursos, em vez de espalhar cópias duplicadas por toda parte. Uma otimização cuidadosa veio com isso: durante o desenvolvimento, uma alteração de ativos em um jogo apenas verifica novamente os recursos do “jogo em que você está trabalhando atualmente”, e não todo o espaço de trabalho do zero – com muitos jogos, essa é a diferença entre “entra em vigor instantaneamente” e “espera um pouco de cada vez”. O compartilhamento e a nova verificação local juntos tornam "uma pessoa gerenciando muitos jogos" eficiente em termos de espaço e rápido.

Os agentes ligam para ferramentas de host por lista de permissões, diretamente no chat

Este dia conectou um canal de "lista de permissões", desde as definições de tipo até o tempo de execução. Um agente pode declarar em seu manifesto "quais ferramentas de host posso chamar" e uma "ponte de ferramenta de host" injeta essas ferramentas declaradas em sua lista de ferramentas de conversação; um kit de ferramentas antigo e codificado foi retirado ao longo do caminho. Concretamente: o agente responsável pela história declarou um conjunto de ferramentas relacionadas à narrativa em sua lista de permissões, para que possa chamar todo um conjunto de ferramentas narrativas refinadas diretamente no chat para organizar o enredo, sem passar por um kit separado. O valor é “autorização explícita, invocação direta”: o que cada agente pode usar está explicitado em seu manifesto – seguro e controlável, e tornando “equipar um agente com os recursos que ele deveria ter” algo declarativo e sustentável. Esta é a base para um sistema de agentes que tende a “qualquer um pode configurar, cada um com sua especialidade”.

Mecanismo: pipeline de renderização multipassagem + áudio + AA alternável

O motor encheu vários pedaços neste dia. A abstração de renderização cresceu para um pipeline de "passagem múltipla" - muitos efeitos visuais avançados (especialmente pós-processamento) são essencialmente computados "em várias etapas, camada sobre camada" e com uma estrutura de passagem múltipla adequada, tais efeitos obtêm uma maneira limpa de serem construídos em vez de amontoados. O motor também construiu uma demonstração de áudio, validando “jogos podem produzir som” de ponta a ponta (o sistema de som já havia sido integrado; neste dia ganhou uma amostra audível). A física corrigiu um bug de “inatividade” – alguns objetos costumavam ficar congelados no lugar sem nenhuma força, e agora caem, colidem e se movem corretamente. Juntos, eles fortalecem todas as três linhas de experiência do motor - visuais, som, física - outro degrau em direção a "pode ​​​​genuinamente fazer um jogo completo".

Repo emagrecimento: tirando binários da base de código

O mecanismo também fez uma rodada de "repo slimming" neste dia: limpando ativos binários volumosos (materiais de amostra, imagens de linha de base, artefatos de construção, etc.) do repositório de código, movendo-os para um repositório de recursos dedicado ou reconstruindo-os sob demanda e estabelecendo uma verificação de integração contínua para que ninguém acidentalmente coloque binários de volta na base de código. Invisível para os usuários, isso melhora genuinamente a experiência de desenvolvimento da linha de frente: um repositório menor clona mais rápido, tem um histórico mais limpo e parece mais leve no dia a dia. Para um projeto destinado a evoluir a longo prazo, de código aberto e clonado por mais pessoas para começar, "apenas código na base de código" é uma disciplina que vale a pena manter - afeta diretamente quanto tempo um recém-chegado (ou uma máquina de CI) espera e quanto espaço é necessário ao desligar o projeto pela primeira vez. Eliminar antecipadamente esse fardo de longo prazo é uma gentileza para todos os futuros colaboradores.

O que este dia significa

O tema do dia é transformar a plataforma de “uma coisa rodando em um navegador” para “um aplicativo que você pode possuir e usar a longo prazo”. O shell da área de trabalho deu a ele sua própria janela e processo; a biblioteca de jogos compartilhada permite cultivar mais de uma obra dentro dela; o canal de ferramentas da lista branca torna o sistema do agente mais configurável e controlável; o áudio do motor mais a renderização multi-pass e o repo slimming reforçam os fins "pode ​​construir" e "funcionar para o longo prazo", respectivamente. Essas mudanças com objetivos diferentes apontam para um marco de maturidade: não é mais apenas um projeto que demonstra que “a conversa pode criar jogos”, mas uma ferramenta que você instalaria em seu computador, abriria diariamente e confiaria a longo prazo. No momento em que ele pode ser considerado um “aplicativo”, a identidade do produto muda.