The workspace is a sectioned hosted editor. Each route owns one part of the game so you can move between instruction authoring, asset libraries, release controls, and diagnostics without losing context.
| Section | What it controls |
|---|---|
| Release | Visibility settings, versioned releases, and release notes. |
| Title Screen | Branding, logo, tagline, intro text, title music, and time-of-day location images. |
| Opening | Optional scripted sequence that plays before free-form AI generation begins. |
| Instructions | The stored runtime, addendum, image, and avatar instructions for the game. |
| Characters & Sprites | The cast catalog and canonical sprite assets used as references for Generated Scene output. |
| Locations | Canonical location ids plus the hosted location image library. |
| Music | Hosted songs and runtime music assignments. |
| Effects | Uploaded audio SFX plus built-in visual effect toggles the runtime may emit. |
| Settings | Game identity, slug, and the managed public URL for your game. |
| Monitoring | Usage costs plus diagnostics for generations, users, and hosted runtime activity. |
The top-level workspace page is a hosted-game summary. Editing happens in dedicated routes like Instructions, Characters & Sprites, and Release. That split is intentional: metadata, publishing, asset management, and diagnostics each get their own working surface instead of competing inside one long editor.
Hosted games are managed directly from the platform workspace. The editor writes the same hosted runtime state that the play surface uses, so preview and publishing stay aligned with the saved workspace state.
The hosted workspace remains the runtime source of truth and the public inspection surface on the platform.
Start from a blank game, add only the assets you need, preview, then publish when the workspace is ready.
Games can expose a public read-only workspace for inspection. Non-owners see public sections, openings, assets, and title-screen data, while owner-only operational controls stay hidden.
Public workspaces keep the game understandable without exposing production instruction IP. Non-owners see safe public instruction views; owners and admins keep the private editing surface.
The title screen is what players see when they launch your game. Configure:
Hosted branding assets are explicit when present. If a workspace favicon, title logo, company splash, or title background is set, it must reference an uploaded UI asset for the game.
Theme controls set the hosted game's core UI colors: accent, warm accent, panel tint, and backdrop. These colors affect the runtime shell and launch surfaces while preserving the shared MDL layout and interaction model.
The heart of your game. The Instructions section shows the exact stored instructions that tell the runtime how to narrate, what tone to use, who the characters are, what the rules of your world are, and how Generated Scene image generation should be directed.
See Instructions for the guide.
Use this section to maintain the cast catalog and the hosted sprite library. Character labels, ids, and sprite assets live here — sprites are always used as references for Generated Scene output. Prompt descriptions for those same visible subjects live under Instructions.
This section owns location ids and the hosted background library. Keep the canonical list of places here, attach uploaded or generated location image variants that represent them, and describe how those locations should be used from the visible workspace configuration and instruction contract. The background generator supports multiple queued attempts. Those jobs continue while you close the location modal or move around the workspace, and running attempts can be cancelled before they finish.
Music is where you upload hosted songs and wire runtime cues like title-screen music or the initial track. It is songs-only, and uploads now go through a drag-and-drop confirm modal instead of an always-open inline form.
Use Effects for short one-shot cues. That section now separates uploaded audio sound effects from built-in visual effects like flashes, shakes, blur, and glitch treatments, so creators can allow both kinds without confusing them.
The semantic meaning of those tracks and effects still belongs in Instructions, so the asset sections stay focused on the library itself and the prompt section stays focused on how the model should use it.
Get your prompt working before investing heavily in art and music. A well-tuned prompt with placeholder assets will feel better than beautiful art with a weak prompt.
Click Preview to play your game as a player would. This is the fastest way to test how your instructions affect the experience. Play, adjust, repeat.
Asset IDs appear in your instructions, workspace config, and the AI's output. Use descriptive names like elena_happy or cafe_night rather than sprite_001.
Begin with a few key locations, up to 4 visible subjects, and basic music. Expand as the game takes shape.
