Compactação de contexto com um toque + substituto de software WebGPU

Tornar sólido o "uso amplo e de longo prazo"

Uma vez implementada a capacidade, a próxima questão é: ela pode ser usada de forma ampla e de longo prazo? Longo prazo significa se uma única conversa pode durar sem transbordar o contexto; amplo significa se ele roda em todos os tipos de máquinas, não apenas nas de última geração do desenvolvedor. Os itens do dia respondem a estes dois, respectivamente: a compactação de conversa com um toque aborda "bate-papo por tempo suficiente atinge o teto" e o substituto do software WebGPU aborda "nenhuma GPU boa significa uma tela preta". Adicione o ponto de partida limpo do novo jogo, animação 2D e um lote de correções de robustez, e o resultado é claro: não novos truques, mas tornando sólido o "uso diário de longa duração em mais máquinas".

Compactação com um toque: /compact + um anel de uso de contexto

Durante longas idas e vindas com um modelo grande, o “contexto” que ele pode conter se acumula; perto do limite, as respostas ficam lentas, a qualidade cai e até começa a esquecer. Este dia adicionou um comando /compact: um toque comprime as trocas anteriores em um resumo conciso, liberando espaço para continuar, e a compactação em si não queima uma conversa inteira – é feita diretamente no backend. O compositor também ganhou um “anel de uso de contexto” que, como um medidor de combustível, mostra rapidamente quanto orçamento resta, para que quando estiver cheio você possa vê-lo e decidir proativamente se deve arrumar. Com preenchimento automático de comando de barra, digitação/apresenta todos os comandos disponíveis para seleção rápida. Este conjunto de mudanças enfrenta de frente a restrição central da “colaboração de longo prazo com a IA” – o contexto é finito; colocar seu gerenciamento nas mãos do usuário, feito de forma leve, é o que torna as sessões longas verdadeiramente sustentáveis.

Uma alternativa de software WebGPU: 3D é executado em mais máquinas

A renderização 3D depende dos recursos de uma GPU moderna, mas na realidade algumas máquinas ou ambientes não conseguem aceleração de hardware – talvez a GPU seja muito antiga, talvez o tempo de execução seja limitado. Anteriormente, isso significava uma tela preta, excluindo totalmente esses usuários. Este dia adicionou uma alternativa de software: quando um dispositivo de renderização acelerado por hardware não pode ser obtido, o sistema recua e usa uma implementação de software para renderizar a imagem – mais lento, mas pelo menos ele roda, mostra e permite que você continue trabalhando. Por baixo, foi adicionado fallback multinível (tente o próximo caminho quando um falhar, erro apenas como último recurso), com diagnósticos mais claros explicando por que a aceleração de hardware não foi realizada (digamos, rodando em uma origem não segura). O significado é a cobertura: uma plataforma para o mercado de massa, querendo que todos comecem, não pode presumir que todos tenham uma máquina de última geração; rodar em máquinas mais fracas também é o que realmente diminui a fasquia.

Novos jogos começam com um modelo ECS limpo

A criação de um novo jogo agora é gerada a partir de um modelo limpo e bem estruturado, organizado em uma arquitetura adequada. Este dia reescreveu esse modelo padrão em um estilo de “arquitetura ECS adequada”, extraiu-o de uma string inline em um arquivo independente com controle de versão e reduziu pela metade sua contagem de linhas – ou seja, no momento em que você cria um jogo, você obtém uma base limpa e compacta pronta para construir, não uma pilha de clichês que você deve entender primeiro antes de editar. O modelo e as instruções do sistema fornecidas à IA foram atualizados para as interfaces de mecanismo mais recentes. Isso é importante especialmente para "jogos de escrita de IA": a IA continua a partir do formato do modelo, portanto, quanto mais limpo e padronizado for o modelo, maior será a probabilidade de o código da IA ​​estar correto e mais fácil será para você ler e reutilizar. Um bom ponto de partida evita inúmeras correções posteriores.

Animação de planilha 2D

O mecanismo adicionou animação de sprite-sheet 2D neste dia: reproduzindo vários quadros de uma "folha de sprite" (uma série de quadros de ação dispostos em uma imagem) em sequência, dando personagens 2D e animação de efeitos uma abordagem padrão e pronta para uso. Este é o método de animação mais comum em jogos 2D - uma pequena figura andando, uma chama tremeluzindo, são essencialmente alguns quadros circulando rapidamente. Antes disso, o conteúdo 2D só podia ser sprites estáticos; com animação de folha, a linha 2D pode realmente se mover. Juntamente com as camadas anteriores do sprite, ele preenche os fundamentos 2D do mecanismo: camadas e empilhamento corretos, além de fazer com que cada sprite se mova. Para quem deseja fazer um jogo 2D, este é o passo fundamental de “conseguir colocar imagens” para “conseguir fazer animação”.

Robustez do motor: testes de regressão + um lote de correções de renderização

O motor também fez uma série de trabalhos de robustez pouco glamorosos, mas importantes, neste dia. Testes de regressão foram adicionados para diversas situações propensas a falhas – consultas de renderização, hierarquia pai-filho e o caso extremo de “nenhuma luz na cena” – fixando-as com testes para que mudanças futuras em outros lugares não possam quebrá-las silenciosamente. Alguns campos com nomes vagos foram renomeados com mais precisão para que o código seja mais difícil de ser mal interpretado; e alguns problemas de compatibilidade que surgiram somente após a fusão foram corrigidos. Este é o trabalho de “soldar a capacidade recém-adicionada”: depois de adicionar intensamente muitas coisas nos dias anteriores, este dia voltou para adicionar testes e arestas limpas, garantindo que eles não “funcionem apenas uma vez”, mas “permaneçam confiáveis ​​daqui para frente”. Alternar iteração rápida com consolidação constante é o motivo pelo qual esta linha de produtos pode continuar funcionando.