A picture worth a thousand rooms: the Worldmap project by Hades_Kane and Grieffels

A couple of months ago, I came across the Worldmap project in a reddit thread posted by Hades_Kane. To be honest, I’m not the most experienced when it comes to ROM codebases, so much of his original post flew right over my head!

Defines? WEdit? What? 😂

But what I did understand is that the Worldmap project is a way to build out a ROM-based world from images files, and that alone was intriguing enough.

I reached out to learn more about the project, and today’s post is the result – an interview with one of the two creators behind the project.

In this interview, Hades_Kane generously shares his experience creating the Worldmap system, how it works, and some lessons learned along the way.

Whether you’re a seasoned ROM developer, brand-new to text-based gaming, or just like clever game design, I hope you’ll find plenty of inspiration in this post!

Meet Joseph: the vocals behind Critical Failure

Better known as Hades_Kane, or Diablos in some online circles, Joseph is based in the northwestern part of Louisiana and is half of the brainpower behind the Worldmap project.

When he’s not eyeballs-deep in code or talking worldmaps with his longtime collaborator Matt (AKA Grieffels), you might find him on stage as the lead vocalist of a nerd-themed band called Critical Failure. He’s also an aspiring author and hobbyist photographer, which might explain the level of care and craft he has brought to the Worldmap project.

Matt, who lives in northeast Tennessee, shares Joseph’s love of MUDs and coding. The two have been friends for decades, having met on a Final Fantasy-themed MUD back in the late ’90s.

While Matt didn’t take an active part in the interview, he encouraged Joseph to speak on behalf of their joint project – and it’s clear the two work closely and trust each other’s instincts.

Joseph’s journey into MUDs

Joseph’s first brush with MUDs came in the mid-90s, thanks to good ol’ AOL. He was a teenager at the time, exploring the early digital frontier like so many of us did back then. Among the few free games available on the platform were the Simutronics titles DragonRealms and GemStone III, which he remembers stumbling through in his early teens.

I couldn’t help but chuckle when I learned that. After all, I got my own start in text-based games playing those exact same titles, at about the same time. (And if you did, too, drop us a shout-out in the comments!)

Although his family didn’t keep AOL for long, Joseph’s curiosity didn’t fade. A year or so later, once he had internet access again, he discovered zMUD (Zugg’s MUD client) and started using its built-in directory to find new games.

That’s when he discovered The MUD Connector, a site that listed hundreds of text-based games, including the Final Fantasy-inspired game Realmz of Delusion. Although no longer running, Realmz was built on the ROM codebase, a popular engine at the time for creating MUDs.

“There was something extra magical in those early days with exploring these worlds and how vividly they came to life for me with something as simple as a few sentences of text,” Joseph told me.

Before long, just playing wasn’t enough – he wanted to start building. And ohhhh, do I know this feeling well!

“After only a few months of playing on [Realmz of Delusion], I learned how to build because I wanted to contribute,” he said.

That game is also where he met Matt, a fellow Final Fantasy fan who would later become his co-developer on multiple projects.

Joseph’s development background comes almost entirely from ROM, with nearly two decades of experience coding in C on his main MUD project, End of Time. Meanwhile, Matt has explored a wider range of systems and often brings alternative solutions to the table.

The two balance each other well, and their collaboration is part of what makes the Worldmap project so comprehensive.

Speaking of… let’s take a closer look at what the project is all about!

The Worldmap Project: building text-based worlds using image files

At a glance, the Worldmap project might look like a clever workaround for traditional MUD mapping limitations, but it’s more than that. It’s a reimagining of how overland maps can be created, visualized, and navigated in ROM-based games.

Most MUDs don’t start with a bird’s-eye view of the world. Instead, areas are painstakingly built one room at a time by builders. You might get an ASCII mini-map or a hand-drawn reference map if you’re lucky, but the structure of the world is rarely visible at scale. (Though, see this interview afterward for one of my favorite exceptions!)

