[MUD-Dev] Text MUDs; in need of an (r)evolution?

John Mauney montyculligan at gmail.com
Fri Nov 18 21:52:37 CET 2005


Sean wrote:

> Disagree. While I agree that you can do more, it's just evolution
> and a minor one at that. There's still a lot we can do with just
> text (look at BBS "doors" - is that what they were called? It's
> been way too long).

I would like to make sure you understand me. I have enjoyed (and
still do enjoy) BBS Doors such as Legend of the Red Dragon,
Operation Overkill II, Trade Wars, and Usurper. In fact, using text
or ANSI formatting in a text MUD is something I had thought would be
great the first time I ever played a MUD! My point here was not to
get away from text. How then, could it still be classified strictly
as a text MUD? I'll concede one thing now; Telnet is more powerful
than I had given it credit for. I had forgotten, but you and
Mr. Pointon reminded me of that. The important idea here is that
text MUDs have made little to no attempts to really advance the
appearance of the play expereince. As an example, I used a platform
for multiplayer networking games called "Byond". You may have heard
of it:

  http://www.byond.com

I used it to create a model text MUD interface that allowed
Windows-style text formatting. The result was beautiful. It was VERY
nice to be able, as a "player" (it was still hypothetical at that
point; simply an interface model) to be able to bold and italics my
words at will. It was also nice as a "builder" to be able to set a
nice light brown text background color with a forest green text
color on top of it, and a nice looking font to top it all off. It's
a wonder what nice looking font can do to inspire someone who is
reading fantasy prose. It was a much more comfortable and enjoyable
experience that the grey or green on black text I'm used to seeing
from most (and even some of the best!) MUDs out there. The reason I
call this one "evolution" is simply because it represents a change
in the presentation of text MUDs. Maybe it isn't revoltionary by
itself, but when I create ideas, they generally travel in packs. No
single one of my ideas can be revolutionary by itself, but the idea
is that if they can all be used to better text-MUDdom, then a
revolution in the genre would hopefully take place. To say 'this
idea is revolutionary' or 'this idea is not revolutionary' doesn't
really work. I think you have to allow the ideas to take place and
see if revolution happens or not. The results validate or invalidate
the origin ideas.

>>  - Text MUDs should no longer require any kind of previous
>>  knowledge with the genre.

> An admirable goal, for sure, but it's more of a design
> consideration than either evolution or revolution. I've played
> many different excellent newbie areas, and I was introduced to
> MUCK programming by a newbie helper, so that kind of stuff is
> already out there.

I did, as well. When I was younger, the scene of online computing
was a much different one. I didn't have other friends who were
engaged in the same activity, because it was considered too geeky,
boring or confusing at the time. Some of these kids were even ones I
table top gamed with! In fact, I even did manage to download a copy
of Usurper and, for about 3 weeks, got them to come over to my house
nearly every day just to play it. Usurper doesn't really have a
learning curve if you have someone telling you how to play it. Yet,
any attempt to get these guys to figure out a MUD would have been a
real frustration. I also was a kid who was taught DOS by a friend,
and figured out how to log into BBSes and, in the days of the
internet, to find and download drivers, etc to maintain my computer
without any help (you know, in those darker days). For me to sit
here and think that MUD tutorials have something going for them
simply because I was able to benefit from them would be selfish. I
would ask you to think back. Did those tutorials REALLY explain
everything? Or, did they just teach you the basics? I can remember
spending collective hours reading through help docs in MUDs to find
out exactly how I cast this spell or which of the two different
types of training this trainer provides, and don't you just remember
the credo all MUDs seem to have? READ THE HELP DOCS before asking
questions on the channels! I can't tell you how many times elite
players would refuse to answer a simple question on the pub
channels, but instead religiously point me to the help docs (and, of
course, never the specific doc I need!). If online help is so darn
good in these MUDs, then why do I find it so much easier to jump
into Morrowind? I don't seem to remember ever needing to look in the
manual for something I needed to know. Do not assume that I am
pointing to any of the MMORPGs out there as a model example,
either. I think most of them are lacking, as well. A good example of
a strong tutorial and online help system would have to be
Civilization III. There is something a MUD could benefit from. I
personally don't think Telnet is capable of handling embedded
hyper-links, but maybe I'm just wrong.

