The game runtime moves fully to the in-house engine

A watershed: from now, your game runs on our own engine

This is a genuine watershed. Before it, what actually drove your game in the preview was still a general-purpose rendering approach borrowed early for a fast start; and the capabilities the engine team had been building these days, though steadily growing, hadn't truly become "the engine that runs games." This day switched the runtime wholesale to the in-house engine — from today, every game you chat into being truly runs on our own engine. Its significance isn't just "swapping the base," but bringing the scattered capabilities built up over the past days (physically-based lighting, shadows, ambient sky light, the asset system, 2D layers) together inside one engine for the first time, no longer each on its own. The items below either revolve around this switch or were driven by it.

Why an in-house engine is the choice worth making

Replacing a ready-made, working approach to build an engine from scratch clearly costs a lot; so why is it worth it? The core is control. Borrowing a general approach leaves image quality, performance and features constrained by that approach's trade-offs, and doing something it wasn't designed for is awkward; in-house, rendering is fully controllable, problems can be traced all the way down, and new features can be built once and take effect everywhere, without working around someone else's limits. More importantly, this engine is designed specifically for "AI writing games" — its interfaces, asset system and default behavior can all be polished around "making it easy for AI to write correctly and easy to reuse generated code," which no general third-party approach can offer. This day's switch turns the product's most core foundation from "rented" to "our own."

Materials gain custom shaders

Riding the engine switch, the material system also split into two layers — template and instance. One is a ready-to-use standard physically-based material that covers most ordinary objects; the other lets an object carry its own custom shader for a distinctive visual effect — glow, distortion, pulsing, energy fields — no longer bound by the standard material. To keep "more variety" from "getting slow," the engine caches a render pipeline per material, reusing the same material and keeping different ones separate, both flexible and efficient. A "pulsing glow" demo proved the path works end to end. For anyone wanting an object to look unlike the rest, this gives a proper route: the ease of the standard material, plus the freedom to fully customize when needed.

Stricter mesh upload: bad data errors on the spot

This day also added a strict entry check to the low-level path of "uploading mesh data to the GPU": if incoming mesh data is malformed (say, the per-vertex data count doesn't match expectations), the engine fails fast on the spot rather than silently swallowing it and leaving you to guess when the image later breaks in some uncanny way. A unified data-format migration came alongside, aligning the relevant vertex data formats to one consistent standard. This looks like "just adding a check," but it embodies an important engineering principle: surface errors as early and as close as possible to where they actually occur, rather than letting them drift down the pipeline into a hard-to-trace oddity. For an engine that will have AI generate mesh data in bulk, this "bad data can't get in" gatekeeping saves countless hours of later debugging.

More specialist agents + picking them in-tool

The collaboration roster filled out again this day: several new agents with distinct specialties arrived, so you can pick the right one to take a task rather than dumping everything on one generalist. The tool window's top bar gained an agent picker to assign which agent works inside a given workbench and open its details in one click to see what it's good at. The backend also added unified create/read/update/delete for agents with role support, making "managing your AI team" itself orderly. Getting the right agent on the right job is key to collaboration efficiency — handing an art need to an art-specialized agent is far more reliable than to a jack-of-all-trades. This day made "picking the person" both convenient and smooth.

Don't let docs lie: automatic doc-vs-code reconciliation

This day also raised a special gate: automatically checking whether the "design docs" and the "actual code" still line up. Every long-evolving project has a common ailment — docs describe the original intent while code keeps changing, and over time the two quietly diverge until the docs start misleading. This reconciliation gate alarms when key code locations referenced by docs change, forcing you to update either the code or the doc, not letting them secretly part ways. It addresses "doc trustworthiness," the most easily overlooked yet long-term efficiency-eroding problem. For a platform that takes "AI also relies on docs to understand the system" seriously, keeping docs honest is itself core infrastructure — because lying docs mislead humans and AI alike.

What this day means

The weight of this day rests almost entirely on that runtime switch: changing the engine that runs your game from "rented" to "our own." It's not a feature that instantly makes the image prettier, but a fundamental decision about "who holds the initiative for the future" — from now, image quality, performance and the direction of AI optimization are all in our own hands. Around this switch, materials became customizable, bad data can't get in, the team is easier to staff, and docs no longer lie — each making this "own engine" more controllable and trustworthy. A platform daring, after it already works, to replace its most core foundation with an in-house one isn't after momentary good looks but lasting autonomy — and that's the judgment this day most deserves to be remembered for.