One of the biggest architectural changes in our MUD engine Hexagon is replacing the traditional room system with a new location system built around an Entity Component System (ECS) pattern.

The Problem with Rooms

The classic MUD room is a monolithic object. A room that contains a shop has to inherit from a shop class. A room with a pub inherits from a pub class. If you want a room that is both a shop and a pub, you need multiple inheritance, which in LPC gets messy fast. And then you want to add a sign, or make it dark at night, or have an NPC attendant, and you end up with inheritance chains five levels deep where half the code is workarounds for the other half.

Components Instead of Inheritance

The ECS approach flips the model: a location is a container, and features are components you attach to it. A shop is a component. A pub is a component. Having climate effects is a component. You can mix and match them freely without worrying about class hierarchies, because you compose locations by mixing components, not by stacking class hierarchies.

In practice, this means a location file could look something like this:

// A tavern that also sells equipment
add_component("shop", ([
  "items": (["sword": 100, "shield": 150]),
]));

add_component("pub", ([
  "menu": (["ale": 5, "mead": 7]),
]));

// And this location is outside and has weather effects
add_component("outside");

Each component manages its own state and responds to player actions independently. When a player types look, the location queries all its components for their descriptions. When a player types buy sword, the location routes the action to the component that responds to buy actions, which checks if it has that item for sale.

What Changed

The conversion touched almost every part of the codebase that dealt with rooms:

• Actions and targets: the action system now treats components as valid targets. If a location has a shop component, buy and sell work without the location needing to know anything about commerce.
• Builder tools: call function() @component: now you can call functions directly on components from the command line, which makes testing and debugging much easier.
• Darkness and weather: the dark/night/outside system was refactored to work as a location property rather than a room class feature.

The old room system still works. We did not break backwards compatibility. Rooms and locations coexist, and you can convert rooms to locations incrementally.

Ventures: Managing It All

Along with locations, we built a new ventures handler. A venture is any player-facing business in the game world: a shop, a pub, etc. The handler tracks all of them across all areas, and the ventures admin command lets you list, inspect, and manage every venture in the system from one place.

Also, every behaviour that a venture can have has been refactored so we can share the code between the location system and the old room system. So if you have a shop in a room, it uses the same underlying code as a shop component in a location.

Next Steps

The plan is to gradually convert existing rooms to locations in the different games in Hexagon. We will be also adding new components and features to the location system as we go, such as support for dynamic events, more complex NPC interactions, and better integration with the quest system. The goal is to have a flexible, modular system that can support a wide variety of locations and gameplay styles without needing to rewrite code every time we want to add a new feature or mix and match different types of locations. The old room code will stay around for a while, both for compatibility and because some simple rooms do not need components at all.

The source code is available in the Hexagon repository.

The soul system in Hexagon has been completely reworked. Souls (also called emotes or social commands in other MUD codebases) are what lets players express themselves beyond game mechanics: waving, laughing, hugging, sighing, facepalming. The stuff that turns a text game into a social space.

Why This Took So Long

Hexagon is bilingual. Every soul needs to produce correct output in both English and Spanish, accounting for verb conjugation, gender, target presence, and self-targeting. “You wave at John” becomes “Saludas a John” in Spanish, but “John waves at you” becomes “John te saluda”. Multiply that by about 80 different souls and every possible combination of arguments.

The original soul data was a tangled mix of code and translated strings. Pulling them apart into clean data files (soul-data.en.h and soul-data.es.h) meant going through every single soul and testing every variation.

How It Works

Each soul has up to four different message patterns depending on context:

1. What you see when you do it (no target)
2. What the target sees
3. What others in the room see

And then, maybe some souls can’t have targets at all, some other maybe only have self-targeting messages, or cannot be self-targeted.

For a soul like bow:

• You type bow and see “You bow gracefully.”
• Others see “Neverbot bows gracefully.”
• You type bow john and see “You bow before John.”
• John sees “Neverbot bows before you.”

And then you can add adjectives to the soul, like bow deeply: with this particular example, you could bow solemnly, deeply, formally, hastily, slightly, respectfully, insolently, clumsily, gracefully, dexterously, wildly or colorfully. And all of these combinations need to exist in both languages.

The Drunk Factor

On top of the souls rework, the intoxication system (drunk.c) was translated and connected to the soul output. A drunk character does not just type garbled text. Their emotes change too. Being drunk affects how souls display, adding slurring and stumbling to the output. And some chances of burping, puking, or some other fun drunk behaviour. This is the kind of detail, together with shops and pubs working as location components, that makes a MUD feel alive. Nobody needs it, but once it is there, players notice.

What’s Next

The soul system is working in both languages. The data files are clean and adding new souls is straightforward: define the four message patterns in each language file and the system picks them up.

The source code is available in the Hexagon repository.