Why We Work on MUDs
It doesn’t really matter if you will be the only player of your little MUD. The point is working on the design, making it fair and sensible.
The whole model is not sensible, which is the real challenge. You’re dealing with a world that persists independently of a player’s perception of it (a tree falling in a MUD forest definitely makes a sound no matter what). Most games are orchestrated experiences from the perspective of the player. MUDs are literally a world.
The most senseless part of the MUD experience is actually quitting. How do you quit life? Normally, when you log off you just disappear, “leave the game” is the terminology generally used. That sounds fine until you think about a random quit, normally in the heat of battle. Internet links are not perfect, and if you’re playing on a smart phone, what happens if you have to take a call? It’s not quite fair to get your butt kicked by the persistent world when you have no way to interact or control/monitor the outcome.
It might be tempting to interrupt only as much game state as does not impact other players significantly. So, it might sound good to temporarily vaporize the current opponent and have them come back fighting you when you log back on. But what if you are fighting as part of a group? And you definitely cannot “disappear” an opponent if you are fighting a real person. How is that fair to them? If you are fighting a computer-controlled character, lesser problems also arise. If you decide to “disappear” anything not human-controlled, you run into questions like: if the dragon is a really unique monster, and he disappears with a logged off player, should another dragon show up to take his place so other characters do not see an interrupted or illogical experience (especially if the logged off player never returns?)? When the logged off player comes back, will there be two dragons? When you start talking about rare things, this could seriously break the game’s continuity, even if the players were not being malicious/manipulative about logging off.
When you start the engineering problem solving around these questions, you normally come up with coarse plans like the ones above. You say, monsters vaporize when people vaporize. Then you realize the difficulties and propose configuration and game mechanics to prevent things from getting out of control: have a little routine to monitor vaporized monsters and clear out the queue after an hour or so. That’s a performance issue. Then you need to be able to mark a monster’s configuration as being non-vaporizable. That’s an encumbrance to the designer, yet another little technical barb to remember.
Then you might try to build a whole game mechanic around it. Have the monster chase you into some temporary location conditioned on a certain set of rules, then fight them there if you log back in. Rethink the entire idea of game presence. That’s probably a rewrite of some significant logic, so you stop here and wonder how it can ever get done. Then a reasonable solution arises:
What if computer-controlled entities just hold grudges? If you disappear, the monster puts you on a hit-list. If the monster ever sees you again, you get attacked. That way, if it’s a quiet day in the game, anybody who logs back in quickly will probably just pick up where they left off. If it’s a nothing enemy, it probably walked away and got killed by somebody else. Fine. If it’s a one-of-a-kind enemy, it’s likely to be there when you get back as well.
It’s finding an “out” like this that makes the whole intellectual design process especially interesting.