Es kommt eine Desktop-App + eine gemeinsame Spielebibliothek

Von „einem Browser-Tab“ zu „einer echten Anwendung“

Zuvor befand sich Studio in einem Browser-Tab – das heißt, seine Existenz hing von diesem Tab ab: Schließen Sie ihn, aktualisieren Sie ihn oder lassen Sie den Browser abstürzen, und alles, was gerade läuft, ging damit einher. Die Schlagzeile des Tages lautete, es zu einer eigenständigen nativen Desktop-App zu machen und ihr zum ersten Mal „ein eigenes Fenster, einen eigenen Prozess“ zu geben. Um dies herum machten die anderen Linien die Plattform eher zu einem ausgereiften Produkt: mehrere Spiele teilen Inhalte, Agenten können direkter anrufen, die Engine fügt Audio und Multi-Pass-Rendering hinzu, das Repo wird verschlankt. Die Umstellung von „kann im Browser ausgeführt werden“ auf „kann langfristig als Anwendung geöffnet bleiben“ ist die Veränderung, die an diesem Tag am meisten in Erinnerung bleiben sollte.

Eine Desktop-App: Schließen Sie das Frontfenster, Agenten sterben nicht

An diesem Tag wurde die vollständige Hülle für eine Desktop-App bereitgestellt: Studio kann zum ersten Mal als natives Desktop-Fenster geöffnet werden, nicht nur als Browser-Registerkarte. Es verfügte über Prozess-Keep-Alive (Hintergrunddienste über das Fenster hinaus am Leben halten), Fensterverwaltung und korrekte Asset-Root-Auflösung beim Packen des Desktop-Builds. Es gibt der früheren Funktion „Agenten überleben einen geschlossenen Browser“ endlich einen echten Desktop-Eintrag – dieser Keep-Alive befand sich früher im Browser, und jetzt, mit einem nativen Fenster, können Sie ihn langfristig als echte Anwendung offen halten: Arbeiten Sie manuell an Agenten, schließen Sie die Frontoberfläche, und sie laufen im Hintergrund weiter; Öffnen Sie das Fenster, wenn Sie den Fortschritt überprüfen möchten. Ein Formular, das als „Anwendung“ allein stehen kann, ist der entscheidende Schritt vom „Demoprojekt“ zum „Alltagstool“.

Mehrere Spiele teilen sich eine Bibliothek

Mehrere Spiele können jetzt eine Spielbibliothek gemeinsam nutzen: Legen Sie gemeinsame Assets und Komponenten in einer gemeinsam genutzten Bibliothek ab, und jedes Spiel verfügt über einen eigenen „Index“, um darauf zu verweisen – es ist nicht erforderlich, Materialien in jedes Spiel zu kopieren. Für einen Schöpfer, der mehrere Werke langfristig kultiviert, bedeutet dies, dass eine Serie oder mehrere Prototypen dieselben Ressourcen sauber wiederverwenden können, anstatt überall doppelte Kopien zu verstreuen. Damit einher ging eine durchdachte Optimierung: Während der Entwicklung scannt eine Asset-Änderung in einem Spiel nur die Ressourcen „des Spiels, an dem Sie gerade arbeiten“, nicht den gesamten Arbeitsbereich von Grund auf neu – bei vielen Spielen ist das der Unterschied zwischen „wird sofort wirksam“ und „jedes Mal eine Weile warten“. Durch gemeinsames Teilen und lokales erneutes Scannen ist die „Verwaltung vieler Spiele durch eine Person“ sowohl platzsparend als auch schnell erledigt.

Agenten rufen Host-Tools per Whitelist direkt im Chat auf

An diesem Tag wurde ein „Whitelist“-Kanal durchgeschaltet, von der Typdefinition bis zur Laufzeit. Ein Agent kann in seinem Manifest angeben, „welche Host-Tools ich aufrufen darf“, und eine „Host-Tool-Brücke“ fügt diese deklarierten Tools in seine Konversations-Tool-Liste ein; Ein alter, fest codierter Werkzeugsatz wurde unterwegs ausgemustert. Konkret: Der für die Geschichte verantwortliche Agent hat in seiner Whitelist eine Reihe erzählerbezogener Tools deklariert, sodass er direkt im Chat eine ganze Reihe feinkörniger Erzähltools aufrufen kann, um die Handlung zu arrangieren, ohne durch ein separates Kit geleitet zu werden. Der Wert ist „explizite Autorisierung, direkter Aufruf“: Was jeder Agent verwenden kann, ist in seinem Manifest festgelegt – sicher und kontrollierbar, und „einen Agenten mit den Fähigkeiten ausstatten, die er haben sollte“ zu einer deklarativen, wartbaren Sache zu machen. Dies ist die Grundlage für ein Agentensystem mit dem Trend „Jeder kann konfigurieren, jeder mit seinem Fachgebiet“.

