MudEngine Part 6: Multiplayer

Step 3 / 12

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

Replace your Cargo.toml with this:

mud-engine/Cargo.toml

[package]
name = "mud-engine"
version = "0.1.0"
edition = "2024"

[dependencies]
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"] }

🔍 What each dependency does

Crate	Purpose
`dioxus` with `fullstack`	Enables the fullstack server/client split, server function macros (`#[get]`/`#[post]`), SSR, and the Axum integration
`dioxus-fullstack`	Provides `use_websocket`, `Websocket`, and `WebSocketOptions` for typed WebSocket connections
`serde`	Serialize/deserialize the message enums sent over the WebSocket
`tokio` with `sync`	`broadcast::Sender` and `broadcast::Receiver` for fanning out messages to all connected clients
`uuid` with `v4`	Generate unique player IDs on the server when a new player joins

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 / 12

◀ Prev Next ▶