Getting Started with MM Engine

Make something.

**Windows:** Use the PowerShell CLI one-liner below today. `mm studio` already exists as the **MM Studio Web Dashboard**. The separate **MM Studio Desktop App** for Windows is still coming soon and is not yet available for download.

**Linux:** Use the download-first CLI installer below. Fully supported CLI path today.

**macOS:** Coming soon.

Custom plugin development requires Rust regardless of platform today. If you later experiment with the roadmap C# plugin flow, install the **.NET SDK** too so the `dotnet` CLI is available.

MM Engine is a plugin-based game engine. Games are built from small, focused plugins

that compile to WebAssembly. Today, Rust is the only supported plugin language in the CLI.

Support for C#, Python, Go, and JavaScript is coming soon. The kernel loads your plugins,

runs the event loop, and handles the rest.

Today, the supported first-run path is the CLI. The MM Studio Web Dashboard already ships inside the CLI via mm studio and opens in your browser at http://localhost:4242 for an existing local project. The separate downloadable MM Studio Desktop App for Windows/macOS is a different product and is still coming soon.

Platform Support

|—|—|—|—|

Today, Linux and Windows users have full CLI support. The MM Studio Web Dashboard is available now via mm studio inside the CLI workflow. The MM Studio Desktop App (a separate standalone download, no Rust required) is in active development — sign up at mostlymodular.gg to get notified when it ships for your platform.

Step 1: Install MM Engine

⚠️ **MM Studio Desktop App for Windows** — coming Q2 2026. Use the CLI path below today. If you run `mm studio`, that opens the **MM Studio Dashboard (Web)** for an existing local project.

Windows — Option A: PowerShell CLI (Available Now — Use This Today)

Important: the PowerShell one-liner installs the **MM CLI only**. It does **not** install Git, Rust, or the WASM targets for you. The installer checks for them and prints the exact setup steps if they are missing.

⏱️ **Time estimate:** MSVC path: ~37–50 min total (includes reboot). GNU path: ~25 min total, no reboot.

Windows CLI Requirements (before running mm build):

[ ] Rust installed (via winget or rustup.rs)

[ ] Git installed via winget install Git.Git

[ ] If you plan to use the roadmap C# plugin flow later: .NET SDK installed so dotnet --version works

[ ] Either GNU host toolchain (Option A — recommended, no MSVC needed) or MSVC Build Tools (Option B)

[ ] wasm32-unknown-unknown target installed: rustup target add wasm32-unknown-unknown (mm doctor will warn if missing)

[ ] wasm32-wasip1 target installed: rustup target add wasm32-wasip1 (required for WASM system interface compatibility — mm doctor warns if missing)

[ ] MM Engine installed via install.ps1

**All current Windows CLI paths require Rust.** There is no Rust-free CLI build path today. The **MM Studio Dashboard (Web)** is already available through `mm studio`; the separate **MM Studio Desktop App** (arriving Q2 2026) will be the first no-Rust option.

If you skip the toolchain step, mm build will fail with a missing linker / missing toolchain error.

⚠️ **Windows CLI users:** Plugin development requires Rust (free). If you prefer a no-Rust setup, wait for the **MM Studio Desktop App** (coming Q2 2026). The existing `mm studio` command is the **MM Studio Dashboard (Web)** and still uses the CLI-installed engine.

⚠️ **Rust is required to build and run games on this path.** Install it first — takes about 5 minutes.

**Step 1 — Install Rust** *(⏳ ~500 MB download — 10 Mbps ≈ 1 min, 1 Mbps ≈ 10 min)*:

“`powershell

winget install Rustlang.Rustup

“`

Then close and reopen PowerShell.

**Verify Rust before moving on:**

“`powershell

rustc –version

cargo –version

“`

If either command is missing, reopen PowerShell once more or finish the `rustup` prompts before continuing.

**Step 2 — Install Git** *(⏳ ~1 minute)*:

“`powershell

winget install Git.Git

“`

Then close and reopen PowerShell so git is in PATH.

> Git is required by `mm doctor` for SDK auto-updates from GitHub.

