The workspace is a sectioned hosted editor. Each route owns one part of the game so you can move between raw prompt authoring, schema inspection, 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, splash positioning, tagline, intro text, title music, and time-of-day backgrounds. |
| Opening | Optional scripted sequence that plays before free-form AI generation begins. |
| Map & Locations | Map image and location markers that give players a sense of geography. |
| Instructions | The stored runtime, addendum, image, and avatar instruction files for the game. |
| Schema | The full stored runtime schema file for the game. |
| Characters & Sprites | The cast catalog and canonical sprite assets used as references for Generated Scene output. |
| Backgrounds | Canonical location ids plus the hosted background library. |
| Music | Hosted songs and runtime music assignments. |
| Effects | Uploaded audio SFX plus built-in visual effect toggles the runtime may emit. |
| Domains | Custom domain configuration and DNS setup 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, Schema, 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 support local package sync so a creator can work from a repository, compute a deterministic package hash, diff it against the hosted dev container, and sync changed files into the workspace through MDL.
That workflow is intended to complement this hosted editor, not replace it. The hosted workspace remains the runtime source of truth and the public inspection surface on the platform.
Use mdl diff, mdl push, and mdl pull for the generic workflow. Existing Monte Lua scripts remain available as wrappers.
Games can expose a public read-only workspace for package inspection. Non-owners see package sections, schema, openings, assets, title-screen data, and a source-package download, but owner-only operational controls stay hidden.
Public source packages keep the package functional while protecting production instruction IP. Prompt files under prompts/ are replaced with generic functional instruction files for non-owners; owners and admins can export the real instruction files.
The title screen is what players see when they launch your game. Configure:
Hosted branding assets are explicit. The workspace favicon, title logo, and company splash must each reference uploaded UI assets for the game; MDL does not substitute platform defaults for hosted branding when those references are missing.
The heart of your game. The Instructions section shows the exact stored instruction files 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.
The Schema section shows the exact stored schema file for the game. MDL still owns the engine-level field meanings, but the concrete enum-backed values and visible contract for the game live here.
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 background variants that represent them, and describe how those locations should be used from the visible prompt and schema contract.
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 instruction files affect the experience. Play, adjust, repeat.
Asset IDs appear in your instruction files, schema, 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.
