Animated agent avatars + one source of truth for project data
This day was a watershed: game-project data was converged into a single source of truth, with the whole platform reading and writing config through one unified entry; each agent gained, in the workbench, an animated avatar that shifts with its state; a "host page ↔ engine" contract and screen-projection capability landed; and through this big integration, several engine rendering bugs surfaced by real games were cleared at once.
Converging the foundation while adding warmth
Two temperaments coexisted this day. One is the cool "convergence": unifying the scattered, every-part-for-itself logic for reading game-project data into a single authoritative entry; aligning the whole platform onto one engine mainline; clearing several engine bugs surfaced by real games at once. These deduplicate and disambiguate the foundation, making the whole system more reliable and maintainable. The other is the warm "addition": giving each agent an animated avatar that changes with its state, so the abstract matter of "collaborating with a team of AIs" gains, on screen, a human presence for the first time. A good platform needs both the composure to converge complexity into simplicity and the care to let a cold system show a little humanity. This day placed both temperaments together — firming the unseen foundation and lighting up the visible details.
Game-project data gets a single source of truth
The weightiest thing this day was converging each game's project configuration (the core file describing "what this game is called, which resources it uses, which scene it starts from") into a "single source of truth." The prior pain was typical: each part of the platform — backend, editor, play side — read this file separately, hand-wrote its own parsing, and wrote its own error-handling; the moment the file's format or fields quietly changed, no one could guarantee every place reading it kept up, planting the hazard of mismatched fields. This day fully unified it: the whole platform reads and writes project data through one authoritative entry only, and the configuration's format describes itself with a machine-validatable spec — that is, what the file looks like, what fields it has, and each field's type are all made clear by the spec itself, no longer relying on scattered docs and word of mouth. The chance was also taken to adopt a cleaner new format: a version number (for smooth upgrades later) and stable identifiers for referencing resources (rather than easily-changing names). The essence is a core creed running through the whole project — a single fact should have only one authoritative source. Setting an authoritative manual for the workbench's "project file" buys project data that is more reliable, consistent everywhere, and diagnosable in one place.
Each agent gets an animated avatar
This day added a humanizing detail to the workbench: each agent is no longer a static image but an animated avatar that shifts with its state — different animations for thinking, working and idle. This came together across four parts: a set of finished animated character avatars, the rendering that plays them in the workbench, a backend state machine that switches the avatar by the agent's current state, and the interface tying it all together. Why is an "animated avatar" worth building deliberately? Because the platform's core experience is directing a team of differently-tasked AI agents to collaborate (planners, designers, coders...), and when they're all just static icons, it's hard to intuit "who's busy now, with what." With avatars that change by state, a glance conveys the "a room full of people each at their own work" presence: who's deliberating, who's running a job, who's waiting. It gives the once-abstract matter of "collaborating with a team of AIs" warmth and life on screen for the first time — a seemingly "just pretty" detail that actually directly shapes how people perceive and trust this collaborative relationship.
A host-page ↔ engine contract + screen projection
The engine also established a "host-page ↔ engine" contract this day and added a very practical capability: projecting a point in the 3D world to its 2D coordinate on screen. The contract first: a game runs in the engine, wrapped by a web interface (the host) outside it, and the two need a clear agreement on "who can ask whom for what, passing what" — writing this agreement down explicitly means collaboration across that boundary no longer relies on tacit understanding and guessing. Screen projection next: it solves a very common need — how to "pin" a UI element above a 3D object? Such as a health bar floating over an enemy's head, a name tag following a character, an interaction prompt appearing beside an item. Achieving these requires converting that 3D object's world position, in real time, into its current 2D landing point on screen. This day made this world-to-screen conversion a standard engine capability, with camera auto-fit to the picture's aspect ratio and a video-cutscene demo alongside. Together these give reliable underpinning to "overlaying a 2D information layer atop a 3D picture" — something nearly every game must do.
Engine bugs surfaced by real games, fixed at once
As project data unified, the whole platform also fully aligned onto one engine mainline this day. This big integration brought an unexpected but valuable gain: several engine issues previously surfaced while building real games were confirmed fixed at once — including large-scene shadows, a class of data writes, resource-identifier collisions, and solid-color ambient light, four concrete problems. This confirms a healthy collaborative loop: stress-testing the underlying engine with real games often surfaces real problems that abstract tests can't; recording them faithfully, driving the fixes, and confirming they land makes the engine ever more solid through rounds of real use. This day the editor and all six sample games were migrated to the engine's new interface too. The benefit of unification is obvious: behavior is consistent everywhere, problems are easier to trace, and new features can be "built once and take effect everywhere," with no juggling compatibility across forked versions. Converging the scattered into the unified looks like mere tidying but actually clears the obstacles for all the fast iteration that follows.
What this day means
The day's keywords are "unification" and "humanity." Unification shows in converging project data into a single source of truth, aligning the platform onto one engine, and writing cross-boundary collaboration into an explicit contract — all eliminating ambiguity and duplication, keeping an ever-larger system understandable and maintainable. This convergence is unseen and unglamorous, yet the inner work that lets a system grow healthily long-term; it follows that plain but fundamental principle: a single fact should have only one authoritative source. And "humanity" shows in those animated agent avatars — when what you face is no longer cold icons but a team of companions seemingly each genuinely busy, human-AI collaboration gains a layer of emotional connection. A truly good tool must both set order seamlessly underneath and make people comfortable, even happy, to use on top. This day attended to both.