> **Why?** Windows PowerShell loads environment variables (like PATH) when it starts. New installs update the system registry, but the current session won’t see them until you start a new one. This is equivalent to running `source ~/.bashrc` on Linux/macOS.

**Step 3 — Choose a Windows Rust toolchain path** *(⏳ 5–10 minutes)*:

For `mm build` / `cargo build –target wasm32-unknown-unknown`, Rust’s `wasm32-unknown-unknown` target links with the in-tree WebAssembly linker (`rust-lld`), so it does **not** inherently require MSVC.

**Option A (recommended):** GNU host toolchain — no MSVC or Visual Studio required

“`powershell

rustup toolchain install stable-x86_64-pc-windows-gnu

rustup default stable-x86_64-pc-windows-gnu

rustup target add wasm32-unknown-unknown

rustup target add wasm32-wasip1

“`

> **Note:** After `rustup toolchain install stable-x86_64-pc-windows-gnu`, you may see “(timeout reading rustc version)” — this is cosmetic and does **not** indicate failure. Verify success with `rustup target list –installed`.

This path uses Rust’s built-in `wasm-ld` / `rust-lld` linker for `wasm32-unknown-unknown` builds. No MSVC linker needed. Officially supported on Windows 11 — `mm build` completes in ~22 seconds with no extra downloads. Faster than the MSVC path (which requires a 600 MB+ Visual Studio Build Tools install).

`wasm32-wasip1` is required for WASM system interface compatibility (`mm doctor` warns if missing).

If you forget the `wasm32-unknown-unknown` target, `mm doctor` will warn you and show the exact fix: `rustup target add wasm32-unknown-unknown`.

**Option B:** MSVC toolchain + Build Tools (GUI installer — recommended method)

1. Download: https://aka.ms/vs/17/release/vs_BuildTools.exe

2. Run the installer (double-click it, or launch it from PowerShell without flags)

3. When the Visual Studio Installer opens, select **”Desktop development with C++”**

4. Click **Install** (⏳ 15–20 minutes, ~2 GB download)

5. **Restart your computer** after installation completes

6. Verify MSVC linker with `where link.exe` in PowerShell after installation

7. Run `mm doctor` to verify your setup is complete

Note: `winget install Microsoft.VisualStudio.2022.BuildTools` sometimes reports success but fails to register the linker. Use the direct installer above instead.

> ⚠️ **If `link.exe` is still not found after reboot:** Run `mm doctor` again — it will show the exact linker path and the exact PATH fix command if Build Tools is installed but not registered in PATH.

**Which path should I pick?**

– **MSVC (Option B):** Standard Windows toolchain, works with all Rust crates. Larger install.

– **GNU (Option A):** Faster setup (~25 min), no Visual Studio required. Officially verified. Recommended if you hit linker issues.

GNU (`stable-x86_64-pc-windows-gnu`) is verified and avoids MSVC entirely — recommended if you hit linker issues.

Default recommendation: GNU if you want faster setup, MSVC if you want the standard toolchain.

**Step 4 — Install MM CLI tools:**

The one-liner below installs **only the MM CLI** (`mm`, `mm-build`, `mm-run`, etc.). It does not install Git, Rust, or WASM targets — you should have those from Steps 1-3 above. The installer runs pre-flight checks and tells you if anything is still missing.

Invoke-WebRequest https://mostlymodular.gg/install.ps1 -OutFile install.ps1
powershell -ExecutionPolicy Bypass -File .install.ps1

This download-first path is the recommended default.

**Download size note:** `install.ps1` is tiny, but the full Windows release ZIP it installs from is currently about **390 MB**.

Shortcut, if you already trust the script:

$ProgressPreference='SilentlyContinue'; iwr -UseBasicParsing https://mostlymodular.gg/install.ps1 | iex

Security note — what | iex means: PowerShell downloads install.ps1 with iwr (Invoke-WebRequest) and pipes the script text into iex (Invoke-Expression) to run it immediately in your current shell. The download-first path above is the recommended default because you can inspect the script before running it.

