Building Space MUD: A Text Game About Robots on a Space Station

The premise is simple: you wake up on a broken space station. You don’t remember anything. You start exploring, picking up items, talking to other units, repairing systems. And at some point it clicks — you’re not a person. You’re a robot. The whole game uses mechanical language from the start. Your health is “integrity.” You don’t sleep, you go idle. When you die, it’s an “emergency reboot.” The station doesn’t call you a crew member. It calls you a unit.

I wanted to build a game where the setting does the storytelling. No cutscenes, no quest text walls. Just a world that makes you feel something when you pay attention to it.

Why a MUD

MUDs are text-based multiplayer games. They’ve been around since the late 1970s. You type commands, read descriptions, and build a mental picture of the world. There’s something about them that modern games can’t replicate — the way your imagination fills in the gaps between sentences.

I also wanted to build something multiplayer without dealing with graphics, netcode, or asset pipelines. A MUD is pure systems design. The world is data. The interactions are logic. I could focus entirely on how the game feels to play without spending months on rendering pipelines.

Evennia

Evennia is a Python framework for building MUDs. It handles all the server infrastructure — telnet connections, a web-based client, user accounts, persistence, command parsing. You write your game logic as Python classes that hook into its system.

It uses Django under the hood, which means you get a database ORM, an admin panel, and a reasonably sane project structure. The learning curve is moderate. The docs are extensive but sometimes assume you already know what you’re looking for. I spent a lot of time reading source code.

The thing I like most: Evennia stores all game objects in a database with arbitrary attributes. An NPC, a room, a weapon — they’re all the same base object with different typeclasses and different attributes attached. That flexibility made it easy to build weird systems without fighting the framework.

The World

The station has 15 rooms across 2 zones:

Central Station is the starting area. Seven rooms connected by corridors. A main corridor, storage hub, repair bay, reactor terminal, observation deck, data core, and docking port. This is where you learn the game. The NPCs here give you missions, the items are safe to pick up, nothing attacks you.

The Outer Zone is where things break down. Eight rooms, all damaged. Collapsed corridors, a breached lab, a cargo wreck, crew remnants, an airlock, a communications array, debris drift. Hostile entities patrol here. The descriptions get darker. The station is falling apart and it shows.

I kept the world small on purpose. Fifteen rooms is enough to explore without getting lost, and every room has something in it — an item, an NPC, a repairable system, or a hostile. No filler corridors. If you’re in a room, there’s a reason to be there.

The Data Layer

All world content lives in JSON files:

{
  "key": "Main Corridor",
  "zone": "central",
  "desc": "A long corridor stretches ahead. Overhead panels flicker...",
  "exits": ["north:Reactor Terminal", "south:Observation Deck", "east:Storage Hub", "west:Repair Bay"]
}

Rooms, exits, NPCs, items, hostiles, repairable objects — each has its own JSON file. A batch script reads them all at startup and creates the corresponding Evennia objects. Want to add a room? Edit a JSON file and reload.

This separation was one of my better decisions. It means I can tweak the world without touching Python code, and the game data is human-readable. I can hand someone the rooms.json file and they immediately understand the station layout.

Systems

The game has more systems than you’d expect for 15 rooms. Each one adds a layer of decision-making.

Chassis

In the Repair Bay, there’s a Chassis Terminal. You pick a frame — one time, permanent choice. Each chassis changes your stats and gives you a passive ability:

• Scout Unit — faster, more power, enhanced sensors that show adjacent room exits
• Heavy Unit — tankier, more shielding, takes reduced damage per hit
• Repair Unit — higher repair level, self-regenerates integrity over time
• Infiltrator Unit — more processing power, hostiles are less likely to notice you
• Broadcast Unit — balanced stats, can message other players across zones

The choice matters because it shapes how you interact with the station. A Repair Unit can fix high-level systems that other chassis can’t touch. A Scout sees more of the map. An Infiltrator can move through hostile areas without fighting.

Professions

Once you hit level 3 and have a chassis installed, you can pick a profession at the Protocol Terminal in the Data Core. Four options, each with different stat growth per level and two unlockable skills:

• Combat Protocol — hits harder, gets upload_virus and overclock
• Systems Engineer — repair-focused, gets emergency_patch and diagnostic_scan
• Infiltration Protocol — power-heavy, gets hack_console and stealth_mode
• Broadcast Protocol — balanced, gets signal_boost and power_surge

Combat

Combat is automatic once you engage. You type attack <target>, and rounds tick every 2 seconds. Your processing stat determines damage dealt, their shielding reduces it. If your integrity hits zero, you reboot in the Repair Bay at 25%. Simple, but it works.

There’s a PVP zone too — Debris Drift. Everywhere else, attacking other players is blocked.

Missions

Five missions from two NPC quest givers. Collect items, visit locations, kill hostiles, repair systems. They give XP and credits. Nothing revolutionary, but they give you direction when you first log in and don’t know what to do.

Repair

Damaged station systems are scattered across the map. You need the right repair level and the right components in your inventory. Some repairs have prerequisites — you can’t fix the Communications Relay until you’ve repaired the Sensor Array first. This creates a natural progression without explicit level gates.

Design Philosophy

I had three principles:

Discovery over direction. The game doesn’t tell you what to do. It gives you tools and a world and lets you figure it out. The chassis choice isn’t explained through a tutorial — you find the terminal and read what it offers. Missions exist, but they’re optional. The most interesting thing in the game might be repairing every system on the station, and no quest tells you to do that.

Atmosphere over content volume. Fifteen rooms with good descriptions beat a hundred rooms with filler. Every room description is written to make you feel the state of the station — flickering lights, sparking conduits, the silence of a breached hull. The game is short. That’s fine. I’d rather someone spend an hour in a world that feels real than ten hours in one that feels generated.

Mechanical identity. You’re a robot. The entire game reinforces that through language. You don’t “heal,” you “repair.” You don’t “die,” you “reboot.” Your stats are processing, shielding, integrity. The NPCs call you “unit.” This isn’t flavor text — it’s the core design decision. The game is about discovering what you are by paying attention to how the world talks to you.

What’s Next

The game is live at play.imadestuff.com:4001. You can play it right now in your browser. It also accepts telnet connections on port 4000 if that’s your thing.

I have ideas for more content — a third zone, more missions, some kind of crafting system. But honestly, the game does what I set out to make it do. It’s a small, atmospheric, multiplayer experience that you can poke around in for an evening. Sometimes that’s enough.