What We Do for Fun: Rebuilding a MUD for 2026

Not everything we build needs a business case.

Sometimes we build something because it solves a problem. Sometimes because someone needs it.

And sometimes we spend an unreasonable amount of time building something simply because we love it.

The Rift is one of those projects.

MUDs—and ROM in particular—have been a personal hobby of mine for decades. I've spent a lot of time over the years tinkering with these strange little text worlds, changing them, breaking them, fixing them, and imagining what else they could do.

The Rift grew out of that hobby.

Before getting into what we're building today, though, this story deserves some history—and a very large thank-you to the people whose work made projects like ours possible in the first place.

Wait. What's a MUD?

If you've never encountered one, a MUD—originally "Multi-User Dungeon"—is one of the ancestors of the modern online role-playing game.

Imagine an MMORPG where your imagination handles most of the graphics.

Instead of watching your character enter a tavern, the game might tell you what the tavern looks like. Instead of clicking on another character, you type commands.

Something like:

look
north
say Hello.
inventory
get sword
wield sword

The game responds with text describing what happened.

But this isn't simply a single-player text adventure.

Other real people are connected to the same persistent world.

Players explore, fight, talk, trade, form groups, collect equipment, solve quests, discover areas, and—in many MUDs—become part of communities that last for years.

And this style of online world is older than a lot of people realize.

Before the MMORPG, There Was the MUD

The original MUD dates back to 1978 at the University of Essex in England, where Roy Trubshaw began developing what became MUD1. Richard Bartle later joined its development.

That was long before "MMORPG" entered the gaming vocabulary.

The idea was already there, though: multiple people inhabiting and interacting inside the same computer-generated world.

Over time, MUDs branched into many different families, philosophies, engines, and communities.

One particularly influential branch eventually led to DikuMUD.

DikuMUD was developed around 1990 and 1991 at DIKU—the Department of Computer Science at the University of Copenhagen—by Sebastian Hammer, Tom Madsen, Katja Nyboe, Michael Seifert, and Hans Henrik Stærfeldt.

Its source became the foundation for an enormous family of text-based online RPGs.

And then that family tree continued.

DikuMUD
   |
   +-- Merc
         |
         +-- ROM
               |
               +-- a whole lot of hobby MUDs
                     |
                     +-- The Rift

That last branch is where our story really begins.

A Huge Thank-You to ROM

The Rift has a long history with ROM 2.4b6.

ROM—Rivers of MUD—is a C-based MUD codebase descended from Merc, which was itself derived from DikuMUD.

For an enormous number of hobbyist MUD developers, codebases like these weren't merely games.

They were playgrounds.

You could download a functioning multiplayer world, read the source, compile it, change it, add an area, create a monster, write a command, completely break something, spend three hours figuring out why you broke it, and learn something in the process.

Then you'd think of another idea and do it all over again.

ROM became the foundation for countless modified MUDs and experiments.

Ours included.

So before talking about everything we're changing, we want to say this clearly:

Thank you.

Thank you to the developers behind ROM.

Thank you to the people behind Merc.

Thank you to the DikuMUD developers.

Thank you to Roy Trubshaw, Richard Bartle, and the early MUD developers who helped establish the idea of a shared text-based virtual world in the first place.

And thank you to the countless builders, administrators, programmers, and players who have kept this wonderfully peculiar corner of gaming alive for decades.

The Rift exists because generations of developers shared their work and gave people like me something we could learn from, modify, break, repair, and eventually turn into worlds of our own.

We're proud to be one tiny branch on that very large family tree.

A Personal Hobby That Refused to Die

For me, MUDs never quite went away.

Certainly some of that is nostalgia.

But there's more to these games than nostalgia.

Text worlds have some genuinely interesting properties.

Your imagination does the rendering.

A handful of carefully written paragraphs can create a place larger than a screen full of polygons.

Developers can create enormous worlds without enormous art departments.

And because the player's primary interface with the world is language, MUDs lend themselves remarkably well to conversation, characters, storytelling, systems, and simulation.

There is also something special about connecting to a world and simply seeing:

That little prompt is an invitation.

What do you want to do?

For decades, people have been answering that question.

The Rift

The Rift started life as one of those ROM projects.

Over the years it accumulated custom systems, areas, story ideas, NPC experiments, mechanics, and increasingly ambitious plans for what its world could become.

Eventually we ran into a small problem.

We wanted the world to do things its original architecture was never designed to do.

Persistent actors.

Persistent individual items.

NPCs that can eventually have schedules, knowledge, memories, relationships, and lives beyond standing in a room waiting for a player to arrive.

Ships that actually travel through a larger spatial world.

Settlements, regions, routes, and other geography existing in coordinate space.

A world that can continue changing and operating regardless of how a player chooses to look at it.

Naturally, our response to this perfectly innocent hobby project was entirely reasonable.

We started building a new game engine.

Well, That Escalated Quickly

The goal wasn't originally:

Let's write an engine.

It happened because the world we wanted kept pushing beyond the assumptions of the system underneath it.

Today, the new Rift Engine is being built in .NET with PostgreSQL providing its durable data layer.