If you manually extract the Windows ZIP instead of using install.ps1, also copy the bundled sdk/ folder to:

%USERPROFILE%.mmenginesdk

install.ps1 handles that SDK copy automatically.

**Note:** `install.ps1` updates `$env:PATH` for the current process, so `mm` is immediately available in the same terminal session where you ran the installer. New terminals will also have it — the installer writes to your user PATH registry.

What the installer does

Downloads about 30 MB for the installer payload itself, then points you at the full release artifacts when needed.

Installs the CLI into %USERPROFILE%.mmbin and engine/support files under %USERPROFILE%.mm or %USERPROFILE%.mmengine, depending on the release layout.

Copies the bundled SDK into your MM Engine data directory when needed.

Adds the MM CLI location to your user PATH so new terminals can run mm without extra setup.

Updates the current PowerShell session too, so you can usually run mm immediately after the script finishes.

**Windows download size reality check:** the public Windows release ZIP at `/releases/mostly-modular-windows-x86_64.zip` is currently about **390 MB**. The small installer script is just the entry point, not the full size of the Windows download.

Quick verification:

mm --version
mm doctor

The installer now ends with: MM is installed -- run mm --version to verify.

Run that verification step before moving on, then run mm doctor.

Verification step (do not skip):

mm doctor
mm init verify-demo --preset menu-shell
cd verify-demo
mm build
mm run

If Git, Rust, or either WASM target is missing, follow the remediation printed by the installer and mm doctor before running mm build.

If mm doctor shows all green checkmarks, you are ready.

**Tip:** If `mm doctor` shows warnings, run `mm doctor –fix` to auto-remediate known issues (missing wasm targets, PATH problems).

Expected output (healthy install):

Version numbers vary by machine/release. `mm doctor` prints the actual detected tool versions.

mm (Mostly Modular Engine) v0.2.0
mm doctor: running checks…

MM Engine — System Check

Core Engine
  ✓ mm-init found
  ✓ mm-build found
  ✓ mm-run found
  ✓ mm-kernel found
  ✓ ~/MostlyModular exists

Plugin Development (optional — Rust only)
  ✓ Pre-built starter game (Astro Snack Run): installed — run 'mm try' to play without Rust
    Other presets require: mm build, which needs Rust
  ✓ cargo 1.94.0
  ✓ rustup 1.29.0
  ✓ git found
  ✓ wasm32-unknown-unknown target installed
  ✓ wasm32-wasip1 target installed
  ✓ mm_sdk found (~/.mm/engine/sdk/mm_sdk)

All good! Ready to make games.

Expected output (Windows, MSVC linker missing):

MM Engine — System Check

Core Engine
  ✓ mm-init found
  ✓ mm-build found
  ✓ mm-run found
  ✓ mm-kernel found
  ✓ ~/MostlyModular exists

Plugin Development (optional — Rust only)
  ✓ cargo 1.94.0
  ✗ MSVC linker (link.exe) not found
    Option A — GNU toolchain (recommended, fastest, no Visual Studio needed)

Windows — Option B: MM Studio Desktop App (Coming Q2 2026 — No Rust Required, Not Yet Available)

The MM Studio Desktop App will be the easiest way to try Mostly Modular on Windows — no terminal, no Rust, no build step.

⚠️ **NOT YET AVAILABLE.** Target: Q2 2026.

The CLI path above is fully supported long-term — your projects work with both the CLI and the MM Studio Web Dashboard today, and with the MM Studio Desktop App when it releases.

Linux (fully supported CLI path):

curl -fsSL https://mostlymodular.gg/install.sh -o install.sh
bash install.sh
source ~/.profile   # or open a new terminal
mm doctor           # verify the install

This download-first path is the recommended default.

Shortcut, if you already trust the script:

curl -fsSL https://mostlymodular.gg/install.sh | bash

Use `bash`, not `sh` — `install.sh` requires bash.

macOS: MM Studio and CLI support is planned. Check mostlymodular.gg/install/ for availability.

