Based on an interview between Eurynomos and Ursun, regarding building, areas, and differences in approach between ArmageddonMUD and Tales of Zalanthas and new mapping tools/builder approach.
--
In a recent conversation, I sat down with Ursun to talk about building, mapping, and the new Area system in development for Tales of Zalanthas MUD.
Some older DIKU/ROM MUDs, including original ArmageddonMUD, were traditionally organized through zones. Zones were useful for the era they came from. They helped divide the game into manageable chunks, separated permissions, and kept vast amounts of rooms, objects, and NPCs from living in one enormous file. Zones were often author specific – Halaster had his own Zone, Nessalin had his own Zone, Ur had his own zone, etc. So they each had their own little sandbox to play in.
By the mid-2000s – Zones were no longer author specific, and in fact, were barely organized or specific to what was contained inside of them. There was a lot of crossover, Zones running out of room, and in short – chaos!
For Tales of Zalanthas, the team is moving toward a different model: Areas. We also cover in-game (and out of game) maps and mapping, and how that will appear to both Staff/Builders and potentially players.
What Is an Area?
At its simplest, an Area is a mapped space with a consistent internal scale. Every room inside an Area has a unique X, Y, and Z coordinate. That means two rooms cannot accidentally occupy the same location, overlap strangely, or create the kind of “map wrinkles” that made some older MUD spaces (such as ArmageddonMUD) impossible to draw cleanly.
As Ursun explained it, one of the core purposes of Areas is to fix those old wrinkles.
“What I mean by a map wrinkle is that rooms are actually not on a grid, even though you think they are. You cannot map parts of the game world on a real piece of paper without overlapping yourself.”
In older building environments, mapping could become a free-for-all. Builders relied on spreadsheets, hand-drawn grids, human memory, and a great deal of trust. A city street, canyon path, or sewer corridor might feel logical while walking through it in game, but when drawn more precisely, the geometry could fold back on itself.
Areas are designed to completely prevent that. They give builders a reliable grid, but they also do more than make the map cleaner.
They give the game a sense of scale.
Scale, Movement, and the Feel of Place
Something ArmageddonMUD struggled with was a sense of scale and distance. A room inside a cramped tenement should not represent the same amount of physical space as a room in the open desert. A city alley, a plaza, a canyon, a cavern, and a stretch of salt-flat wilderness all imply different relationships between distance, danger, movement, and visibility.
That is where Areas become more than a mapping tool.
“The other concept that Areas gives us is a measure of room size. Since every room in an Area is on the same grid, every room is understood to be the same size.”
Ursun was careful to make the distinction that Tales of Zalanthas is still a text world, not a tactical simulation.
“We are not building a shooter game where every space has exact 3D coordinates.”
Instead, the goal is to let the game understand scale in a useful, text-friendly way. A settlement interior might have small rooms. A canyon road might have larger rooms. A desert expanse might have enormous rooms.
Those differences can then affect systems such as travel time, stamina drain, movement delay, ranged weapon distance, wagon movement, flight, and visibility.
A narrow hallway and an open wasteland should not feel identical simply because both are made of rooms. Inside a fortress, it may make sense to shoot an arrow a few rooms down a corridor. In an outdoors space, heat, dust, terrain, and distance may make that far less practical or impossible.
The goal is not complexity or realism for its own sake, which was a trap we often fell into during ArmageddonMUD. The goal is a world that behaves in ways players can feel in an almost tactile sense, and understand the physics/laws that govern each space through helpfiles and playtesting/actual play. It can make exploring and traveling make more sense and have better stakes, simply by treating the rooms and the distances being crossed correctly.
Areas Within Areas
Areas can also contain other Areas.
At the highest level, Zalanthas itself is an Area: the plane of real existence. Within it, there may be the ruins of Allanak and Tuluk, Luir’s, the Canyons of Waste, the Eastrook and Shalindral mountain ranges, cavern systems, and stretches of desert.
But Areas are not divided simply because the landscape has a different name. They are divided when the scale of the map needs to change.
A city, for example, would be an area; a district within it, a bazaar within that. The Canyons of Waste would be an area, and within that, a ruin. And within that ruin, buildings and caves that are areas themselves, as they scale smaller and smaller (or larger and larger). You might have an area the size of a closet (because it is a closet) within an apartment, or a crate.
Because Tales of Zalanthas is being built in Python with Evennia, rooms and exits are not limited to the traditional north, south, east, and west commands. A room can have an exit called enter the wardrobe, duck beneath the vines, climb through the broken window, or crawl into the ash-choked crevice. That flexibility lets movement feel more descriptive and intentional, especially in places where a simple compass direction does not capture the action. Hidden exits/entrances FTW!
Why Move Away from Zones?
In original ArmageddonMUD and other DIKU-derived games, Zones did many jobs at once. They organized rooms, controlled permissions, grouped objects and NPCs, and often determined settings like weather or NPC reset behavior.
Zones could represent a region of the world, but they could also represent a specific builder’s work. Items and NPCs were tied to zones. Permissions were tied to zones. Environmental rules were sometimes tied to zones. This meant a player could cross from one technical container into another and experience an abrupt change that was both unrealistic and immersion breaking.
Ursun pointed to weather as one example.
In the old model, sandstorms and visibility could change sharply at a zone boundary. A character might approach a settlement or region and run into a sudden environmental discontinuity, sometimes with punishing (or deadly and unrealistic) consequences.
Another example I can think of is Zones that were for 'House Salarr' and were 100% full, so you had to write up a new item or room in an unrelated zone. Allanak had 3 or 4 zones, all full, and you had to write in a 'Vrun Driath' zone or something else that just quickly became uncategorized and unorganized. Chaos!
Areas are meant to be much cleaner and oriented purely towards the map, spatial reasoning, and gridding everything out. The world can still have regions, districts, spawning rules, and environmental behavior, but those things do not all have to be trapped inside the same old concept of a zone. We also won't tie up all of the things like objects/NPCs with Zones, those will be distinct and separately organized.
Spawners, Tags, and Room Selectors
Moving away from zones does not mean losing control over where things happen. In fact, it gives builders more precise tools.
Instead of saying “this creature belongs to this zone,” builders can define more specific conditions. A creature might appear only in the lower Red Desert, only in a particular district, only in alleys, only outdoors, or only after dark.
One tool supporting this is the Room Selector.
A Room Selector is a way of querying rooms by their properties. Builders can filter by things like name, sector, tags, flags, or other values. For example, a builder might search for rooms tagged as outdoors with “road” in the name. The system can then produce a selector string representing that query.
That selector can be reused elsewhere, such as in a mob spawner.
“Let’s say you want a mob to spawn in Luirs, in the alleys of the outer bailey, but only when it’s dark. You can configure the spawner for that.”
That opens the door for more precise ecological, social, and atmospheric placement of creatures, NPCs, and events. A dangerous animal can belong to a particular stretch of waste. A cutpurse can haunt a particular district. A night creature can appear only when the sun has gone down and the alleys have cooled into shadow. A wilderness creature might have a certain territory, marked by rooms rather than 'by zone'.
It also means that good tagging and good building practices become important. The more thoughtfully the world is described and categorized, the more intelligently the game can use it.
Building Without Requiring Coding Knowledge
A major goal of the system is that builders should not need to know how to code.
The tools are being designed to be straightforward, documented, and usable by creative builders. Foundational builders will help not only by creating areas of the world, but also by helping document the process for future contributors.
When asked how much coding knowledge a builder would need, Ursun’s answer was:
“None.”
The emphasis is on creative passion, judgment, and a strong sense of milieu and place. This mostly takes writing chops, understanding how areas flow one room into the next, and how memorable items and NPCs are when they are hand-crafted.
At the same time, the system is being built to reduce the kinds of mistakes that were easy to make in ArmageddonMUD. Builders should have access to the settings they need to build rooms, NPCs, and objects, without also having the ability to accidentally break the world.
Undo, Redo, and Safer Building
Very simple – We added an Undo and Redo functionality, so there's a clean list of actions that can be undone and redone, making a building session a bit more straightforward. Made a mistake? Undo it.
Mapping the World
Mapping has been one of the major inspirations for the Area system.
Modern MUD clients such as Mudlet have raised expectations for what a game can provide. A featured MUD in a modern client is expected to support mapping in a way that older ArmageddonMUD could not easily satisfy.
As Ursun put it, there was little chance the old map structure would ever pass that test cleanly.
For Tales of Zalanthas, mapping is being considered from the beginning rather than added after the fact. If the world is going to map cleanly, then the world needs to be built cleanly.
The current proof of concept includes an ASCII-based map command that is already useful for building. Orientation matters in a text world, and even a simple map can make a significant difference when reviewing or navigating an area.
There are also plans to expose some form of mapping to players. The intent is not to hand every character a perfect map of the entire world. There is a difference between preserving mystery and making navigation needlessly miserable.
“We do want there to be discovery elements in the game, but we also don’t want to make people’s lives miserable with the FOIC (Find Out In Character) byline.”
One possible model is that characters begin with knowledge of their starting settlement. As they explore beyond it, rooms are added to a personal map. That map may follow the player account from character to character, because the discovery of the world is often an out-of-character achievement as much as an in-character one. It might be a toggle, so a player can decide if they want to rediscover from PC to PC, or keep an overarching map that sticks to their account. This is all theoretical and something we are both figuring out and want to invite the community in on the discussion.
The Visual Web Map
Alongside in-game mapping, Ursun has also built a visual web-based map tool connected to the MUD server.
This tool behaves much like one would expect from a modern map interface: it is zoomable, scrollable, and displays rooms in relation to one another. Right now, its main purpose is staff and builder support. We are hoping to expand its utility and usefulness in the future as well.
Closing Thoughts
The Area system is one of those pieces of development work that may not always be obvious from the player side, but it will shape almost everything the player experiences. It affects how the world is built, how it is mapped, how movement feels, how wilderness differs from city streets, and how builders can create new spaces without fighting the old limits and archaic relic of Zones.
It also matters for access. One of our hopes for Tales of Zalanthas is that it can meet the expectations of modern MUD clients like Mudlet, including the possibility of being listed among its Featured MUDs, which was not possible on ArmageddonMUD. Original ArmageddonMUD, for all its strengths, was never built with that kind of mapping requirement in mind. It was unique, strange, and unforgettable, but its underlying map structure was never clean enough to satisfy a modern client-facing mapper.
By building Areas into the foundation now, we are giving Tales of Zalanthas a better chance to support those tools from the beginning. That means cleaner maps, better orientation, and more ways for new players to find and enter the world and not get confused as to where they are.
More than anything, Areas give Tales of Zalanthas a stronger skeleton. They let us build a world that is easier to maintain, harder to break, cleaner to map, and better able to support the kind of harsh, strange, and immersive Zalanthan experience we want to create. No more sudden sandstorms or odd behaviors / mapping between rooms!
A big thank you to Ursun for taking the time to talk through the system with me (Eurynomos), and especially for coding up Areas and the supporting map tools. This is the sort of behind-the-scenes work that makes the visible world possible, and we are excited to keep building on it.
-Eurynomos