← Changelog
Daily2026-05-31

Export a game as a standalone site + skybox and bloom

This day took a big step "from built to shipped": a whole game can be exported as a self-contained static website, dropped onto any host and run. Scenes gained a real skybox and bloom and composite objects sit correctly; the preview loads correctly under prefixed URLs; and the interactive-narrative pipeline runs a full loop.

From "built it" to "shipped it"

For a game platform, being able to "build it" isn't enough — you must be able to "ship it," letting what you made leave the tool and be played by others. The weightiest thing this day was filling in the "export" step: packaging a whole game into a website anyone can host and anyone can open. Meanwhile the engine added skybox and bloom for atmosphere, fixed loading under prefixed URLs for deployment flexibility, and ran the narrative pipeline into a loop. On one side "make it look better," on the other "take it away when done" — the day pushed both ends of creation: making you enjoy building, and giving your results somewhere to go.

Package a game into a website you can take with you

A big step toward shipping: you can now export a whole game as a self-contained static website — no need to bring the full Studio along; drop the exported folder onto any static host and it runs on its own. In other words, the game you chat into being and build here can be packaged up, sent to friends to play, or put online for everyone, instead of being locked inside this tool. A first exported sample came with it — an FPS game called Sector Strike (with its own scene and readme) — to run and validate the whole export chain. A key bug was also fixed: the backend's route addresses used to be wrongly "captured" by the front-end's routing rules, keeping some embedded pages from opening; once fixed, the exported product reliably routes front-end and backend requests each to the right place. From "playable inside the tool" to "playable outside it," the road to shipping is genuinely open for the first time.

Skybox + bloom: more atmosphere

The engine shipped two immediately visible features this day. One is a visible skybox: a scene's background is no longer a flat solid color but a real sky environment wrapping the whole scene, with sky and atmosphere in the distance — the sense of space changes at once. The other is bloom: a soft glow spillover on bright areas — neon signs, strong light sources and glowing objects bleed a halo — the most common move for sci-fi, dreamy or night-scene atmosphere. Both are "atmosphere effects" acting directly on look and feel. Underneath, an important thing was wired through: hierarchical world transforms. A parent and child's position, rotation and scale now propagate correctly layer by layer to the renderer, meaning the parts of a composite object — a character holding a weapon, a vehicle with attached parts — finally place and move correctly with the whole instead of being misaligned. Atmosphere plus correct hierarchy together make a scene both good-looking and "correctly arranged."

Preview loads correctly under a URL prefix

This day also grappled with an unglamorous but deployment-flexibility-critical path: making the preview load all resources correctly under a "URL path prefix." In many real deployments, an app isn't at the website root but under some sub-path (a subdirectory of some site) — and if resource addresses don't account for that prefix, loading fails to find files and errors. This day aligned the whole chain, from engine to packaging to the resource index, to "respect the path prefix," and locked a regression test to keep it from going wrong again; it also fixed the startup flow to ensure the full set of needed runtime pieces is correctly built before launch. It addresses the most headache-inducing class of environment issue — "deploy it somewhere else and loading breaks." Getting this path working means exported games and embedded previews reliably find their resources and run no matter what URL path they're placed under — exactly the underlying guarantee that makes "package it into a website and take it" genuinely usable.

The interactive-narrative pipeline runs a full loop

The story pipeline for narrative-driven games was wired into an end-to-end loop this day. A plot is essentially a branching "story tree," and drawing and running that tree correctly means solving a string of thorny problems: disambiguating repeated numbering, repairing back edges, routing long-span connections around, and auto-mounting on start so it's visible from the beginning — all fixed this day, so the whole story structure presents correctly. The agent responsible for narrative connected to the full pipeline toolset and reports progress live as it runs. The key piece: when the whole pipeline finishes, the system automatically wakes that agent back to do a closing summary, rather than stopping halfway and leaving a dangling end. With that, building a branching, well-paced plot becomes a smooth, visible, self-closing flow from start to finish — the narrative line moves from "has tools" to genuinely "can run all the way through once."

What this day means

The most important shift this day is the platform having a complete "exit" for the first time. Before, however well-made, a game was still trapped in the tool; and "export as a website" plus "loads correctly under any path" together let your work genuinely leave here and reach others for the first time. With skybox and bloom making it better-looking and the narrative loop making it more complete, this day filled in the last link of the "create — take shape — ship" chain. A creation tool's value is ultimately redeemed by whether "what you make can be seen by the world." From today, the game you make here is no longer just a local demo but a real work you can package, host and share for anyone to play.

← All daily updates