“AFKMUD and Smaug are the main codebases out there that often feature an image loading based worldmap, while ROM and others have typically relied on a large grid of linked rooms that use a certain room flag and the sector/terrain of the rooms to create a visual map,” said Joseph. 

Joseph and Matt’s system changes that by extending image loading to the ROM codebase.

“Image loading systems take a PNG, BMP, or RAW file and translate the RGB values of each pixel into an associated sector/terrain, and load that into a map array that stores the data and ultimately displays a visual map based on that,” said Joseph, laying out the basics. “We wanted to help others working with ROM have an option for the image loading type of map.”

Here’s where things start to get really clever:

Instead of assigning a separate vnum (virtual number) to every single pixel on the map, the entire worldmap exists inside a single room. A player standing anywhere on the map always occupies that one room. Their position is tracked using a pair of X/Y coordinates that correspond to the original image.

As Joseph explained, “Each worldmap itself is actually contained within a single room/vnum, and every character and object has values in their structure that defines what map and coordinates they are in. The code compares those values with the map itself and every other character or object on the map, making any mismatches behave as though the characters or objects are in separate rooms.”

So cool! I never would have thought to place characters in one room per map and then change their underlying coordinates. But it makes so much sense when you think about it.

1. First, you save thousands of vnums that would otherwise be spent representing each individual room. This means less vnum bloat and faster lookups when the code needs to search across vnum entries.
2. Second, you gain the ability to track every player, mob, or object on the map precisely using coordinates. If someone is standing at X 412 Y 363, the game knows exactly where that is and what terrain they’re standing on.

From a player’s perspective, it feels like moving across a classic JRPG overworld. From a developer’s perspective, it unlocks massive time savings and flexibility.

You can revise the shape of a continent, tweak the terrain, or add a mountain pass just by editing the PNG and reloading the map – no digging or relinking required. 🤯🤯🤯

Create maps with MS Paint, edit them in-game

One of the most impressive things about the Worldmap project is how approachable it is. You don’t need fancy software or a deep understanding of the codebase to get started. In fact, you can begin designing your world with something as simple as MS Paint.

The system also comes bundled with example PNG maps and a ready-to-use color palette. Developers can either start from scratch or edit one of the included templates. As long as your image editor can save in a simple image format, you’re good to go.

Here are some real example images used in the project:

Once you’ve created your map image, the system reads the RGB values of each pixel and converts them into terrain data, building the entire map from that image.

It’s a refreshingly simple approach; you can quickly draw a continent, drop it into the game, and start exploring.

The system also includes a set of in-game tools that let builders modify the map from inside the game itself. No need to edit files manually.

For example, you can:

• Place specific terrain types (like forest, water, or road) at chosen map coordinates using in-game commands
• Enable an “autowalk” mode that updates terrain as you move
• Use tools like floodfill or fractal placement for larger edits
• Fine-tune the terrain or fix errors with a built-in world editing system (WEdit)

The in-game interface is designed to feel familiar to ROM developers, mirroring the format used by REdit and MEdit so that users don’t have to memorize obscure commands or consult helpfiles constantly.

Joseph and Matt also focused on reducing code duplication and making configuration easier.

For example, adding a new map only requires just a few quick edits – like adding a line to a list of maps, defining a short label for it in the code, and updating a setting that tracks how many maps exist.

“Within the code, there are about a dozen ‘configuration’ defines that can be commented or uncommented to alter how aspects of the map work, making single location alterations available for changing things such as whether movement points count on the worldmap, whether sector type affects map viewfinder radius or distance at which you can see others, whether objects show on the map, or whether certain color depth options are enabled,” said Joseph.

There are even optional visual upgrades like night mode, which dims the ASCII map after sunset, and light sources, which let characters with torches brighten the area around them.

The area lighting effects were inspired by Niymiae’s work on the Italian game Lumen et Umbra. However, Joseph notes that Niymiae’s system is “leaps and bounds more advanced” than what they chose to implement here.