Engine: eine Multi-Pass-Render-Pipeline + Audio + umschaltbare AA

Der Motor füllte sich heute in mehreren Teilen. Die Rendering-Abstraktion entwickelte sich zu einer „Multi-Pass“-Pipeline – viele erweiterte visuelle Effekte (insbesondere die Nachbearbeitung) werden im Wesentlichen „in mehreren Schritten, Schicht für Schicht“ berechnet, und mit einer geeigneten Multi-Pass-Struktur können solche Effekte sauber erstellt und nicht überfüllt werden. Anti-Aliasing wurde zur Laufzeit umschaltbar, was den Vergleich zwischen Ein- und Ausschalten erleichtert und beim Optimieren deutlich sichtbar macht. Die Engine erstellte auch eine Audio-Demo, die durchgängig bestätigte, dass „Spiele Sound erzeugen können“ (das Soundsystem war bereits früher integriert worden; heute gab es ein Hörbeispiel). Die Physik hat einen „Leerlauf“-Fehler behoben – einige Objekte waren früher ohne Einwirkung von Kräften an Ort und Stelle eingefroren, und jetzt fallen sie, kollidieren und bewegen sich ordnungsgemäß. Zusammen festigen diese alle drei Erfahrungsbereiche der Engine – Grafik, Sound, Physik – eine weitere Stufe in Richtung „kann wirklich ein komplettes Spiel machen“.

Repo-Verschlankung: Binärdateien aus der Codebasis entfernen

Die Engine hat an diesem Tag auch eine Runde „Repo-Verschlankung“ durchgeführt: Sie hat umfangreiche Binärdateien (Beispielmaterialien, Basisbilder, Build-Artefakte usw.) aus dem Code-Repository gelöscht, sie in ein dediziertes Ressourcen-Repository verschoben oder bei Bedarf neu erstellt und eine kontinuierliche Integrationsprüfung eingerichtet, damit niemand versehentlich Binärdateien wieder in die Codebasis stopft. Für Benutzer unsichtbar, verbessert dies das Entwicklungserlebnis an vorderster Front erheblich: Ein kleineres Repo klont schneller, hat eine sauberere Historie und fühlt sich von Tag zu Tag leichter an. Für ein Projekt, das langfristig weiterentwickelt werden soll, Open-Source ist und von mehr Leuten geklont wird, um loszulegen, ist „nur Code in der Codebasis“ eine Disziplin, die es wert ist, beibehalten zu werden – sie wirkt sich direkt darauf aus, wie lange ein Neuling (oder eine CI-Maschine) wartet und wie viel Platz es braucht, wenn das Projekt zum ersten Mal heruntergefahren wird. Die frühzeitige Beseitigung dieser langfristigen Belastung ist eine Wohltat für alle zukünftigen Mitarbeiter.

Was dieser Tag bedeutet

Das Thema des Tages besteht darin, die Plattform von „einem Ding, das in einem Browser läuft“ zu „einer Anwendung, die man besitzen und langfristig nutzen kann“ zu entwickeln. Die Desktop-Shell gab ihr ein eigenes Fenster und einen eigenen Prozess; Mit der gemeinsam genutzten Spielebibliothek können Sie mehr als ein darin enthaltenes Werk pflegen. Der Whitelist-Tool-Kanal macht das Agentensystem konfigurierbarer und kontrollierbarer. Das Audio der Engine plus Multi-Pass-Rendering und die Repo-Verschlankung verstärken die Enden „Kann bauen“ bzw. „Läuft auf lange Sicht“. Diese anders ausgerichteten Änderungen weisen auf ein Zeichen der Reife hin: Es handelt sich nicht mehr nur um ein Projekt, das zeigt, dass „aus Konversation Spiele entstehen können“, sondern um ein Tool, das Sie auf Ihrem Computer installieren, täglich öffnen und langfristig anvertrauen würden. In dem Moment, in dem es als „Anwendung“ allein stehen kann, ändert sich die Identität des Produkts.