Lately, I’ve had a laser focus that’s consumed me in my latest project, Pinwheel: a fork of Ranvier, a MUD engine in JavaScript. This fork started as a question: can I add a web server to a MUD engine? The answer—which I found out pretty quickly—is yes. With that done, I turned my attention to the rest of the code. I started to rip things out and move them around. Even after weeks of tinkering with it, I’m genuinely fascinated by how this stranger’s software works. Reorganizing the blocks bit by bit, rewriting some parts entirely… all of it is rewarding. The silent reflection of teaching yourself another person’s code is oddly zen-inducing.
But before I get ahead of myself…
I want to take a moment to plug The MUD Coders Guild, a fun collection of like minds. We’re all interested in or working on MUDs, and there’s a lot of interesting discussions on our Slack. A lot of my reflections below are a result of my conversations with the group, whereby we discuss the interesting design questions we face while pursuing our hobbies. Stop by and say hi!
Okay! Now, back to what I was saying…
Rolling around in the code acquainted me with some interesting design choices. No matter what, there will always be seams between our vision of a project (a design) and the finished product (an implementation), but with careful attention to detail and smart brainstorming, you can save yourself from some major headaches (or at least some major refactors).
As I started to sketch a worldview for the MUD I was building, I asked myself a series of questions. These questions became my roadmaps for designing the codebase. And later when I started applying those ideas, I asked myself a second series of questions. These questions are now guiding my implementation.
DESIGN
In its purest form, design is poiesis. It is drawing ideas from the ether. It’s a Muse. But as daydreams and ideas solidify into beta tests and emergent gameplay, those ideas provoke questions about the text universe you’re building:
1. Who will play this game?
You, hopefully. You should always want to play what you make. But beyond yourself, what type of players do you imagine playing this game? Will you cater to casual or hardcore playstyles, or attempt to please both? There are issues with balance when you reward players for playing 24/7 and also when you reward everyone more or less equally, regardless of time devoted.
Games with a very narrow theme or intended gameplay might harbor a hardcore niche of players, but sometimes a vertical integration of a theme without the surrounding world structure is unrewarding. For example, an economic sim is, necessarily, concerned entirely with trading, earning money, collecting resources, and haggling with other players for dominance. But when this simulation takes place in a vaccuum, the gameplay can become dull in isolation. If everyone is a trader, then it’s less special special being a talented player. But if you’re in a city full of politicians, warriors, and priests, being dominant in “your corner” of the world’s gameplay comes with more social prestige and bragging rights.
2. What will keep players around?
Why will they keep playing past their initial login? You should assume the average first-time player will remain connected for less than a few seconds. It will be very rare when someone sticks around long enough to invest anything into their character. How will you entice them to do so? Trickle out rewards in the beginning, showcase what makes your game unique early. Don’t hide all of your best gameplay in the end-game stages.
Similarly, you have to be able to cater to guests in order to grow your playerbase. Reduce the time and commitment needed to get into the game from first landing on your website. If players are curious, they will want to explore before they commit. It’s very common for players to make “throwaways” (very generic characters for the sole purpose of deciding if they want to play) before actually investing. Give your players avenues to do this, because they’ll do it regardless of if it’s supported or ideal.
3. How can players influence the world?
Can a player make lasting changes on the world? How much agency does a character have? This question fuels the question before it, because the more ownership players can take of your world, the longer they’ll stick around.
Importantly, however, there must be checks and balances in how a player can change the world, in order to maintain a level of quality. Some MUSHes are very freeform and allow players to write or describe anything. But as a result, the game theme is varied and inconsistent. Because everyone is just a freeform entity of text, there’s no measuring stick of comparison between characters and as a result, the gameplay is entirely collaborative storytelling instead of mechanics.
Some MUDs strike a middle ground, like Haven, which allows players to create and describe locations, equipment, items, and their character. Players have full control over how they present themselves to the world through these vanity strings, but it doesn’t alter the underlying game mechanics of power and corruption (which sits on the unbiased fulcrum of hardcoded formulas, not prose). You can describe yourself as the hottest, strongest, coolest character on the map, but since the game has coded systems to determine all of those things, situations can be confusing when characters present themselves one way when the opposite is true in the code. This means that the game administrators have to trust players to align themselves with the reality of the code, which doesn’t really happen on its own. To have both the freeform creation and the enforced mechanics, you essentially need a fascist state to maintain the integrity of the theme.
4. What is the cultural mentality of your world?
Every popular game has a mindset or mantra that its players identify with. An example that immediately comes to mind is Armageddon which, for decades, has built a fervent fanbase around its post-apocalyptic low fantasy theme of “Murder, Corruption & Betrayal.” Players boast of their political coups, backstabbings, and downright grit. This mindset fuels the gameplay that they all love together in the game. Players who are too soft or nice are considered to be “unthematic.”
That’s an extreme example, but an us-versus-them mentality goes a long way in creating dedicated players.
5. How can players deviate from your theme?
In other words: what can they get away with? In a roleplaying game, administrators often control everything going into the world. It’s very common for games like this to have an application process, whereby a character is submitted for review to ensure it adheres to theme before a player can begin. This can be scare off new players, so some games take an alternate approach that lets you begin playing immediately, but your character must be fleshed out and reviewed by a certain point. In situations like this, the administrators will create essentially a fascist state to enforce the theme, and players will have little opportunities to deviate.
In Armageddon, administrators review all characters and gameplay is observed. Comments are even left on your player account and points (called karma) are doled out to players who stick to theme and promote realistic gameplay. But in Haven, there is no review process. Instead, players risk being ridiculed by others when they deviate from the hardcoded systems. The game has avenues by which jealous or annoyed players can seek retribution in-character, in an attempt to correct theme. This causes players to try and police each other, and cliques will likely form as a result.
In all of this, you should remember that players will communicate outside of your game, whether you give them channels to do so or not. As a result, there will be “metaplay” of your game that happens off your server, and there’s nothing you can do about that. Instead, you should provide ways to communicate across game boundies within the game. Players are going to talk to each other regardless of if it’s officially supported.
IMPLEMENTATION
If design is poiesis, then implementation is praxis. Implementation is taking those raw ideas and parsing them into the rules that dictate the code. It is here where we start to shove round pegs into square holes, and it is here where we begin to sacrifice those original ideas. But don’t lament—some of your best ideas will be reborn from these ashes.
1. Where is the fun?
There’s an important rule of prototyping: find the fun first and build from there. In all of your brainstorming, you need to determine what is actually fun to play. Sometimes a really complex or interesting system is compelling to plan out, codify, and parse as an algorithm… but then turns out to be lackluster to engage with. Keep moving. Find this fun as fast as possible, and don’t accept anything less. Your players won’t either.
This may mean deviating from what players expect, but you must also leave breadcrumbs in your new systems that players can naturally find based on their instincts or past experiences.
Don’t be afraid to hide secrets and not give everything away. But trust that your players will, in time, decipher every formula and figure out how to “win” your systems. Whether or not this is what you want depends on the vision of your game world.
2. How will you classify the ‘playing pieces’?
Your game will likely be made up of entities, NPCs, rooms, players, areas, items… and how you distinguish these objects (or don’t distinguish them) matters!
If player characters and NPCs and monsters are all subject to the same bodily rules of the world, then anything a player achieves could be achieved by an NPC, and vice versa. Providing ways for the game world to make new combinations and surprise even the creator is how we get emergent gameplay.
Similarly, it’s important to consider how space and locations are represented in your textual world. In many MUDs, “rooms” are used as units of measurement of space. Sometimes a room is massive (maybe an entire forest) and sometimes a room is just a tiny closet. Because rooms are inconsistent, how will you represent scale in the world? How are locations grouped together? It’s important to create a world with spatial sense, so players can orient themselves within the environment. If your game fails to properly address distance, space, and depth, then the mental illusion of telepresence is disrupted and the game world becomes clunky to navigate.
3. What will persist between boots?
At first glance, this question might seem out of place, but when implementing the vision of your world, you need to think about what “sticks” and what doesn’t. In some games, anything dropped on the ground is subject to being deleted during server refreshes or reboots. In this case, players are usually the persisting containers and will walk around with all of their earthly possessions. Sometimes, games like this will have special player housing that allows them to store items in an actual room in exchange for a fee (as a money sink).
Other games take a different approach and persist everything. Something dropped on the ground might stay there until another player or NPC picks it up, or until it decays via some innate behavior. If NPCs also persist from boot to boot, then that also introduces the question of how they’re spawned and removed from the game. Where do NPCs come from? If a mayor is put inside the mayor’s office and, across 6 months of server time, the same mayor entity stays in the office, then what about them will have changed? Will the mayor have the same abilities, items, and behaviors as when initially spawned, or will the game allow them to grow, learn, and explore like a player? If nothing has changed, then what was even the point of persisting that data? Use persistence as an opportunity for the game state to react to the players who inhabit it.
4. How will time pass?
A simple seeming question that dictates a lot: what is the passage of time? Is time important in your game, or only an abstract idea? How fast does time pass? What happens to a character when time passes and the player isn’t logged in?
What is important about the passage of time as it relates to your game mechanics? Maybe you just need a day/night cycle to simulate a town or a shopkeeper, but maybe you need a season cycle to support your farming mechanics. Find the scope of time you need to support your gameplay, and make it unobtrusive whenever it can be. Players shouldn’t be inconvenienced if their playtimes always line up with a game time that is “dead” in terms of what it can offer.
For example, Haven follows real time, so whatever time and day it is in the real world, it is in the game. But if a player can only ever login on weeknights or early mornings, then they’ll essentially never see a midday world. Don’t restrict your players’ opportunities based on when they can log in. But on the opposite end of the spectrum, don’t make time pass so quickly that it’s entirely worthless to consider. If 20 in-game days pass in a real-life day, you’re leaving little time for anything about that day to matter.
Personally, I think a good maximum is maybe 8 in-game days in one real-life day. That makes an in-game day passes every 3 hours. You can divide it into a real-life hour for morning, afternoon, and evening, and this spread of time means that logging in at consistent times will still expose you to the full breadth of time in the game.
Of course, you could eschew time altogether if it doesn’t offer anything compelling to your game. This is your universe, after all.
5. How will your players actually interact with the world?
Will players simply make an account and play as their account name? Do players create an account then create characters witihn that account, which represent them in the actual game world? What distinguishes out-of-world with in-world?
Being a MUD, you have it pretty easy in terms of providing an interface. Many longtime MUD players will stick with their favorite telnet client no matter how fancy your custom one may be, so give them reason to use it. Is it important that everyone uses your custom client?
What will players be able to do on your website? Can they log in, interact with the game world, chat with others, or otherwise “hang out” in the metaverse of your game?
6. How will players progress?
How is a 60-day character different from a 60-minute character? Will everyone progress at the same rate, whereby the amount of time invested directly correlates to how powerful a character is? Or will you reward crafty, cunning, or particularly skilled players over those who aren’t?
Providing pathways of rapid advancement can be helpful for encouraging fresh blood to join your game and mix it up, but be cautious of over-rewarding new players and spurning your pre-existing dedicated players. It’s similar to when a cell phone carrier will release an exclusive new deal to attract new clients, but won’t extend that same deal to their pre-existing customers. Don’t be like a cell phone carrier.
CONCLUSION
This list is by no means exhaustive, but I hope these questions are helpful to you if you’re brainstorming a digital world and you seek ways to implement it. Excelsior!