Open any folder as a workspace + in-app version & shortcuts

From "locked to a directory" to "open any project"

Before this, your game code had to live in one of the platform's built-in fixed directories to be managed — a real constraint: it meant your project had to accommodate the tool rather than the tool accommodating your project. This day's through-line was removing that constraint, letting the platform open any directory on disk as a workspace. It looks like a small "pick a folder" feature, but behind it is a loosening of product positioning: from "an app where you must arrange code by its rules" toward "a development platform that can take over your existing project." Together with the version awareness and several polishes added this day, the platform took another solid step toward "being used daily like a proper tool."

Open any folder as a workspace

The top bar gained a project switcher that opens into a file browser, so you can pick any directory on disk as your current workspace — no longer forced to drop code into one built-in folder. Recently opened projects are remembered for one-click return. Even better: if you choose an empty directory, the system drops in a directly-runnable default game scaffold, so "make a new folder → have an agent start working in it" becomes a perfectly smooth path. For someone who just cloned a repo, this means opening their own project's directory and starting right away, without first learning the platform's directory conventions. It genuinely lowers the bar to getting started.

In-app version + changelog + shortcuts

This day gave the app a "sense of version." The status bar now shows the running version and refreshes on its own — it watches the live code version in the background and updates the moment files change, so switching back to the window confirms whether you're on the latest rather than staring at a long-stale number. Settings gained a "Changelog" section so you can read what recently changed inside the product, without going elsewhere. And a "Shortcuts" section with a set of global keyboard shortcuts makes common actions discoverable, memorable and one keypress away. Individually plain, together these signal something: this is no longer a throwaway experiment but a product that keeps updating, is worth using long-term, and takes seriously "how does the user know which version they're on."

Engine: model instancing + build-time texture cooking

The engine advanced on both performance and assets this day. On performance, standard 3D models gained instanced drawing — when the same model appears in bulk in a scene (a row of trees, a crowd of enemies), the engine can draw them all in one submission, sharply cutting cost; importing a model also carries each node's own name into the engine, easing later identification and manipulation. On assets, image textures are now cooked ahead of time at "build time" and fetched by handle at runtime — both faster to load and more stable, without reprocessing on every run. One targets "many objects on screen," the other "fast and stable loading," and together they pave the way for the genuinely complex, content-rich scenes to come.

An engine runtime shell with a game loop takes shape

The engine also filled in a structural foundation this day: a complete "runtime shell" plus a game loop. The runtime shell is responsible for starting a game correctly and driving each frame's update and render at a steady cadence — the engine that makes any game "turn" at the lowest level. Before this, individual examples often assembled this startup-and-loop logic themselves; converging it into a standard shell the engine provides means writing a game can start from a clean, uniform point rather than rebuilding the skeleton each time. This matters especially for "having AI write games": the more standard and predictable the starting point, the more easily the AI's code runs correctly and can be reused.

Small ergonomics: selectable text + a composer right-click menu

This day also smoothed a few everyday frictions. Text in chat can now be selected and copied as expected — which sounds obvious, but it had been unintentionally disabled before, making it inconvenient to pull out a passage of the agent's reply. The composer gained a right-click menu, putting common actions within reach. Each of these is trivial on its own, but they're exactly the layer that decides whether a tool "feels smooth to use." An interface where even copying text is awkward will erode goodwill no matter how strong the capability; smoothing these edges one by one is basic respect for the people who use it every day.

What this day means

The day's pieces together answer a plain question: does this platform deserve to be used long-term as a "proper tool"? Being able to open any project of your own says it's willing to accommodate your existing way of working; having a version number, changelog and shortcuts says it treats itself as a product that keeps evolving and is accountable to users; the engine adding instancing, build-time cooking and a standard runtime shell says the low level is seriously preparing for bigger scenes and more content; and bothering with details like whether text can be copied says it cares about your daily feel. Between "can demo" and "can use daily" lies exactly this kind of unglamorous but indispensable work.