**Note:** All current CLI paths require Rust for `mm build` — there is no Rust-free CLI build path today on any platform. MM Studio (no Rust required) is arriving Q2 2026. Both the GNU and MSVC toolchain paths are officially supported on Windows. The GNU path is recommended — it’s faster to set up and doesn’t require Visual Studio.

Custom plugin development requires Rust regardless of platform.

Step 2: Create a project

Use the CLI to scaffold your first project today:

mm init my-game --preset menu-shell
cd my-game

--preset chooses the starter you want MM to scaffold. Start with menu-shell if you want the same project shown in this guide. To see other built-in starters, run:

mm init --list-presets

Examples:

mm init arcade-demo --preset menu-shell
mm init arena-demo --preset topdown-2d
mm init jumper-demo --preset platformer-2d

--preset menu-shell tells MM which starter layout to scaffold. Use mm init --list-presets to see the available presets first. If you omit --preset, MM uses the default starter preset for that release.

This creates a new MM project shell. Today, mm init creates the project structure first, then you add your first plugin with mm plugin new. Your project structure looks like this:

my-game/
├── game.toml               # Project config and gameplay knobs
├── pack.toml               # Pack metadata (name, version, description)
├── Cargo.toml              # Rust workspace (auto-generated)
├── README.md               # Project readme
├── .gitignore              # Sensible defaults pre-configured
├── .mm-journey             # Tracks which preset was used (safe to commit)
├── plugins/                # Plugin workspace, starts empty after mm init
├── assets/                 # Game assets (sprites, audio, fonts, etc.)
├── games/                  # Game configurations
├── specs/                  # Design specs
└── docs/
    └── DESIGN.md           # Design doc (generated per preset)

.mm-journey tracks which preset this project was scaffolded from. It’s safe to commit — MM uses it to suggest relevant next steps.

`mm init my-game` is the public CLI command for project scaffolding.

To open the current MM Studio Web Dashboard for this project:

“`bash

mm studio

“`

Today, `mm studio` launches the **MM Studio Dashboard (Web)** in your browser for an existing project. It is not the downloadable **MM Studio Desktop App**, and it is not the first-run project creation path on Windows yet.

Genre starters (Journey 3):

“`bash

mm new –template topdown-2d my-game # top-down arena game

mm new –template platformer-2d my-game # side-scrolling platformer

mm new –template twin-stick my-game # twin-stick shooter

“`

Note: the downloadable MM Studio Desktop App for Windows/macOS is still coming soon.

Step 3: Explore and play the starter project

Before you build or run, add your first plugin. Today, mm init gives you the project shell and mm plugin new creates the code MM can compile.

This keeps the current CLI flow honest and avoids the “empty plugins directory” surprise.

mm init creates the project root, config files, docs, and an empty plugins/ workspace.

mm plugin new my-game creates the first plugin crate in plugins/my-game/.

After that, use mm build and mm run as your normal loop.

**Windows/Linux CLI path**

Add your first plugin, then build and run:

“`bash

mm plugin new my-game

mm build # fresh Rust install: 5-10 min (downloading crates); subsequent builds: under 1 second

mm run # launches the game

“`

If you installed via Option A (GNU toolchain), crates may already be cached — expect under 1 minute.

If Rust crates are already cached, even first builds may be fast.

If `mm run` says “No built plugins found and Rust is not installed” — that means Rust isn’t in PATH. Reinstall Rust (via `winget install Rustlang.Rustup` on Windows or `curl –proto ‘=https’ –tlsv1.2 -sSf https://sh.rustup.rs | sh` on Linux) and reopen your terminal.

**Note for SSH users:** If you’re testing over SSH, `mm run` will show a TTY warning and run in headless mode. This is expected — the menu game still boots and runs correctly. Use `mm run –no-tty-warn` to suppress the warning. For graphical games, use `mm run –windowed`.

Hot Reload (Edit Without Restarting)

Run with hot reload enabled:

mm run --watch

mm run --watch and mm run --hot-reload enable the same mode. --watch is the preferred spelling in the docs, and --hot-reload remains supported as an alias.

