MudEngine Part 6: Multiplayer

Step 3 / 18

Fullstack Setup

The single-player app compiled to a WASM bundle that ran entirely in the browser. For multiplayer we need a server that holds shared state. Dioxus Fullstack lets us write both the server and the client in the same Rust project.

Add dependencies

Add these 4 crates to your existing [dependencies]:

mud-engine/Cargo.toml

dioxus = { version = "0.7", features = ["fullstack"] }
dioxus-fullstack = "0.7"
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["sync"] }
uuid = { version = "1", features = ["v4", "js"] }

🔍 What each dependency does

Crate	Purpose
`dioxus` with `fullstack`	Enable the fullstack server/client split, server function macros (`#[get]`/`#[post]`), SSR, and Axum integration
`dioxus-fullstack`	Provide `use_websocket`, `Websocket`, and `WebSocketOptions` for typed WebSocket connections
`tokio` with `sync`	`broadcast::Sender` / `Receiver` for fanning out messages to all connected clients
`uuid` with `v4, js`	Generate unique player IDs; the `js` feature provides randomness on WASM targets

The dx CLI detects the fullstack feature automatically. Running dx serve now compiles two targets — a server binary (Axum) and a client WASM bundle — and starts them together. The server serves the WASM and handles WebSocket upgrades; the browser loads the WASM and renders the UI.

📝 No more Dioxus.toml changes needed

The Dioxus.toml you created in Part 4 works unchanged. The dx CLI reads the Cargo features and figures out the build targets.

If you skipped Part 4's CSS step, no worry — we'll add fresh styles for the multiplayer UI at the end.

Step 3 / 18

◀ Prev Next ▶