Inside RUN.world Creator Studio: Pure Vibe Coding, Model Testing, and the AI Coach

RUN.world gives you two completely different ways to build games: the localrundot CLI and the browser-based Creator Studio.

Working inside the browser Studio is a pure vibe-coding experience. You don't get version control, and you have almost no tools to manipulate files directly. If you send a destructive prompt that ruins your game loop or breaks your layout, that change is irreversible, and a string of quick back-and-forth fixes will fill up the model's context window fast. Because of that, the web Studio is too tight for medium projects and barely usable for large game development—but as a sandbox for visualizing a quick idea in 20 minutes or testing how different frontier AI models write game code, it is genuinely fun to poke around in.

One thing the Creator Studio does really well is giving you a single dropdown to test almost every current model against the exact same game-building prompt.

Instead of locking you into a single default model, the Studio splits its selector into three tiers:

Being able to switch between GPT-6 Sol,GPT-6 Astra, and Gemini 4 Argon inside the same project makes it easy to see how each model handles collision math or state machines. Just keep an eye on your balance: firing off prompts on the Power tier eats through credits like hell, especially once your conversation history grows long.

Even though you barely touch files yourself in the browser interface, the AI isn't writing spaghetti HTML from scratch. Internally, the Studio steers the models using a strict CLAUDE.md project template built onPixi.js v8 + React 19 + Tailwind v4.

Every game generated in the Studio follows a pre-wired architecture designed to survive LLM edits:

• React for UI, Pixi for the Canvas: React 19 (src/ui/) handles screen routing (loading → menu →playing) and Tailwind HUD overlays, while Pixi.js v8 (src/game/) runs the actual game loop inside a shared#app-frame container.
• Discrete State Bridge (src/state/store.ts):To stop the AI from triggering React re-renders 60 times a second inside the Pixi ticker, a tiny useSyncExternalStore bridge sits between them. The game only calls store.patch() on discrete events like score updates, wave changes, or game-over popups.
• Locked 8-Step Boot Sequence (src/main.tsx):The entry file enforces a numbered 1-to-8 boot order:
  1. initSdk() (RundotGameAPI.initializeAsync(), wrapped so the game still runs in a plain browser if the host isn't present)
  2. Load saved progress from RundotGameAPI.storage
  3. Mount React
  4. Lift the HTML boot cover (which has a 4-second CSS safety fade inindex.html so a bad script never leaves the player staring at a permanent black screen)
  5. Warm up critical assets (src/assets/preload.ts)
  6. Show the main menu
  7. Register the six host lifecycle hooks (onPause/onResumeto freeze the Pixi ticker, and onSleep/onQuitto flush save data)
  8. Fire initial analytics
• 720-Unit Design Stage (src/game/stage.ts):Models are instructed never to use raw pixel coordinates. Everything is placed on a 720-unit wide virtual stage (DESIGN_WIDTH = 720, scaling from 1280 units high at 9:16 up to ~1560 on tall phones) so mobile layouts stay proportional.
• A Few Quirky Build Rules: Under the surface, reactand react-dom are pinned to 19.2.4 sorundotGameLibrariesPlugin() can externalize them to the host CDN instead of bundling them, and firebase has to stay indevDependencies because the RUN SDK dynamically importsfirebase/app without declaring it in its own package manifest.

All the places where the AI is supposed to inject game-specific code are marked with ADAPT: comments in the template files, which explains why the Studio can spin up a working prototype so reliably on the first prompt—and why things get messy once your game outgrows that initial template and the context window fills up.

Next to the prompt chat sits the Assets tab, which acts as the central bucket for all media in your project.

Every sprite, background, or sound effect you generate—along with any files you upload manually—lands in this tab. The Studio uses the files sitting here as visual references when generating new assets so the art style stays somewhat consistent, and wires them into src/assets/manifest.ts(split into critical assets that block the loading screen anddeferred assets that stream in the background). If you don't want to spend credits generating basic icons or tiles, there are also free starter asset packs available right inside the tab.

The standout part of the Creator Studio is the Coach tab.

Once your game is published, Coach hooks into the game's analytics, tracks how real players behave inside your sessions, and gives you concrete recommendations on what to adjust to improve retention and gameplay flow.

There is one funny catch, though: Coach relies on actual player telemetry. If you are bad at promoting your game or don't have a marketing budget to bring in traffic, Coach doesn't have enough gameplay data to analyze your mechanics—so you just end up looking at three pieces of advice telling you to get more players first, haha.

To its credit, Coach actually tries to help you solve that problem too by generating ready-made promotional media packs and creatives that you can take straight into ad campaigns or social posts.