Then edit any plugin source file and save — the engine reloads your plugin automatically without restarting the game. No need to stop and rerun.

**Tip:** Hot reload works best for logic changes. If you change your plugin’s `plugin.toml` (settings, toolbar buttons), restart `mm run` to apply those changes.

mm dev — The Complete Dev Loop

For the full hot-reload workflow with external editors (VS Code, Blender, etc.), use mm dev:

mm dev

This command:

Watches your plugin source files for changes

Automatically rebuilds when source changes are detected

Runs the game with hot-reload enabled (`mm run –watch`, same as `mm run –hot-reload`)

Reloads plugins instantly when the build completes

The workflow is: edit code in your editor → save → mm dev rebuilds and runs automatically.

Press Ctrl+C to stop the dev loop.

**External Editor Tip:** Open your project in VS Code, Zed, or Blender, edit files, and watch your game update live. The Bistromathic Drive handles plugin hot-swapping while `mm dev` handles the build cycle.

Step 4: Open a plugin

Open the main plugin file for your language in your editor of choice:

| Language | File |

|————|———————————–|

| Rust | plugins/my-game/src/lib.rs |

| C# | plugins/my-game/src/Plugin.cs (roadmap preview, not the supported CLI path today, requires the .NET SDK / dotnet CLI) |

| Python | Coming soon |

| Go | Coming soon |

| JavaScript | Coming soon |

**C# note:** When the C# plugin path is enabled, you will also need the **.NET SDK** installed so the `dotnet` CLI is available. The current day-one CLI flow is still Rust-first.

Look for the lifecycle functions — init, update, and on_event. The template already wires them up for you.

If you want the current dashboard experience after scaffolding, run mm studio from the project root and open the same files in the browser-based MM Studio Web Dashboard.

You don’t need to understand every line yet. Find the entry points, make one change,

then build and play.

Step 5: Build

Build from the project root:

mm build

Builds compile your plugins to WebAssembly automatically.

Fresh Rust install: 5–10 min downloading crates; subsequent builds are much faster.

If you installed via Option A (GNU toolchain), crates may already be cached — expect under 1 minute.

If you are using the MM Studio Web Dashboard (mm studio) on an existing project, you can watch the same project there while you work.

Step 6: Play

Run the game from the project root:

mm run             # run the game
mm run --watch     # hot-reload on file changes (--hot-reload is an alias)
mm run --windowed  # graphical games with a native window

For text/menu games, output appears in the terminal.

For graphical games, a game window opens.

If you also run mm studio, the MM Studio Web Dashboard can inspect the same project while it is running.

That’s the full loop today: edit, build, run, verify, repeat.

The Event System

Plugins talk to each other through events. The kernel’s event bus delivers them.

Emitting an event

fn update(&mut self, ctx: &mut Context, _dt_ms: f32) {
    ctx.emit("player:moved", "42.0,100.0");
}

Subscribing to events

fn init(&mut self, ctx: &mut Context) {
    ctx.subscribe("player:moved");
    ctx.subscribe_key_down();
}

fn on_event(&mut self, ctx: &mut Context, event: Event) {
    let player_moved = ctx.kind_for("player:moved");
    let key_down = ctx.kind_for("input:key_down");

    match event.kind {
        kind if kind == player_moved => {
            let pos = event.payload_str();
            ctx.print(&format!("Player moved to {}", pos));
        }
        kind if kind == key_down => {
            if let Some(key) = event.key_code() {
                ctx.print(&format!("Key pressed: {}", key));
            }
        }
        _ => {}
    }
}

Rendering

The kernel provides host functions for 2D and 3D rendering.

2D sprite

ctx.emit("render:sprite", "player.png,100,200,64,64");

2D text

ctx.emit("render:text", "Hello, World!,50,50,white,24");

3D mesh

ctx.emit("render:mesh3d", "ship.gltf,0.0,0.0,-10.0");

Input

Subscribe to input events from the kernel. event.kind is a numeric event ID, so compare it to IDs from ctx.kind_for(...):

