One-tap context compaction + a WebGPU software fallback

Making "long-term, broad use" solid

Once capability is in place, the next question is: can it be used long-term and broadly? Long-term means whether a single conversation can last without the context overflowing; broad means whether it runs on all sorts of machines, not just the developer's high-end one. The day's items answer these two respectively: one-tap conversation compaction addresses "chatting long enough hits the ceiling," and the WebGPU software fallback addresses "no good GPU means a black screen." Add the clean new-game starting point, 2D animation and a batch of robustness fixes, and the through-line is clear: not new gimmicks, but making "everyday long-running use on more machines" solid.

One-tap compaction: /compact + a context-usage ring

Over long back-and-forth with a large model, the "context" it can hold piles up; near the limit, responses slow, quality drops, and it even starts forgetting. This day added a /compact command: one tap compresses the prior exchanges into a concise summary, freeing room to keep going, and the compaction itself doesn't burn a whole conversation turn — it's done directly on the backend. The composer also gained a "context-usage ring" that, like a fuel gauge, shows at a glance how much budget remains, so when it's getting full you can see it and proactively decide whether to tidy up. With slash-command autocomplete, typing / surfaces all available commands for quick selection. This set of changes faces head-on the core constraint of "long-term collaboration with AI" — context is finite; putting its management in the user's hands, done lightly, is what makes long sessions truly sustainable.

A WebGPU software fallback: 3D runs on more machines

3D rendering depends on a modern GPU's capabilities, but in reality some machines or environments can't get hardware acceleration — maybe the GPU is too old, maybe the runtime is constrained. Previously this meant a black screen, shutting those users out entirely. This day added a software fallback: when a hardware-accelerated rendering device can't be obtained, the system steps back and uses a software implementation to render the picture — slower, but at least it runs, shows and lets you keep working. Underneath, multi-level fallback was added (try the next path when one fails, error only as a last resort), with clearer diagnostics explaining why hardware acceleration wasn't taken (say, running under a non-secure origin). The significance is coverage: a platform for the mass market, wanting anyone to get started, can't assume everyone has a high-end machine; running on weaker machines too is what truly lowers the bar.

New games start from a clean ECS template

Creating a new game now generates from a clean, well-structured template organized along a proper architecture. This day rewrote that default template in a "proper ECS architecture" style, extracted it from an inline string into a version-controlled standalone file, and halved its line count — meaning the moment you create a game, you get a clean, compact base ready to build on, not a pile of boilerplate you must first understand before editing. The template and the system instructions fed to the AI were updated to the latest engine interfaces alongside. This matters especially for "AI writing games": the AI continues from the template's shape, so the cleaner and more standard the template, the more likely the AI's code is correct and the easier it is for you to read and reuse. A good starting point saves countless later corrections.

2D sprite-sheet animation

The engine added 2D sprite-sheet animation this day: playing multiple frames from a "sprite sheet" (a series of action frames laid out in one image) in sequence, giving 2D character and effect animation a ready-made, standard approach. This is the most common animation method in 2D games — a little figure walking, a flame flickering, is essentially a few frames cycling quickly. Before this, 2D content could only be static sprites; with sheet animation, the 2D line can truly move. Together with the earlier sprite layers, it fills in the engine's 2D fundamentals: correct layering and stacking, plus making each sprite move. For anyone wanting to make a 2D game, this is the key step from "can place images" to "can do animation."

Engine robustness: regression tests + a batch of rendering fixes

The engine also did a batch of unglamorous but important robustness work this day. Regression tests were added for several failure-prone situations — render queries, parent-child hierarchy, and the edge case of "not a single light in the scene" — pinning them down with tests so future changes elsewhere can't quietly break them. Some vaguely-named fields were renamed more accurately so the code is harder to misread; and a few compatibility issues that surfaced only after merging were fixed. These are the work of "welding down newly added capability": after intensely adding many things over the prior days, this day went back to add tests and clean edges, ensuring they don't just "run once" but "stay reliable going forward." Alternating fast iteration with steady consolidation is why this product line can keep running.