Une seule commande, désormais également sous Windows

Le plus gros obstacle : il ne s'installerait pas si vous changiez de plate-forme

Pendant longtemps, son installation et son exécution reposaient sur une pile de scripts bash. Très bien pour macOS et Linux, mais un mur dur pour les utilisateurs de Windows - bash n'est pas natif de Windows, vous avez donc dû soit installer une couche de compatibilité comme Git-Bash, soit rencontrer diverses erreurs cryptiques. Pour un outil qui veut que "n'importe qui transforme ses idées en jeux", "il ne s'installe pas" est le premier refus le plus fatal. Cette journée a corrigé exactement cela : réécrire tous les scripts d'installation et de lancement en gros, de bash vers TypeScript multiplateforme exécuté par Bun. Bun se comporte de manière identique sur les trois principaux systèmes, de sorte que les mêmes commandes et la même logique s'exécutent sous Windows exactement comme sur Mac, sans aucune couche de compatibilité nécessaire.

Les commandes se regroupent en un seul ensemble mémorable

Parallèlement au déménagement, les points d'entrée ont été nettoyés. Les scripts dispersés par plate-forme du passé (.sh, .bat, .ps1, etc.) ont été supprimés ensemble et unifiés en un seul ensemble simple et mémorable : bun run setup pour installer l'environnement une fois, bun run start pour démarrer la pile entière, bun run stop pour l'arrêter, bun run app pour l'application de bureau. Quel que soit le système que vous utilisez, ces quelques éléments sont tout ce dont vous devez vous souvenir. Pour les nouveaux utilisateurs, cela signifie « copiez quatre lignes du fichier README et il s'exécute », sans plus « Je suis sous Windows, contre lequel dois-je l'échanger » ; pour les utilisateurs existants, cela signifie plus de charge de maintenance de "deux copies de chaque script (une sh, une ps1) à éditer en même temps et faciles à manquer". Regrouper plusieurs scripts équivalents en une seule source de vérité multiplateforme est au cœur du travail quotidien : une chose de moins à synchroniser est un endroit de moins où se tromper.

Effacement d'une chaîne de bloqueurs spécifiques à Windows

Pour rendre Windows vraiment fluide, les scripts multiplateformes ne suffisent pas à eux seuls : vous devez également corriger, une par une, les bizarreries qui n'apparaissent que sous Windows. Un cas typique traité aujourd'hui : le "faux" Python du système - Windows fournit un espace réservé python3 qui n'est pas réellement installé et n'ouvre l'App Store que lorsqu'il est invoqué, et un script qui suppose naïvement qu'il fonctionne se bloquera mystérieusement pendant l'installation. Cette journée a appris au flux d'installation à reconnaître et à ignorer cet espace réservé et à trouver un Python qui fonctionne réellement. Des détails comme celui-ci - inexistants sur d'autres systèmes, vous faisant trébucher uniquement sous Windows - constituent la partie la plus complexe mais la plus nécessaire du support multiplateforme : ils n'ajoutent aucune fonctionnalité, mais chaque correction signifie qu'un groupe d'utilisateurs Windows cale une fois de moins et peut continuer.

Les sessions passent de globalement limitées à limitées par jeu

Cette journée a également touché une structure plus interne : à qui appartient une session (une session étant une partie de votre conversation avec Forge). Auparavant, les sessions étaient globales et distinctes de tout jeu spécifique ; ce jour-là, ils les ont imbriqués sous chaque jeu, définis par jeu. Signification : votre conversation avec Forge pour le projet "space shooter" et celle pour le projet "farm sim" sont désormais chacune la leur, sans jamais se confondre. C'est plus intuitif – une conversation appartient en premier lieu à un jeu spécifique – et cela jette les bases d'une gestion de projet plus propre plus tard : changer de jeu, son historique et son contexte de discussion apparaissent, au lieu d'être confrontés à un pot global de sessions mixtes. Ce type de rangement consistant à « classer les données là où elles appartiennent réellement » n'est pas glamour au quotidien, mais il maintient le modèle mental de l'ensemble du système propre.

Importation d'actifs plus stable + une CLI plus rapide et plus contrôlable

La journée a également apporté plusieurs correctifs qui rendent l'utilisation quotidienne plus stable. Sur les actifs, il a résolu un problème d'indexation lors de l'importation de modèles plus grands (les grands maillages ont besoin d'entiers plus larges pour indexer leurs sommets, ce qui échouait ici) et a fait en sorte que les métadonnées écrites lors de l'importation du modèle suivent un format canonique - de sorte que l'importation d'un modèle plus grand et plus complexe ne tombe plus facilement. Le noyau CLI qui pilote l’IA a également bénéficié de plusieurs améliorations : réduction de la redondance pour que le premier tour commence à fonctionner plus rapidement dans certains cas ; résoudre un problème lors de l'injection du « code de conduite » d'un agent ; et l'ajout d'un masquage facultatif des propres outils externes d'un utilisateur ainsi que d'une piste d'audit des appels d'un agent aux outils hôtes - cette dernière signifiant "quels outils l'IA a-t-elle réellement utilisés cette fois-ci" devient traçable dans les enregistrements. Ensemble, cela renforce la base d'une autre couche vers "plus rapide, plus contrôlable, plus fiable".

Ce que signifie cette journée

Le protagoniste de cette journée est « la barrière ». Quelle que soit la puissance d'un outil, si un grand groupe est exclu parce que son système est erroné et qu'il ne s'installe pas, la moitié de sa valeur disparaît avant que quiconque ne l'utilise. Rendre l'installation et le lancement entièrement multiplateforme, afin que les utilisateurs de Windows puissent également l'exécuter avec une seule commande, ouvre cette porte à tout le monde - l'une des conditions préalables pour que "n'importe qui puisse créer des jeux" soit vrai. Et le même jour, le classement des sessions sous leur jeu, la correction de l'importation des actifs pour qu'elle soit stable et le polissage du noyau CLI pour qu'il soit plus rapide et plus auditable ont rangé la pièce pendant que la porte était ouverte. Abaissez la barrière à l’entrée, puis augmentez la qualité à l’intérieur – cette journée a fait les deux.