fn init(&mut self, ctx: &mut Context) {
    ctx.subscribe_key_down();
    ctx.subscribe_key_up();
}

fn on_event(&mut self, _ctx: &mut Context, event: Event) {
    if let Some(key) = event.key_code() {
        match key {
            KEY_ARROW_LEFT | KEY_A => { /* move left */ }
            KEY_ARROW_RIGHT | KEY_D => { /* move right */ }
            KEY_SPACE => { /* jump */ }
            _ => {}
        }
    }
}

Hot Reload

Edit your code, save, and the engine reloads your plugin automatically.

In the MM Studio Web Dashboard (mm studio in your browser), hot reload is on by default — just save the file and watch the game

update live. Implement save_state and restore_state on your Plugin to preserve

game state across reloads:

impl Plugin for MyGame {
    fn save_state(&self) -> Vec<u8> {
        format!("{},{}", self.x, self.y).into_bytes()
    }

    fn restore_state(&mut self, bytes: &[u8]) {
        if let Ok(s) = std::str::from_utf8(bytes) {
            let parts: Vec<&str> = s.split(',').collect();
            if parts.len() == 2 {
                self.x = parts[0].parse().unwrap_or(0.0);
                self.y = parts[1].parse().unwrap_or(0.0);
            }
        }
    }
}

**Optional CLI path**

“`bash

mm run –watch

“`

`mm run –hot-reload` works too. It is the same hot-reload mode, kept as an alias for `mm run –watch`.

Multiple Plugins

Games are composed from multiple focused plugins. Each plugin does one thing.

plugins/
├── my-game/        # Main game logic
├── player/         # Player movement and input
├── enemies/        # Enemy AI
└── ui/             # Score display

Add a new plugin from the future MM Studio Desktop App (coming Q2 2026): click New Plugin in the project sidebar, name it,

pick a language, and it scaffolds everything for you.

mm plugin new creates a plugin skeleton. For a full game project with game.toml,

plugins/, and the rest of the project structure, use mm init .

If you are experimenting with the roadmap C# flow later, install the .NET SDK first so dotnet --version works before you scaffold or build a C# plugin. If dotnet is missing, C# plugin scaffolding and builds will fail.

Plugins communicate via events. The kernel handles load order (declared in plugin.toml

dependencies).

**Optional CLI path**

“`bash

mm plugin new player

mm plugin new enemies –lang csharp

“`

MM Studio Dashboard (Web)

**Status:** The `mm studio` command is available in CLI builds today and launches the **MM Studio Dashboard (Web)** as a local web server on `http://localhost:4242`. The dashboard (Plugin Manager, Live Event Stream, Scene Inspector, Performance Monitor) is functional for local development today.