The traditional Telnet MUD interface still exists.

In fact, preserving it is important to us.

We're not building a graphical game and keeping the MUD around as a novelty.

Instead, we've changed what the text interface represents.

The MUD isn't the world anymore.

It's a window into the world.

And eventually, the browser can be another.

One World, Different Windows

One of the architectural rules we've adopted while rebuilding The Rift is simple:

There should only be one canonical world.

Suppose one player walks into a tavern using a traditional MUD client.

Another player eventually sees that same tavern through a graphical web interface.

Those shouldn't be two approximations of the same place.

They're in the same place.

If an NPC walks out the door, that happened.

If somebody drops an item on the floor, that happened.

If a ship is halfway between two settlements, that's where the ship is.

The Engine owns the rules and live simulation.

PostgreSQL provides durable state.

Telnet presents the world primarily through words.

Web interfaces can present that same world visually.

Different windows.

Same Rift.

Then We Needed an Actual Map

Traditional MUD geography is often built as a graph.

A room has exits to other rooms.

North leads here.

West leads there.

Up leads somewhere else.

That's incredibly effective for navigating a text game, and we're keeping that model where it makes sense.

But The Rift also needs larger-scale geography.

Worlds.

Regions.

Settlements.

Routes.

Remote sites.

Rift-space.

Ships traveling between actual positions.

So the new Engine has a spatial model above the traditional room graph.

A settlement can exist at a real coordinate in a world.

Inside that settlement can be a network of familiar MUD locations.

That gives us multiple scales:

Rift-space
    ↓
World
    ↓
Region
    ↓
Site / Settlement
    ↓
Local Locations
    ↓
Rooms and Connections

Which introduced another problem.

Editing all of that by hand would be miserable.

Naturally, We Needed a World Editor

So now our hobby MUD has its own browser-based development environment.

We call it RiftBuilder.

RiftBuilder talks to the same Rift Engine that runs the game.

On the large-scale map, we can work with worlds and sites using actual spatial coordinates.

Open a site and we can work with its local locations and the connections between them.

Those two kinds of position are deliberately different.

Dragging a room around on the editor canvas shouldn't magically change which direction its gameplay exit leads.

Moving an entire settlement on the world map, however, really does mean changing where that settlement exists.

It's an important distinction:

Geometry decides where something is.

Gameplay topology decides how local places connect.

Artwork decides what it looks like.

And all of those tools are editing the same world the game is actually running.

The Builder isn't creating a second copy of The Rift.

It's another window into it.

A Fun Bit of History

There's a tiny historical coincidence here that makes us smile.

When the original DikuMUD publicly opened at the University of Copenhagen in 1991, it ran on port 4000.

More than three decades later, while rebuilding a descendant of that software family into an entirely new engine, we needed to settle on the public Telnet port for The Rift.

The Rift Engine currently listens on:

Port 4000.

That wasn't originally intended as a historical tribute.

But we're certainly not changing it now.

Why Are We Doing This?

Because it's fun.

There are easier ways to make a game.

There are considerably easier ways to operate a MUD.

But there's something wonderfully entertaining about taking a style of game with roots stretching back nearly half a century and asking:

What happens if we stop treating its original technical limitations as rules?

What if the text interface survives, but the world behind it doesn't have to think like a 1990s MUD?

What if an NPC isn't merely a mobile loaded into a room?

What if a ship actually travels somewhere?

What if geography exists even when nobody is standing there looking at it?

What if the same character and the same persistent world can be experienced through text or graphics?

What happens when modern simulation, databases, development tools, and eventually modern AI techniques meet one of the oldest forms of shared online world?

We don't know where every one of those questions will lead.

That's part of the point.

What We Do for Fun

Cedar Harbor builds software.

But software doesn't always have to be serious.

The Rift is where we get to experiment with things because they're interesting: game engines, persistent worlds, spatial systems, development tools, simulated characters, old-school networking, and the wonderfully peculiar engineering problems that appear when you try to modernize a decades-old style of online world without throwing away the things that made it interesting.

So every once in a while, we'll use the Cedar Harbor Journal to share some of it.

What worked.

What didn't.

What we're experimenting with.

And how an innocent desire to tinker with an old text game somehow resulted in a new game engine, a database-backed persistent world, and a browser-based world editor.

Because apparently...

this is what we do for fun.

Further Down the Rabbit Hole

MUD history stretches back decades, and The Rift represents only one tiny branch of it. If this strange corner of computing history sounds interesting, these are good places to start:

MUDs / Multi-User Dungeons — an overview of the genre, terminology, and its history.
MUD1 — the pioneering shared virtual world created by Roy Trubshaw and Richard Bartle at the University of Essex.
DikuMUD — the official DikuMUD site, including the history of one of the major ancestors of ROM and therefore part of The Rift's software lineage.
ROM 2.4b6 — preserved historical ROM source and documentation for developers and curious digital archaeologists.

The new Rift Engine is an independent modern implementation rather than a port of ROM, but we're very happy to acknowledge the shoulders—and many thousands of lines of C—this hobby stands on.