Oh? I haven’t mentioned yet that Joseph and Matt’s project also includes a built-in ASCII map system? It’s one of the bells and whistles packaged in StockMUD+, the ROM codebase they’ve put together. More on that below!

With multiple pre-made maps, optional area links, and clean integration with the ROM codebase, it’s clear Joseph and Matt weren’t just building a tool for themselves – they were thinking about how to make it useful for others, too.

Note: a define is a kind of shortcut or label used in C programming. It tells the compiler, “Every time you see this name, substitute it with this value or behavior.” It’s commonly used for toggling features or assigning IDs.

Accessibility built-in: making the map usable for everyone

One of the most thoughtful aspects of the Worldmap project is its built-in support for screen reader users. This isn’t just some checkbox feature – it’s baked into the system.

Joseph and Matt designed the system with accessibility in mind, drawing on years of feedback from players with visual disabilities who’ve played Joseph’s main game, End of Time.

Since the visual map relies on symbols and colors, it’s not something a screen reader can interpret directly. But instead of excluding those players, the system offers a text-based alternative that provides meaningful spatial information using coordinates and terrain descriptions.

Here’s how it works:

• When a player with screen reader mode enabled moves across the map, the game outputs their current X/Y coordinates, the terrain type, and any nearby points of interest.
• The output is short and to the point, but still gives players the info they need to understand where they are and what’s nearby.
• When a player uses the “look” command manually, they receive additional information about surrounding terrain.
• If the player also enables “brief” mode, the output becomes even more compact, reducing repetition while still offering key navigational cues.

Here’s a sample of what that might look like:

World Map Coordinates X 412 Y 363
Terrain: grassy field here.
grassy field, north, northeast, south, southwest, west, northwest and further, southeast.
forest and further, northeast, southwest, northwest.
road, southeast.
West of the Nikeah Port is in the near vicinity to the east at coordinates 415 X 363 Y

And while encountering a point of interest while moving:

> east

X 392 Y 366, grassy field here.

> east

X 393 Y 366, grassy field here.

> east

X 394 Y 366, grassy field here.
West of the Nikeah Port is off in the distance to the east at coordinates 415 X 363 Y

However, Joseph did emphasize that developers using the system should design their maps with accessibility in mind. It’s not just about the code, he said, but also how you lay out your world.

His tips are incredibly practical and include:

• Using roads or trails to create logical, followable paths between major points of interest
• Adding signage or markers that give rough directions and coordinates to nearby areas
• Making sure towns and major features are visible from a distance (with larger visibility radii)
• Including narrow passes or bridges to guide travel through tricky terrain
• Supporting automated travel between areas, where appropriate

The full system (more on this below) also includes a “scan” command that works like a radar, listing nearby terrain and features with their distances and coordinates. This further helps players who can’t rely on visual cues.

As Joseph put it, the screen reader support is based on what’s worked well in End of Time over the years. It may not be perfect yet, but it’s functional, inclusive, and continuously improving.

For a bit of history on End of Time, you might find this mud.fandom entry interesting.

Overcoming challenges: one vnum, many moving parts

For all its polish and ease of use, the Worldmap system didn’t come together overnight.

As Joseph explained, one of the biggest technical hurdles was making the system work within the structure of a traditional ROM codebase – particularly the part where every player, mob, and object appears to move around a giant map, despite occupying only a single room.

“The biggest challenge with this system is how much care that is necessary in ensuring that certain checks are in place all throughout the code to properly ensure that the way it ‘fakes’ each coordinate being a separate room is working,” he said. “Forget one check, and things can get pretty screwy!”

Everything on the map exists in the same virtual space, but what you can see and interact with depends entirely on where your coordinates place you. If two players are standing at different positions on the same map, the game treats them as if they’re in different rooms – even though they’re technically in the same one.

Because everything depends on coordinates instead of room numbers, the system frequently needs to check each player’s coordinates to make sure they’re only able to interact with things at their precise location.

It’s a delicate dance, but the result is worth it: a fluid overland map where developers can manage thousands of locations in a fraction of the time.

