A new asset browser + smoother first-run onboarding

Pushing on both ends: catching newcomers, supporting veterans

This day's work splits into two directions, each for a kind of user. One end is "catching newcomers": the first-run guide was redone to be smoother, getting a never-before-seen visitor fastest from "open it" to "chatting with the AI to make a game." The other end is "supporting veterans": a new asset browser, an editing flow that reliably saves changes back to disk, a telemetry panel making all runtime state observable — all for those already seriously working on projects, who need not "can I get started" but "is the tool handy and reliable enough." A platform just open-sourced and welcoming all sorts of users needs exactly to push on both ends: shaving the entry steps flat and equipping the workbench inside. This day was just such a two-way push.

A new asset browser: dual-pane + thumbnails + hand a batch to the AI

The asset browser was upgraded to a second generation this day and made the default. It's a complete, professional-grade material-management panel: favorites and a folder tree on the left for organizing by directory and pinning frequently-used items; a content area with thumbnails and rich hover tooltips on the right so you recognize each material at a glance; add, import, delete and save-all all in place, plus keyboard shortcuts so, once practiced, you can organize efficiently without leaving the keyboard. The most imaginative part is that it's wired to the AI: you can select a batch of assets in the browser and hand them all to the chat AI as references in one click — where you previously had to describe one by one which models and which texture you wanted the AI to "use in the scene," now you pick them in the browser and pass them over, and the AI knows exactly which assets you mean. This stitches together "managing materials" and "directing the AI," two previously separate things, making "I have these things in hand → help me use them" one smooth continuous action.

A smoother first run: two steps, three ways to connect

The first-run setup guide was redone this day, its core goal to make the step newcomers most easily get stuck on as effortless as possible. The new guide is only two steps, offering three connection paths to choose from: it defaults to an aggregated model entry, the friendliest to newcomers and runnable with the least configuration, while keeping other paths for those who need them. The key design is "never blocking" — you needn't be forced to fill everything on the first screen before entering; you can skip first, look around inside, and come back to fill it in when you want. The guide itself is bilingual. Why is a "setup guide" worth deliberate polish? Because for a never-before-seen visitor, the first few minutes after opening are the watershed of staying or leaving: once the flow is cumbersome, once it stalls somewhere, once you can't tell what the next step is, people leave. Shaving this threshold to "two steps, skippable, with a default recommendation" is the utmost effort to let everyone willing to click in smoothly reach the "start using" step.

The editor completes the "open project → edit → save to disk" loop

The editor completed this day a key loop that turns it from "can view and tune" into genuinely "usable for creation": open a project, edit, and reliably save changes back to disk. Several things landed: support for an "open a project" authoring flow that correctly loads the game's entry and scene assets; a switch to "manual save" — dropping the previous automatic timed save for a clear "unsaved" marker, so you know whether current changes are saved and decide when to persist; a writeback chain from in-editor changes to disk files, with hot reload so changes show instantly yet save safely. The editor also gained a "systems panel" (toggling each logic system in the game) and an "add component" menu in the inspector. Together these mean the editor is no longer just an auxiliary view for fine-tuning but a real tool that independently carries the full "open → edit → save" creative loop. The most fundamental sense of security for a creator is "what I change is saved and recoverable" — and this day made that security real.

Observability: a telemetry/log panel + a chat anti-freeze

This day added "observability" to the whole system — letting you see what's actually happening inside it. A telemetry panel was added, gathering "traces + logs" into one observable feed: what an agent is doing at the moment, how long each step took, and what went wrong are all visible in it. The backend got a matching telemetry sink and reporting route, and the front end gained a monitoring scaffold. Why build this deliberately? Because as more work is pushed autonomously by AI, "what is it actually doing, where is it slow, where did it err" becomes a question that must be visible — invisible, it can be neither trusted nor optimized. Meanwhile, the chat fixed a real freeze risk: when the AI outputs very long, formatted Markdown, the front end keeps re-parsing and rendering, frequently enough to blow up memory and freeze the whole interface; this day throttled it so long answers stay stable as they stream. A transparent system that withstands long, intense use is what lets people confidently hand it big tasks to run.

Engine: unified handles + instanced drawing + a unified plugin protocol

The engine did several far-reaching low-level things this day. One: unifying "handles." A handle is a program's reference to an entity or asset (a grip pointing at something), and this day unified entity and asset handles into one encoding carrying "generational" info — a generation being a version stamp on each handle, so when the thing it points to has been destroyed and its slot reused by something new, the system immediately recognizes "this is a stale old reference" rather than mistaking it as valid. This eliminates at the source the extremely subtle, hard-to-diagnose class of bugs where you "reference something that's already gone." Two: instanced-drawing optimization — when a scene has many identical objects (a forest, a crowd of soldiers), drawing commands used to be issued one by one, and this day merged the identical ones into a bucket drawn in one call, sharply cutting draw calls — a qualitative change for large-scene performance, verified with a stress test of tens of thousands of independent objects. Three: unifying the plugin protocol into one form for more consistent extension, plus a headless clean backend for testing. These are under-the-hood work users don't see yet that decides how big the platform can run, how far it extends, and how few errors it makes.

What this day means

What's most memorable about this day is that it attended to both ends of a user journey at once. For the newcomer clicking in for the first time because of the open-sourcing, it shaved the "entry" threshold to the lowest — a two-step guide, skippable, with a default recommendation, doing its best to let everyone willing to try start smoothly. For creators already seriously working on projects, it equipped the "work" tools more fully — a professional asset browser, an editing loop that reliably saves, a telemetry panel that sees inside. And the engine-level handle unification, instanced drawing and unified plugin protocol provide, deeper down, the support for all of this to be "large-scale, extensible, reliable." For a product to truly hold, catching newcomers isn't enough — those who stay must find it smoother the more they use it; satisfying veterans isn't enough — newcomers must be able to get in. This day rarely did both together — opening the door and equipping the house alike.