Striking a balance: simulation vs. storytelling in text-based roleplaying games

ko-fi Written by Brandon Cross
A player in a virtual environment and the text: Striking a balance: simulation vs. storytelling.
A player in a virtual environment and the text: Striking a balance: simulation vs. storytelling.

Guest author Brandon Cross gives advice for MUD developers on how to use storytelling, instead of simulation, to create a more immersive game with less effort.

Table of Contents


    It’s after midnight. In fact, it’s well after midnight, and you know you should have been in bed several hours ago. Your mind is swimming with ideas though, and you can’t seem to stem the tide.

    You need an outlet, and, as it so happens, you’ve got one.

    Your MUD is coming along quite nicely. You’ve got a starting area built, you’ve even got some of its systems coded. The thing is, you’re tempted by greater things.

    You set out to create a roleplaying MUD where people will want to develop characters and tell their stories; however, you know you can deliver some pretty in-depth systems to your players. Your head swims, almost to the point of bursting, but you have an outlet, so you begin to code.

    As time passes, the systems you’re developing begin to take shape. You initially lament the time it’s taken to get this far, but tell yourself that it’s OK, because people will enjoy the level of detail you’re putting into the game.

    You crawl into bed, your creative energy spent. As sleep overtakes you, a single thought burbles up from your subconscious, “Will this all be worth it?”

    Are detailed systems more engaging?

    In essence, the pitfall here is thinking that your game has to have the most detailed systems to engage players. There is a time and place for in-depth simulation, and knowing where to apply that focus is key. 

    For example, if you’re creating a MUSH, you may not need to develop an extensive emoting system, even though MUSHes are heavily based on emoting.

    Players will likely use a simple command such as ‘emit’ to pose. Or, in the case of engines such as AresMUSH that have a web portal, they’ll have the option to type their pose into the appropriate field on the scene page. And that’s all they will need.

    On the other hand, if you’re developing a more MUD-like world rich with coded items, equipment, quests, and NPCs, then you will likely want a more comprehensive emoting system.

    Such a system might allow players to do a number of additional things such as:

    • change where their character’s name appears in an emote
    • include speech as part of an emote
    • provide partial keyword matching for:
      • characters in the same room (including NPCs)
      • objects in the same room
      • objects in the emoter’s inventory

    In a roleplaying-focused MUD, this system would likely get used extensively by players and would be well worth the developer’s time to code.

    This is an obvious example, but we can apply the same logic to more complex scenarios, as well.

    To demonstrate, let’s look at two more examples. In the first example, we will lay out how a transport vehicle might work, and cover why this type of object might not require extensive code support to operate in a way that feels immersive to players. 

    After that, we’ll take a look at a healer’s call to action, and talk about why this scenario might benefit from a greater level of code support.

    Example 1: Transport vehicle

    A futuristic cityscape with unique worlds in the background.

    Let’s say your MUD’s setting takes place in the future. Thus, there is advanced technology available. The players occupy a unique world, and while space flight is possible in the setting, it isn’t the focus.

    Still, you want a way to break up areas. Your world has three continents, and you want a way for players to travel between them. Sure, you could employ traditional aircraft, but what about something snazzy and futuristic, like a sub-orbital pod?

    This pod departs on a set schedule, which players can view at a station near the launch area. If a player wishes to board this pod, they arrive at the appointed time and place and board the craft. Optionally, they might also be required to buy a ticket before they can embark.

    We have a very rough sketch of what this pod will look like and how it will function.

    Now let’s consider the features the pod itself might have to simulate a real sub-orbital vehicle. We could code in a way to track its speed, altitude, coordinates over the air map or game world, distance traveled, and distance to destination. From these, even more information could be derived, such as an ETA.

    We should think about condensing this list, but before we do that, let’s establish what we actually want to convey to players:

    • A sense of acceleration and deceleration
    • A sense that the pod is still moving after it’s accelerated to maximum velocity
    • The estimated time to arrival at the next destination
    • When it is safe to disembark

    Now that we have a list of things we would like the player to know about, let’s talk about how we could condense that earlier list a bit.

    First, the coordinates of the pod, as well as its actual speed, do not need to be tracked. The entire flight from takeoff to landing could happen on a simple timer. All we then have to do is display messages to players conveying that the pod is speeding up or slowing down, without actually having to manage speed as a separate variable.

    The same can be said for altitude and distance. The flavor in all this is the messages the player sees. Your task, as the developer, is to make them feel what’s going on.

    You’re in the business of evoking emotional responses in your players, and in a MU*, quality writing is the cornerstone to making that happen.

    Putting yourself in players’ shoes

    Imagine getting into this pod yourself. You board, find a seat, and wait. After some time, the craft launches. At every step, you are kept in the loop as to what’s going on. You feel the craft pick up speed as well as climb, cruise steadily, reach the apex of its arc, begin descending, and land. Perhaps there’s even a bit of turbulence along the way.

    All of this can be achieved without coding extra variables to simulate real sub-orbital flight. Quality writing is all that’s required.

    The pod itself never needs to travel through different coordinates; it can simply be moved to an off-grid room for the duration of the flight, with messages displayed at takeoff and landing to alert players in those locations.

    For extra flavor, let’s say you type ‘look out’ to see what conditions are like through the window. Or ‘look’ to see the craft’s ETA displayed in the “room.”

    Again, providing an ETA doesn’t require that you track coordinates, speed, and distance. It only requires that you know that the flight takes ‘X’ number of minutes and that the flight started at a specific time. For looking outside, you could easily reference existing weather for the area the pod is entering.

    The key here is to provide immersive messages that will make players feel like they’re really traveling to another continent.

    Example 2: Healer run

    Photo of a picturesque stream with mountains in the background.

    In our previous example, we looked at how scaling back on an object’s code need not render it uninteresting. Now, let’s switch things up a bit and take a look at a situation in which additional code support makes sense.

    Imagine you’re playing a MUD with a lot of wilderness, and you just found out that someone’s gone missing in the woods. You’re equipped to help, so you grab your medical bag and head out toward their last known location.

    On the way, you see suspicious tracks in the dirt. It’s hard for you, with your limited experience, to tell who or what made them, so you use your radio to call for a hunter or scout to come check things out.

    When you find the injured person, you see that they’re covered in blood and unconscious. You don’t have time to waste, so you do your best to stop the bleeding. However, it’s clear that you will need to get them back to town quickly.

    You start dragging them back, but it’s exhausting. You eat the only scrap of food in your pack, a trail ration, but are still hungry. The westering sun presents another concern, but you keep trudging on.

    When you get back to town, you rush your patient into surgery, where you’re able to disinfect and clean the wounds. You had to give them medication to encourage their blood to clot, and then, upon further analysis, you discovered a neurotoxin in their blood. The blade that was used must have been coated in it. It’s a race against the clock, but you’re able to find the antidote and inject it just in the nick of time…

    Giving players the tools to do more

    In this scenario, so many things could have happened differently based on your character’s skills or attributes. Maybe you didn’t have the strength to drag the patient at all, or the stamina required to drag them so far. Maybe your medical skill wasn’t up to par, and you botched injecting the medication on the first try.

    In any case, the patient lived, and now you (and they) both have a story to tell. The skills, objects, and systems you used along the way included:

    • Scouting or tracking
    • Communications device
    • Wilderness survival
    • First aid
    • Diagnostic medicine
    • Surgical skill
    • Injection, antidote

    Systems like these, which go beyond a generic “heal” command, can encourage and enhance RP by giving players more to do without having to rely on GM guidance.

    The player who took on this mission would likely feel a sense of accomplishment, not only because they saved their patient, but because they made good use of their chosen skills.

    Note how they also generated RP for other players (hunters) who could fill in the gaps in their expertise (tracking).

    When to employ simulation-style mechanics

    Thus far, we’ve covered two different examples. In the first example, we considered a system for transporting characters between different continents. In the second example, we looked at a common situation for a healer-type character and the various skills that might be involved.

    But why is one of these scenarios deserving of more effort?

    The point here is not to avoid complexity at all costs, it’s to recognize where to code in-depth systems to provide a more immersive and engaging experience, and when it can be faked.

    So when coding new systems, ask yourself whether spending the time and putting in the effort will be valuable to players. If the answer is yes, then you might want to invest in that system. If not, then scaling back might be the solution.

    Because players aren’t viewing the state of your MUD’s active memory, they won’t know that your sub-orbital pod isn’t tracking speed, distance, and coordinates; however, they will definitely know if the experience of riding in it doesn’t feel realistic or engaging.

    This is, of course, your MUD, and you can opt to code everything in as much detail as your time and skill level permits. But if you sort out the systems worth developing further, versus the ones that can be kept simple, you will be able to do more in less time.

    Simple, in this context, need not mean bad. Simple can still be immersive. The flavor text your builders write for objects, rooms, and NPCs is what makes a virtual world feel alive.


    To wrap up, the aim of this article was to show how and when to apply deeper levels of coding that will impact your players’ roleplay experience. We explored two examples and discussed how we could do less work to implement one of them, and why the other might deserve more effort.

    The truth is, the more complex a system is, the more time it will take to write. It will then need to be tested and debugged, which is an iterative process that is even more time-consuming and can potentially impact the playerbase.

    The trick is to determine what level of complexity is sufficient to achieve immersion. Thinking of ways to simplify code will cut down on development time and prevent future frustration, both for you and your players.

    About the author

    Brandon Cross has been a MUDder since 2013. He’s since taken up the staffer role, both as a builder and a coder. In his journey of trying to build and enhance virtual worlds, he’s learned several lessons along the way, and he hopes to impart some of them so that future MUD developers might avoid some of the traps that can eat time and cause stress and frustration.

    You can find more of Brandon’s perspectives featured in articles on Mudlet’s accessibility updates and soundpacks in MUDs.