An editor mode gets its roadmap + the engine preps for visual editing

Setting direction, laying foundations, and subtracting — all in one day

The day's items look scattered but orbit one goal: growing a new "editor" leg for Studio. Growing it takes three things at once. First, "set direction" — turning "add an editing mode" from spoken discussion into a formal design blueprint so the coming work has something to follow. Second, "lay foundations" — the engine filling in, at the bottom layer, the capabilities an editor genuinely needs; without them the upper interface is a castle in the air. Third, "subtract" — converging two historically-parallel runtime kernels into one, so the maintenance burden doesn't crush you before the new feature even appears. When a project reaches the threshold of adding a major capability, what's most tested isn't the speed of writing new code but whether you can simultaneously think the direction through, firm up the foundation, and shed the baggage — this day did all three.

An editor mode roadmap: from play-only to edit-and-play

Until now, Studio has mostly been the place to run and play-test a game: you chat with the AI, it writes code, and the right side runs the game for you. This day formally kicked off "add an editing mode," captured as a full set of design and status documents — comparing the engine's existing capabilities, writing down the editing mode's feature spec, taking stock of how far the implementation has come, and offering a concrete design proposal. The goal is clear: you don't just watch a game run but can directly place objects, tweak properties and build scenes in a visual interface — true edit-and-play, where a change shows its effect right beside you at once. Writing it up as a document first, rather than diving straight into code, is because it touches the engine, the front end and the runtime in several places and deserves a clear blueprint before action; all the editor work over the coming days follows this blueprint. It's a signpost for Studio's move from a player's view toward a creator's view — from "the AI builds it for you and you play," toward "the AI and you edit together and you can step in anytime."

Field reflection lands: the property panel can build itself

The engine's key step this day was adding "reflection metadata" to component fields. Reflection, put plainly, lets a program "describe itself": the system no longer needs to be told — it can read, for each property in each component, the name and type — this one's a number, that one's a color, another's a toggle. Why does this matter? Because the heaviest work in a visual editor is drawing an input control for each of hundreds of property kinds: a slider for numbers, a picker for colors, a checkbox for toggles. Hand-writing each one neither finishes nor keeps up with the engine's changes. With field reflection, the editor's property panel can "build itself from the metadata" — add a new property in the engine and the matching control appears in the panel automatically, with no extra handwork. This is exactly the underlying precondition that lets that editor blueprint genuinely land: first make the data self-describing, and only then can the interface be automated.

The render pipeline becomes swappable, so visual style isn't locked

The engine also made the "render pipeline" swappable this day. The render pipeline is the whole assembly line by which the engine turns a 3D scene into each frame on screen — deciding how light falls, how shadows are computed, how post effects stack. This pipeline used to be hardcoded into the engine: you could only use the one visual style it gave. This day exposed the pipeline's "seam," so a project with special visual needs can drop in its own rendering flow and achieve a distinctive look beyond the engine's default. More importantly, the capability was validated by "using it ourselves first" — the engine's own rendering began running through this swappable pipeline, ensuring it's not decorative but genuinely usable. Proactively opening the seam of a core capability means the engine shifts from a "take-it-as-given" black box toward a platform where "advanced users can deeply customize" — especially crucial for creators chasing a distinctive visual identity.

An engine usage manual, written for the AI

The day also did something distinctive: writing an engine usage manual specifically for the AI. On this platform the main force actually writing game code is the AI agent, not a person — so "make the engine usable" must first mean "make it legible and correctly usable to the AI." This manual isn't prose for humans but a structured usage spec for agents plus a set of directly-followable operational skills: how to create entities, attach components, use the asset system, and the correct posture for common tasks, all written in a form an agent can reliably follow. Its significance: a tool's "documentation" is no longer a side note for humans but a means of production that directly determines AI output quality — the better the AI understands the engine, the more correct and less rework-prone the games it writes for you. Treating "the manual for the AI" as a first-class citizen, written in earnest, is a fundamental difference in mindset between this AI-native platform and a traditional engine.

Two runtime kernels converge into one

The day also performed a heavy "subtraction": formally retiring and archiving a historically-leftover standalone runtime kernel, with all the runtime duties it once carried already moved into the unified backend process. This single cut deleted nearly a hundred and fifty thousand lines of code, leaving only an empty shell as a historical marker. Why is this good? Because for a long time the system had two kernels capable of running agents at once, so any change had to be synced on both sides, and a moment's inattention left their behavior inconsistent — an invisible, ongoing maintenance tax. Once converged into a single kernel, all agent flows, capabilities and tools register and run in just one place, with no more "two sides to keep aligned." Deleting a hundred and fifty thousand lines yet making the system more robust confirms a creed running through the whole project: progress isn't measured by lines written but by how many things you must hold in mind to understand and maintain the system — the complexity you can cut is itself the most valuable output.

Game content moves to assets + a replay-order fix

The content side also moved a step with the main line this day: enemies in the sample shooter changed from "spawned one by one in code" to "scene asset instances." The difference between these approaches: enemies hardcoded in code can only be changed by a programmer, while enemies made into structured assets are easier to reuse and configure, and easier for the coming editor to recognize and place — so this too is groundwork for visual editing, letting "things that will be edited" exist in asset form ahead of time. Beyond that, the content-creation tools (node-style editing, scene-building and the like) got a batch of everyday polish: brush tools, a canvas fit-to-view, a scene toolbar, import round-trip fixes and more, making those workbenches smoother to use. A chat replay-ordering issue was also fixed: inter-agent and system messages now append correctly at the tail, so replaying a stretch of history matches exactly the order you saw live — for replay to be trustworthy, the order must be precise to the letter.

What this day means

This day is the textbook look of a project "preparing to pivot": before tackling a big thing, first settling direction, foundation and baggage all at once. The editor blueprint gives "where to go," the engine's field reflection, swappable pipeline and AI manual pave "a road you can actually walk," while kernel convergence and assetization shed "the old baggage that trips you up." Worth remembering: this day had not a single dazzling new button a user could click and play with that very day — its value is all underneath, the kind of "if you don't lay the foundation today, tomorrow's tower can't be built" work. A platform that evolves over the long run depends precisely on being willing to do this groundwork in earnest when there's no instant applause. From this day, the new "editor" leg has its drawings and its foundation; what follows is building it up, layer by layer.