Lessons learned: cleaner code, better balance

Joseph has been working on MUDs for more than two decades, and like many long-time developers, he’s learned a lot through trial and error. His approach to code has evolved significantly since those early days of figuring things out on his own.

“I’ve never had any formal education with coding and have really learned by doing,” he told me. “Some of the biggest takeaways for me over the last few years I wish I had a better grasp on earlier would have to be things like memory management and better organization in the code.”

One of the most important shifts in his thinking was the move away from copying and pasting similar lines of code. Now, he tries to keep things clean and efficient by relying more on helper functions – reusable blocks of logic that make the codebase easier to maintain and less prone to errors.

“We focused very intently on performance and memory with this system, and tried to be as efficient with our functions as we could,” Joseph said.

That mindset helped shape the Worldmap project. Joseph and Matt were both committed to making it efficient, modular, and easy to configure. They didn’t want future developers to have to fight with fragile systems or track down bugs caused by repetitive code scattered across dozens of files.

Just as importantly, Joseph spoke about the personal side of the project. Back in the day, MUDs took up most of his free time. These days, it’s more of a balancing act between music, writing, photography, and code.

“For the first bit of 2025, it’s been very intently focused on MUDs,” he said. “When work is slow, I’m sometimes able to get some coding in during then, as well.”

Working with Matt has also been a standout experience. While MUDs are almost always collaborative to some degree, this project was different. The two of them were working in the same codebase, often on the same systems, and shaping the architecture together in real time.

“Matt has always had this knack for motivating others in his various projects,” Joseph said. “His enthusiasm has definitely helped me stay focused.”

Working that closely with someone you trust can be a rare treat. It also helped take this project from a fun technical experiment to a serious tool with the potential to benefit the wider MUD community.

Community resources and recommendations

For anyone thinking about tackling a similar project, Joseph has some practical advice mirrored by many of my previous interviewees: don’t go it alone.

He points to r/mud and its companion Discord server as one of the most active, welcoming spaces in the current MUD landscape. While older sites like The MUD Connector, MudBytes, and Top MUD Sites still hold value, much of the day-to-day conversation has moved elsewhere.

Joseph also recommends taking time to play other games and experience different systems from a player’s point of view.

It’s easy, he says, to get caught up in the developer mindset and forget what it actually feels like to use the systems you’re designing. This is also something previous interviewees have said, and it speaks to Joseph’s growth and level of experience.

Stepping back and engaging with your game like a player can help you catch awkward flows or usability issues before they turn into frustrations for others.

Another piece of advice that stood out was about accessibility. Based on his experience making End of Time more screen reader-friendly, Joseph emphasized that it’s far easier to design with accessibility in mind from the beginning than to try retrofitting support for it later.

“I’ve spent a significant amount of time over the last few years trying to make EoT as screen reader friendly as I can,” he said. “And there’s still plenty of room for improvement there.”

That’s part of what makes the Worldmap project so inspiring. It’s not just a tool for creating intricate, JRPG-style overworlds – it’s also a framework that encourages inclusive design and player-first thinking.

Whether you’re building a new MUD from scratch or modernizing an old ROM codebase, the tools and philosophy behind this system offer a great starting point.

What’s next: StockMUD+ and When Worlds Collide

The Worldmap project is already available, but rather than doing a formal launch, Joseph and Matt took a more grassroots approach: they put together a simple webpage and have been keeping the project visible through the r/mud subreddit, its Discord server, and their own dedicated Discord community.

The Worldmap system is bundled as part of StockMUD+, a ROM-based codebase Joseph and Matt have been steadily enhancing. It’s not tied to a strict release schedule – they add to it when they have the time. Eventually, they plan to make it available on GitHub.

StockMUD+ is designed to be modular and flexible. It includes optional quality-of-life features like expanded color support, modern mapping tools, and configurable settings.

Developers can start with:

• A ready-to-go worldmap with stock areas placed and linked
• An in-game ASCII map system with screen reader support
• A blank all-water map for designing their own world
• Or no worldmap at all, using traditional room-based navigation

Meanwhile, Matt is continuing development on his game, When Worlds Collide, which blends elements from Final Fantasy III and V. His goal was to get the Worldmap system in place early so he could build and test other systems on top of it – and now he’s diving into things like custom combat mechanics and a modular job system inspired by JRPGs.

The two projects – WWC and StockMUD+ – are deeply connected. Joseph and Matt continue to share code, swap ideas, and improve systems together, with an eye toward making tools that not only power their own games but also benefit the broader MUD community.

And if you’re curious about When Worlds Collide, the game isn’t open to public just yet, but you’re welcome to join the project’s Discord server to follow updates, ask questions, and share ideas.

Giving credit: the people behind the progress

Behind every long-running MUD project is a network of people who’ve helped along the way – and Joseph is quick to acknowledge that.

“If it weren’t for Matt, it’s entirely possible End of Time might have sat on a disc somewhere in my filing cabinet and I wouldn’t be where I am with it today,” he said.

It was Matt who encouraged Joseph to bring EoT back online, even helping him get it running on a server when Joseph was still unsure whether it was worth reviving. Their continued collaboration across EoT, the Worldmap project, and now StockMUD+ has been a major force behind everything Joseph has built over the past few years.

He also named a few other key figures who helped him get his footing in the early days of development:

• Ryzic (Justin Cooper), who Joseph credits as being instrumental in his early time as lead developer
• Titania (Sophie), who contributed code and helped shape systems he still uses
• Samson, whose overland map system for SMAUG served as the original inspiration for adapting something similar to ROM
• And the many helpful folks in the r/mud Discord server, who’ve provided feedback, support, and second opinions when he’s run into tricky issues

Joseph also gave a special shout-out to Luminari MUD, which influenced the default color palette used by the PNG image part of the worldmap system.

If there’s one thing that’s clear, it’s how much Joseph cares about the MUD community – not just the games, but the people keeping them alive.

As much as the Worldmap project is a technical achievement, it’s also a reflection of that shared legacy – and a way of giving back.

Final thoughts: building for the future

What struck me most about this interview wasn’t just the technical feat of coding in coordinates for every character, room, and object and tying them to a flexible image-based map – though that’s certainly impressive!

Rather, it was how much care Joseph and Matt have put into making their work usable, flexible, and shareable.

They didn’t just build a tool for their own games. They built a system that developers of any experience level can take advantage of. They thought about the things that actually matter – like accessibility, simple setup, and not making your future self want to scream. That’s what takes a project from cool concept to something others might actually want to use.

I also appreciate how deeply rooted this system is in practical experience. Joseph has been through the trial-by-fire of messy codebases and accessibility oversights. Rather than gatekeeping or hoarding that knowledge, he’s passing it along in a form that others can benefit from.

And honestly? I think that’s one of the most generous things you can do as a developer in this space.

So if you’re working on a ROM game, or thinking about creating a new one from scratch, take a look at the StockMUD+ worldmap system. Even if you don’t end up using it exactly as-is, you’ll probably walk away with some ideas about how to structure your own world.

It’s projects like these that remind me that MUDs are still evolving.

A big, warm thank you too Joseph / Hades_Kane for taking the time to do this interview! I learned a ton, and it gave me new ways of thinking about map systems in MUDs that I never would have come up with on my own.

During the process of writing this post, I even challenged myself to build my own PNG map loading system in Evennia, just to see if I could do it. And I could! It was a fun proof-of-concept project that I never would have taken on if not for Joseph and Matt’s hard work.

If this project inspires you too, leave a comment below and tell us about your experience!

About the author

Andruid (she/her) is a writer, roleplayer, storyteller, and nerd who tries to live by Bill and Ted wisdom, i.e. "Be excellent to each other." She created Writing Games to share lessons learned and to introduce new players to the world of text-based games. Learn more.