Compactage du contexte en un clic + solution de repli logicielle WebGPU

Rendre solide « une utilisation large et à long terme »

Une fois la capacité en place, la question suivante est : peut-elle être utilisée à long terme et à grande échelle ? Le long terme signifie si une seule conversation peut durer sans que le contexte ne déborde ; large signifie s'il fonctionne sur toutes sortes de machines, pas seulement sur celle haut de gamme du développeur. Les éléments du jour répondent respectivement à ces deux : le compactage de la conversation en un seul clic indique "le chat assez long atteint le plafond" et le logiciel de secours WebGPU répond "pas de bon GPU signifie un écran noir". Ajoutez le point de départ propre du nouveau jeu, l'animation 2D et un lot de correctifs de robustesse, et le résultat est clair : pas de nouveaux gadgets, mais une « utilisation quotidienne à long terme sur plus de machines » solide.

Compactage en un clic : /compact + un anneau d'utilisation contextuelle

Au cours de longs allers-retours avec un grand modèle, le « contexte » qu'il peut contenir s'accumule ; près de la limite, les réponses sont lentes, la qualité diminue et il commence même à oublier. Ce jour a ajouté une commande /compact : un clic compresse les échanges précédents en un résumé concis, libérant ainsi de l'espace pour continuer, et le compactage lui-même ne brûle pas un tour de conversation entier - il est effectué directement sur le backend. Le compositeur a également obtenu un « anneau d'utilisation contextuelle » qui, comme une jauge de carburant, montre en un coup d'œil combien de budget il reste, de sorte que lorsqu'il est plein, vous pouvez le voir et décider de manière proactive s'il faut le ranger. Avec la saisie semi-automatique des commandes slash, la saisie / fait apparaître toutes les commandes disponibles pour une sélection rapide. Cet ensemble de changements se heurte de plein fouet à la contrainte fondamentale de la « collaboration à long terme avec l’IA » : le contexte est limité ; remettre sa gestion entre les mains de l'utilisateur, avec légèreté, est ce qui rend les longues sessions vraiment durables.

Un logiciel de repli WebGPU : la 3D tourne sur plus de machines

Le rendu 3D dépend des capacités d'un GPU moderne, mais en réalité, certaines machines ou environnements ne peuvent pas bénéficier d'accélération matérielle : peut-être que le GPU est trop ancien, peut-être que le temps d'exécution est limité. Auparavant, cela signifiait un écran noir, excluant complètement ces utilisateurs. Cette journée a ajouté une solution de secours logicielle : lorsqu'un périphérique de rendu accéléré par le matériel ne peut pas être obtenu, le système recule et utilise une implémentation logicielle pour restituer l'image - plus lentement, mais au moins il fonctionne, s'affiche et vous permet de continuer à travailler. En dessous, une solution de repli à plusieurs niveaux a été ajoutée (essayez le chemin suivant en cas d'échec, erreur uniquement en dernier recours), avec des diagnostics plus clairs expliquant pourquoi l'accélération matérielle n'a pas été prise (par exemple, exécutée sous une origine non sécurisée). L'importance réside dans la couverture : une plate-forme destinée au marché de masse, qui souhaite que tout le monde puisse se lancer, ne peut pas supposer que tout le monde possède une machine haut de gamme ; fonctionner sur des machines plus faibles est également ce qui abaisse réellement la barre.

Les nouveaux jeux démarrent à partir d'un modèle ECS propre

La création d'un nouveau jeu est désormais générée à partir d'un modèle propre et bien structuré, organisé selon une architecture appropriée. Aujourd'hui, nous avons réécrit ce modèle par défaut dans un style "d'architecture ECS appropriée", l'avons extrait d'une chaîne en ligne dans un fichier autonome contrôlé par la version et réduit de moitié son nombre de lignes - ce qui signifie qu'au moment où vous créez un jeu, vous obtenez une base propre et compacte prête à être construite, et non une pile de passe-partout que vous devez d'abord comprendre avant de l'éditer. Le modèle et les instructions système transmises à l'IA ont été mis à jour avec les dernières interfaces du moteur. Cela est particulièrement important pour les "jeux d'écriture d'IA" : l'IA continue à partir de la forme du modèle, donc plus le modèle est propre et standard, plus le code de l'IA a de chances d'être correct et plus il est facile à lire et à réutiliser. Un bon point de départ évite d’innombrables corrections ultérieures.

Animation de feuille de sprite 2D

Le moteur a ajouté aujourd'hui une animation de feuille de sprite 2D : lecture de plusieurs images à partir d'une "feuille de sprite" (une série d'images d'action disposées dans une image) en séquence, donnant à l'animation de personnages et d'effets 2D une approche standard prête à l'emploi. Il s’agit de la méthode d’animation la plus courante dans les jeux 2D : une petite silhouette marchant, une flamme vacillante, correspond essentiellement à un cycle rapide de quelques images. Avant cela, le contenu 2D ne pouvait être que des sprites statiques ; avec l'animation de feuille, la ligne 2D peut véritablement bouger. Avec les couches de sprite précédentes, il remplit les principes fondamentaux 2D du moteur : superposition et empilement corrects, ainsi que faire bouger chaque sprite. Pour tous ceux qui souhaitent créer un jeu 2D, il s'agit de l'étape clé entre « pouvoir placer des images » et « pouvoir faire de l'animation ».

Robustesse du moteur : tests de régression + un lot de correctifs de rendu

Le moteur a également effectué un lot de travaux de robustesse peu glamour mais importants ce jour-là. Des tests de régression ont été ajoutés pour plusieurs situations sujettes aux échecs - requêtes de rendu, hiérarchie parent-enfant et cas limite de "pas une seule lumière dans la scène" - en les fixant avec des tests afin que les changements futurs ailleurs ne puissent pas les briser tranquillement. Certains champs aux noms vagues ont été renommés avec plus de précision afin que le code soit plus difficile à mal lire ; et quelques problèmes de compatibilité apparus seulement après la fusion ont été résolus. Il s'agit du travail de "soudure des capacités nouvellement ajoutées" : après avoir intensément ajouté de nombreuses choses au cours des jours précédents, cette journée est revenue pour ajouter des tests et nettoyer les bords, garantissant qu'elles ne "s'exécutent pas seulement une fois" mais "restent fiables à l'avenir". L’alternance d’itérations rapides et de consolidation régulière est la raison pour laquelle cette gamme de produits peut continuer à fonctionner.