Project kickoff

Why day one starts from the rendering foundation

This is day one of the platform's public record. For a platform where "you chat and a game appears," one thing must hold true at the very bottom: the browser has to render 3D — genuinely and stably. So day one wasn't about piling on a flashy interface; it put all the effort into the hardest part, the rendering foundation: building a rendering pipeline directly on the browser's next-generation graphics capability (WebGPU) in-house, rather than wrapping an off-the-shelf general library. That path is harder and slower at first — many details others have packaged away must be walked through ourselves, and the pitfalls filled one by one. But it decides whether image quality, performance and features stay in our own hands later, instead of being throttled by an upstream library's trade-offs. Today's deliverables are really different faces of one big thing — "lighting the first pixel correctly in a browser." Getting this most-underestimated, least-compromisable thing solid first is what gives every later dream of "generating games by conversation" a place to stand.

A working shader pipeline: WGSL + a shader-compile shim + simplified PBR

The core of rendering is the shader — the little program that tells the GPU "what color each pixel should be." This day wired a whole shader pipeline together: written in the browser graphics standard's shader language (WGSL), paired with a compile shim that turns shader source into a GPU-executable format in place, plus a simplified physically-based shading (PBR) implementation. "Physically based" means materials react to light by real-world rules — metal looks like metal, plastic like plastic, not a colored paper cutout. This simplified PBR deliberately uses a lean resource-binding structure (just three bind groups) to stay light while keeping the image believable — easy to understand and easy to extend. The compile shim matters especially: WebGPU doesn't directly consume high-level shader source, so a translation step into a lower-level format is needed in between, and solving it in the browser is what makes "write a shader and immediately see the result" possible. From this day, the engine no longer merely tints triangles; it renders objects that are lit and have material — the key first step from "can draw" to "draws correctly," and the right starting point for all the richer materials and lighting to follow.

The rendering device layer taken over end to end

For shaders to run, there must be a "rendering device layer" underneath handling everything: requesting GPU resources, managing the canvas surface, organizing each frame's draw commands and submitting them to the GPU. This day took that layer over completely from start to finish, verifying the whole chain stage by stage — from initial setup to stably producing frame after frame, a series of milestones all ticked off. Players never see this layer, but it's the steward of all rendering: when it's solid, the games above it are solid; when it has holes, even the prettiest effects randomly black out or crash. Many rendering issues look like a broken effect on the surface, but the root is really this layer not being sorted out. Making it staged and verifiable has a long-term payoff too: when a future frame goes wrong, you can trace back through these milestones to pin which link broke, rather than staring helplessly at a black screen. Making it sturdy first lays a reliable track for every rendering feature to come.

The first cross-environment hurdle: a GPU-memory lifecycle hotfix

Running WebGPU across different environments, GPU memory buffers follow strict lifecycle rules for "when usable, when to hand back"; once the timing is misaligned, you get half-read dirty data or an outright crash. This day hotfixed the buffer lifecycle during the "mapped read/write" stage, making it follow the rules under two quite different environments: one where, with no discrete GPU, rendering is simulated purely in software, and one where the browser calls the machine's native graphics directly. For the same code to be correct on both paths, every allocation and return of GPU memory has to get its timing exactly right. Such fixes ship no "visible new feature," yet they're exactly what decides whether the engine is "a toy that sometimes runs on my machine" or "a base that runs on another machine and another environment too." A large share of the cost of an in-house renderer goes into this grind of plugging cross-environment uncertainty one hole at a time; each one plugged widens the range of devices the platform can reliably cover.

Safe concurrency: a lifecycle lock per agent

The platform's other side is the agents that chat with you and do the work. From the start this platform envisions "a team of agents working at once" — a lead handing out tasks, sub-agents each taking a slice, rather than talking to one assistant at a time. But the moment several agents run concurrently, the classic "race condition" appears: two actions touch the same agent's state at almost the same instant with no guaranteed order, producing intermittent corruption or hangs. This day extracted each agent's lifecycle management into a dedicated "async lock" component: operations on the same agent — start, stop, switch — are serialized through that lock into a queue, guaranteeing only one action touches its state at any moment. With that, running many agents no longer means stepping on each other, and behavior becomes predictable. For a platform that treats "multi-agent collaboration" as a core promise, this lock is a key piece that lets the blueprint actually land instead of living only in a demo.

A sturdier terminal: paste won't crash + collaboration guidance

Beyond concurrency safety, the chat agent gained two "everyday feel" fixes. First, terminal input: an old "the second paste freezes" bug was fixed, making pasting long requirement text on the command line more resilient — paste in a whole block of setup or a long spec and it won't seize up. Second, collaboration communication: the tool agents use to message one another got fleshed-out usage scenarios and reply guidance, so "who should message whom, when, and how" has structure, and communication during multi-agent collaboration stops being ad hoc. These are the key "doesn't feel awkward to use" details: an assistant that crashes when you paste your requirements, or that descends into a babble when collaborating, can't be trusted no matter how smart. Only by smoothing these rough edges one by one does it become something you'd hand real work to.

No wasted cache: dynamic reminders append a new message

When talking to a large model, the stable context up front can be "cached" to save time and money; but rewriting the very front each time invalidates that cache and forces a full recompute. This day changed "dynamic reminders" (the temporary, conversation-shifting info handed to the model) from "rewrite the front" to "append a new message at the end," preserving the prefix cache. The direct feel for you: faster responses and lower cost on long conversations. Such an optimization looks small on its own, but on a platform built around long back-and-forth collaboration with AI it adds up to real differences in smoothness and spend — and the longer the conversation grows, the more this early right call pays off. It also reveals a stance running through the whole project: treating "how we talk to the model" as engineering worth real polish, not a prompt slapped together on a whim.

What this day means

Looking at day one's pieces together, you notice none of them is deliberately a "feature to show off": no pretty home page, no flashy demo. They are the first cornerstone of each of four through-lines — rendering, engine, concurrency, conversation. Behind that is a clear-eyed judgment: whether "generate a game by chatting" ultimately works doesn't hinge on whether day one can demo a trick, but on whether the foundation is hard enough — drawable in the browser, stable across environments, agents that don't fight, long conversations that don't burn money. Pouring these four foundations at once is what lets every later day stack steadily on top of them. It's also the first model this changelog wants to leave for future development: get the hardest, least glamorous, least-compromisable things right first.