A desktop app arrives + a shared game library

From "a browser tab" to "a real application"

Before this, Studio lived in a browser tab — meaning its existence depended on that tab: close it, refresh, or have the browser crash, and everything in progress went with it. The day's headline was making it a standalone native desktop app, giving it "its own window, its own process" for the first time. Around this, the other lines made the platform more like a mature product: multiple games sharing content, agents calling capability more directly, the engine adding audio and multi-pass rendering, the repo slimming down. Upgrading "can run in a browser" to "can stay open as an application long-term" is the transformation this day most deserves to be remembered for.

A desktop app: close the front window, agents don't die

This day stood up the full shell for a desktop app: Studio can open as a native desktop window for the first time, not just a browser tab. It came with process keep-alive (keeping background services alive beyond the window), window management, and correct asset-root resolution when packaging the desktop build. It finally gives the earlier "agents survive a closed browser" capability a real desktop entry — that keep-alive used to be inside the browser, and now, with a native window, you can keep it open as a real application long-term: hand work to agents, close the front interface, and they keep running in the background; open the window when you want to check progress. A form that can stand alone as an "application" is the key leap from "demo project" to "everyday tool."

Multiple games share one library

Multiple games can now share one game library: put common assets and components into a shared library, and each game carries its own "index" to reference them — no need to copy materials into every game. For a creator cultivating multiple works long-term, this means a series, or several prototypes, can cleanly reuse the same resources rather than scattering duplicate copies everywhere. A thoughtful optimization came with it: during development, an asset change in one game only rescans the resources of "the game you're currently working on," not the whole workspace from scratch — with many games, that's the difference between "takes effect instantly" and "wait a while every time." Sharing plus local rescan together make "one person managing many games" both space-efficient and snappy.

Agents call host tools by whitelist, right in chat

This day wired a "whitelist" channel through, from type definitions all the way to runtime. An agent can declare in its manifest "which host tools I'm allowed to call," and a "host-tool bridge" injects those declared tools into its conversation tool list; an old, hardcoded tool kit was retired along the way. Concretely: the agent responsible for story declared a set of narrative-related tools in its whitelist, so it can call a whole set of fine-grained narrative tools right in chat to arrange the plot, without routing through a separate kit. The value is "explicit authorization, direct invocation": what each agent can use is spelled out in its manifest — safe and controllable, and making "equip an agent with the capabilities it should have" a declarative, maintainable thing. This is the basis for an agent system trending toward "anyone can configure, each with its specialty."

Engine: a multi-pass render pipeline + audio + toggleable AA

The engine filled in several pieces this day. The rendering abstraction grew into a "multi-pass" pipeline — many advanced visual effects (especially post-processing) are essentially computed "in several steps, layer over layer," and with a proper multi-pass structure such effects get a clean way to be built rather than crammed in. Anti-aliasing became runtime-toggleable, making it easy to compare on versus off and obvious while tuning. The engine also built an audio demo, validating "games can make sound" end to end (the sound system had been integrated earlier; this day got an audible sample). Physics fixed an "idle" bug — some objects used to be frozen in place under no forces, and now they fall, collide and move properly. Together, these firm up all three of the engine's experience lines — visuals, sound, physics — another notch toward "can genuinely make a complete game."

Repo slimming: getting binaries out of the codebase

The engine also did a round of "repo slimming" this day: clearing bulky binary assets (sample materials, baseline images, build artifacts, etc.) out of the code repository, moving them to a dedicated resource repo or rebuilding them on demand, and establishing a continuous-integration check so no one accidentally stuffs binaries back into the codebase. Invisible to users, this genuinely improves the front-line dev experience: a smaller repo clones faster, has a cleaner history, and feels lighter day to day. For a project meant to evolve long-term, open-sourced, and cloned by more people to get started, "only code in the codebase" is a discipline worth keeping — it directly affects how long a newcomer (or a CI machine) waits and how much space it takes when first pulling the project down. Clearing this long-term burden early is a kindness to all future collaborators.

What this day means

The day's theme is growing the platform from "a thing running in a browser" into "an application you can own and use long-term." The desktop shell gave it its own window and process; the shared game library lets you cultivate more than one work inside it; the whitelist tool channel makes the agent system more configurable and controllable; the engine's audio plus multi-pass rendering and the repo slimming reinforce the "can build" and "runs for the long haul" ends respectively. These differently-aimed changes point at one mark of maturity: it's no longer just a project demonstrating that "conversation can make games," but a tool you'd install on your computer, open daily and entrust long-term. The moment it can stand alone as an "application," the product's identity changes.