**Not the same as the MM Studio Desktop App.** The dashboard is browser-based and launched by the CLI with `mm studio`. The desktop app is a separate standalone download (no Rust or CLI required) coming Q2 2026 for Windows and Q3 2026 for Linux/macOS. Check [mostlymodular.gg/install/](https://mostlymodular.gg/install/) for availability.

While your game is running, the MM Studio Web Dashboard gives you:

Plugin Manager — see loaded plugins, enable/disable, trust status

Live Event Stream — real-time event bus with filtering

Scene Inspector — entity tree and component editor

Performance Monitor — frame time, memory, plugin budgets

You can also access the dashboard in a browser at http://localhost:4242.

**Using MM Studio over SSH?** `mm studio` runs at `http://localhost:4242` on the remote machine.

To access it from your local browser, forward the port:

“`bash

# On your local machine:

ssh -L 4242:localhost:4242 user@yourserver

“`

Then open `http://localhost:4242` in your local browser.

Or launch without browser auto-open: `mm studio –no-browser`

Project Structure

A typical MM game project (as scaffolded by mm init):

my-game/
├── game.toml               # Project config and gameplay knobs
├── pack.toml               # Pack metadata (name, version, description)
├── Cargo.toml              # Rust workspace (auto-generated)
├── README.md               # Project readme
├── .gitignore              # Sensible defaults pre-configured
├── .mm-journey             # Tracks which preset was used (safe to commit)
├── plugins/
│   └── my-game/            # Main plugin crate
│       ├── Cargo.toml
│       ├── plugin.toml     # Plugin manifest
│       └── src/
│           └── lib.rs
├── assets/                 # Game assets (sprites, audio, fonts, etc.)
├── games/                  # Game configurations
├── specs/                  # Design specs
└── docs/
    └── DESIGN.md           # Design doc (generated per preset)

.mm-journey tracks which preset this project was scaffolded from. It’s safe to commit — MM uses it to suggest relevant next steps.

plugin.toml Reference

Every plugin has a plugin.toml:

[plugin]
name = "my-game"
version = "0.1.0"
context = "game"         # "game", "editor", or ["game", "editor"]
latency = "realtime"     # "realtime", "async", "init", or "background"
description = "My awesome game"

[events]
# Optional: declare events this plugin produces/consumes

[dependencies]
# Other plugins this one depends on
# player = "*"

Latency classes

| Class | When it runs | Use for |

|——-|————-|———|

| realtime | Every frame | Rendering, physics, input, game logic |

| async | Own schedule | Asset loading, networking, file I/O |

| init | Startup only | Config, registration, one-time setup |

| background | Periodically | Analytics, autosave, cleanup |

Troubleshooting

Build fails in the MM Studio Web Dashboard

Check the build output panel for the specific error. Most common: a syntax error in

your plugin code. Fix the error, save, and click Build again.

Plugin not loading

Check your plugin.toml — make sure latency is one of realtime, async, init,

or background. Other values cause a parse error.

Build errors about WASM target (CLI users)

rustup target add wasm32-unknown-unknown

`mm doctor` will warn if this target is missing and show the exact fix command.

mm run fails: “No built plugins found and Rust is not installed”

This means you need to build first — and Rust must be installed and in your PATH.

On Windows (Option B path), you need Rust before MM Engine works:

winget install Rustlang.Rustup
# Then close and reopen PowerShell

On Linux:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.profile

Then build your project before running:

mm build    # fresh Rust install: 5-10 min (downloading crates); subsequent builds: under 1 second
mm run

If you installed via Option A (GNU toolchain), crates may already be cached — expect under 1 minute.

If Rust crates are already cached, even first builds may be fast.

Don’t want to install Rust?

The MM Studio Desktop App for Windows (coming Q2 2026) will let you run pre-built templates without Rust. Until then, Rust is required for mm build. Check mostlymodular.gg/install/ for availability.

Linux MM Studio is coming soon. Linux users should use the fully supported CLI path for now with mm init, mm plugin new, mm build, and mm run.

mm run: no .wasm files found (CLI users)

Run mm build first. The .wasm files need to exist before the kernel can load them.

If game.toml lists plugins under [plugins.required], treat that as the intended project/plugin wiring, not proof that matching .wasm files are already present. On the CLI path today, mm run still depends on built or preinstalled WASM assets.

What is the .prebuilt marker file?

When you run mm init --preset , MM writes a .prebuilt file in your plugin directory. This marker tells MM that the preset template is based on a pre-built binary.

If a matching .wasm is installed (e.g., from MM Studio): mm run works immediately, no Rust needed.

CLI path (no pre-built .wasm installed): The marker exists, but the binary isn’t there. Run mm build first (requires Rust). The .prebuilt file is harmless — it won’t block builds.

If you see “no WASM files found” after mm init, run mm build to compile your plugin.

Build errors about OS threads or sockets

Your plugin compiles as a cdylib for wasm32-unknown-unknown. Anything that touches

OS threads, files, or sockets directly won’t compile. Use the kernel’s event system

for I/O instead.

Next Steps

[Build Your First Game](/docs/first-game/) — The step-by-step game-building

walkthrough. Pick a language, add one menu action, build, and play.

[Plugin Guide](docs/PLUGIN-GUIDE.md) — Deeper dive into writing plugins

[API Reference](docs/API-REFERENCE.md) — Complete list of host functions and events

MM Engine — build something fun.