← All Workshops

MudEngine Part 7: Save & Load

Step 9 / 10
◀ PrevNext ▶

Run it!

Start the fullstack dev server with dx serve. The server loads game.toml from the project root on first WebSocket connection.

Make sure game.toml exists in the mud-engine project root before starting — the server panics if it's missing.

Serve the persistent MUD
dx serve --open
🧪 Testing persistence

Basic play-through (same as Part 6)

Open two browser tabs side by side with different names — Alice and Bob. They connect, move around the grid, see each other's positions, and disconnect. Everything works the same as Part 6.

Check game.toml gets populated

With Alice and Bob connected, open game.toml:

[[players]]
id = "550e8400-e29b-41d4-a716-446655440000"
name = "Alice"
room = 4

[[players]]
id = "6ba7b810-9dad-11d1-80b4-00c04fd430c8"
name = "Bob"
room = 1

After Bob moves to Hilltop (room 1), re-read the file — Bob's room field has changed.

Server restart behaviour

  1. With Alice and Bob in the world, stop the server with Ctrl+C
  2. Start it again with dx serve --open
  3. Refresh Alice's tab — she gets a fresh connection with a new ID
  4. Open game.toml — the player entries from the previous session are gone (they were live connections)

What IS persisted

The room definitions are always loaded from game.toml. You can edit room names, descriptions, or exits, then restart the server to see the changes without recompiling:

Change "Forest Path" to "Enchanted Glade" in game.toml, restart, and the grid will show the new name.

What is NOT persisted across restarts

Player entries are live session data. When the server stops, all players disconnect and the file is saved with those entries removed (the disconnect handler fires). On restart, game.toml starts with the [[players]] section empty — that's the intended behaviour for a session-backed MUD.

🚦 Troubleshooting

Server panics on startup — "Failed to read game.toml" → Make sure game.toml exists in the mud-engine project root (same directory as Cargo.toml). The server won't start without it.

"cannot find type RoomInfo" or "cannot find type TomlGame" → The order of definitions in main.rs matters. RoomInfo, TomlRoom, TomlGame, etc. must be defined before the server module block that references them.

Grid cells show empty names → The State message includes room data. Check the message receive loop handles rooms from the State payload — the room map must be populated from ServerMessage::State { rooms: r, .. }.

"failed to resolve: use of undeclared crate or module toml" → Add toml = "0.8" to your Cargo.toml dependencies and re-run dx serve.

Movement still uses old EXITS → Remove the old pub const EXITS block from mod srv and replace the movement validation with the can_move function. The old code indexes into a slice; the new code searches rooms by ID.

"error[E0061]: this function takes 2 arguments but 3 arguments were supplied" → The ServerMessage::State variant now has a third field rooms. Make sure all pattern matches (both the send and the receive sides) include the new field.

Step 9 / 10
◀ PrevNext ▶