> I think you're barking up the wrong tree there. I've always been
> of the opinion that "features" are the crutch of a bad designer. A
> good designer can create a brilliant game with one button; a bad
> designer couldn't create a decent game with ten. Text is extremely
> powerful communication, or else my local Borders wouldn't have
> about 30,000 books there (some of them don't even have pictures!)

I agree, but do not see this as relevant. Again, I think you
misunderstood me. I'm talking about the capability to add features
with merit. I purposely left the discussion generalized for this
very reason; I'm not inclined to suggest that any specific features
would make serious changes to the text MUD genre. You are correct in
saying that a brilliant game can be made with fewer features, and
that an aweful game can be made with many; but that's not a very
insightful statement. I might as well say that a beautfiful song can
be written using one instrument and a terrible song can have
seventeen parts! That's not a good reason to write songs that only
feature one instrument. I'm not sure if you're afraid of features,
or you've just seen too many games go to hell because the designer
over prioritized them. I am in no way here to promote the
over-prioritization of features. By the way, I have played some very
good games that were chock full of features. In fact, since I've
already mentioned the Civilization series, I will use Civ IV as an
example of that kind of game. Operation Overkill II was a great BBS
Door game that had probably more unique features (and an impressive
ANSI UI) than most of the other Door games. It is still being played
today. LORD had very few features and was also a very good game. I
don't think either game is better purely because of the increase or
decrease in features.

Speaking of minimalist designs, I wouldn't say that I purposely
challenge myself to create game systems with them, but I will say
that when I am critiquing a system I do not enjoy, many times my
solution would be to minimalize. Your example of a combat system
without experience points (or even hit points!) would be an example
of something I might conceive. My opinion here differs from your,
but only slightly (I think). Instead of thinking that minimalist
designs are best, I would say that a system is at its best when it
can do the things you want with the minimal amount of design. In
other words, keep reducing if it's possible, but don't reduce so
much that you lose elements that actually enhance your game. I also
think minimalist game systems can work in tandem with more complex
ones. I look at Guild Wars for that. In the end, it depends on the
game. I believe that a game can be designed well and be deep and
complex at the same time. I also believe that a game can be designed
well, require fewer resources, and be instantly rewarding with fewer
fetures. My personal bent is to the more complex, because I enjoy
complex games that reflect a complex universe.

To respond to Sam:

> The point about telnet formatting is invalid, as there are some
> -very- fancy things that can be done with pure telnet, assuming
> your client is fully VT100 compatible (which, unfortunately, most
> MUD clients aren't). I would flag this as a problem in the client
> developer's court, rather than the MUD developer's.

I will concede a bit here. Sean reminded me of what Telnet was
capable of in the BBS days. However, there are some features that
could potentially be very useful to text MUDs which I understand
cannot be done inside a Telnet client. I will list a few which come
to mind now: hyper-links, ability to send windows-style text
formatting to client output, mp3 playback, full color graphics
presentation (2D or 3D).

Those are the handful that come to mind now. Hyper-links can achieve
a lot.  > From better onlin-help systems, to better customer
support, to web integration, or simply the ability for certain MUD
commands to open multiple windows to achieve certain tasks (maybe a
special 'letter writing' window that opens when you wish to write a
letter or post a note. Further, what if this special 'letter window'
was actually the graphic of a paper scroll with a feather pen for a
cursor?). Text formatting is fairly obvious. As I stated far above,
it could really help text MUDs to shine. Some people might balk at
the idea of MUDs that play music, but music can be turned off, and I
think many people would enjoy it. Imagine a band that plays ever
time you enter a tavern, or the sound of rain every time it begins
to rain outdoors.  Graphics presentation is a but more
subtle. Retaining the qualities that make a text MUD great is
actually easy to do while using graphics. Graphics can be used for
things like a compass, an inventory (graphics for the body, text for
the items), a celtic wondow border, a splash screen, etc. Text MUD
games even can remain text games without relying on the typical text
MUD combat systems. What about a, GASP!, turn based combat system
that can be played by clicking buttons! The text can still be there
in the form of combat prose, but you don't have to rely on inputting
commands. None of these things are necessary for text MUDs, but
then, graphics wasn't necessary for EverQuest, and they decided to
use them. I suspect things would be different today had they not.

> Your next point about the expertise needed to play text MUDs is a
> moot point, as different people expect different things from
> different games, and even the same person, six months on, would
> expect something different.

Maybe my motivation was unclear. The point of making text MUDs more
accessible is to invite people to play the game who otherwise don't
because they find them too boring. You might think people who find
text MUDs boring do so because they are made up of text, but this is
inaccurate. Many people find text MUDs boring because they get into
the game and then say, "Um, what do I do now?" The response of,
"Well, read the help file." or "Go 'N'orth to enter the MUD school"
falls upon deaf ears because they are looking at a screen full of
meaningless (to them) text, and have already decided this experience
is NOT for them. I believe a MUD can retain all its wonderfully
text-based qualities without shoving the player into something
confusing upon arrival. A good example of this is how easy it is to
get new players at least past the character creation sequences. As
long as their are prompts asking them questions, then they can
figure out an answer. Once the prompts stop, and they're left in the
middle of a huge city, they are already lost.  I am of the opinion
that there are people out there who have imaginations, but those
imaginations require more prodding and nurturing than maybe yours or
mine does. It's like the person who is first introduced to PnP role
playing. The first response is something a little like, "WTF?! A
game without pieces??" Then, if they actually stop to consider it,
they realize how much fun a game that is solely dependant on
imagination allows.

> I am intrigued by your final proposition - give some examples
> please? I consider the fact that you can log on anywhere there is
> a telnet terminal and not be massively disadvantaged (hey, who
> needs MXP and that stuff anyway?) to be one of the great
> advantages of MUDs, but, say, custom GUIs would put a stop to
> this, effectively rendering these MUDs EQ-in-text, rather than
> being closer to online interactive fiction.

Your example of "being able to log on anwhere" is not any
significant aspect of text MUDs that makes them closer to
interactive fiction. It is a significant feature of them, in
general. I know lots of players who have enjoyed this feature in the
past. You are correct in noting that it would be a casualty but, as
you said yourself, people expect different things from different
games (and different MUDs). I am one of the people who never makes
use of said feature. Here are a few examples, however: player-owned
property, player run villages and cities, true turn based combat,
gathering, crafting and commerce systems (tale in the desert style),
instanced areas, action combat, mini-games (cards, dice, fishing,
lock-picking, etc). None of these things are present in EverQuest,
not even the crafting system.  EverQuest instead has a horrible
excuse for a crafting system. Also, none of these things have to
take away from the Interactive Fiction appeal of MUDs.  You might
say that pressing buttons to move around is less appealing than
typing commands in a prompt, but who said you can't have both? It
could be that utilizing buttons is not meant to take over command
entry, but instead be an alternative to some of the more dreary
aspects of it, like compass direction movement or inventory screen
management. You can still build a MUD which relies on having to
type, "pull bottle" to get into that secret chamber behind the
wine-bottle shelf and also feature a graphical compass or a
graphical representation of the world map. Finally, I think your
statement about these kinds of things elevating text MUDs into the
realm of graphical MMORPGs is not well thought out. So far, there
has been not a single statement by me that any of the textual prose
and presentation should be done away with. All of these ideas are
meant to either accent and heighten the prose, make it easier to
concentrate on the prose aspects of play, or, in this final example,
do away with all text that doesn't fall into the category of
'prose'.

Consider this kind of MUD combat system: Instead of being based on a
timer, let us make it truly turn-based. To alleviate any fear of the
combat 'locking up', let us give each participant 10 seconds to make
their move.  Let's even be liberally minded and say that all player
input is achieved through buttons (a system that uses text would
still work). P = participant.  P1 presses the 'defend'
button. Everyone sees some a textual phrase that represents this. In
fact, the MUD builder could have 100 different 'defense prose
phrases' if he wanted to make things as interesting as possible. We
already see one advantage over typical MUD combat. Everyone can take
their time to read and enjoy this prose. It is unlike the typical
MUD combat (and Everquest, actually!) spam that nobody actually
enjoys because they're too busy hack and slashing. P2 presses the
'attack' button, or maybe the 'special move 1' button and you get to
read some prose that results in a combination of an attack action
and a defense action clashing. Now, you might think this would
become old after some time. However, MUDs are more dynamic than most
MMORPGs. Since the MUD relies on prose, a good MUD builder will
ideally design every creature in the game with unique combat prose
phrases. Every time you encounter a new creature, you'd be reading
new and interesting combat stories. Again, compared to typical MUDs,
combat is not a story at all. It's a feverish quest to type in all
your commands as fast as possible. Everquest boiled it down to
clicking buttons as fast as possible; it was no better or worse in
that regard. Now, lest you attribute this favorable result to my
example being a turn-based combat system, I will give you another
example. Imagine a combat system a bit more similar to MUD combat,
with a few differences: first, the timer is much slower;
consequentially, combat lasts fewer ticks. Second, players can use
the arrow keys each round to position their character in the
existing room. This positioning is represented somehow
graphically. Maybe it is a little grid with enemies and allies on
it, or maybe it is just a little box with their targeted opponent's
name and relative distance (things like grappling, close, far and
distant). Adding the ability to move your character with the arrow
keys makes the text MUD combat exponentially more fun. Here is why:
instead of going through a wrote combat sequence as you kill your
1,000th opponent for the day, you will have to dynamically pay
attention and adapt during every combat. If your character is a
rogue, his strategy may be to wait until he thinks his enemy is
going to use his 'kick' attack to backpedal (avoiding the attack)
and then throw a dagger from range. If your character is the
fighter, he might opt to not use the kick immediately once it
recycles, but instead wait for the rogue to back up first, and then
close in quickly and kick, hopefully ruining the rogue's chance to
throw that dagger. The timer for this combat would be slow enough to
allow players not only the chance to make these decisions, but also
the chance to read all the combat prose they are creating as they
perform these attacks. Part of the reason I keep pushing for
readable combat prose is because I've played a BBS Door game called
Operation Overkill that used it very, very effectively to create
interesting fights. And, this was all using a particularly
featureless console-style combat system! Adding a bit more complex
combat system than simply "attack", "use item" and "flee" and you
could have something really great. Again, the point of using
graphics rather than text, is not really to add features, but to
help the presentation to be more natural and easy to understand and
use. A lot of this could actually be done in Telnet, but would be no
less arcane or awkward than text MUDs presently are.

John M.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list