A MUD for Graphic-kids

In designing a MUD to compete with most MMOGs, one would first have to consider that text is unnecessary. I won't make a non-text MUD to prove it, but I know it is true. The reason being that our brain converts text into symbols. Our brain doesn't break apart known words into letters, it takes the whole word into the brain and finds a matching image or emotion to place with it. 'Cat' isn't read C-A-T - our brain immediately turns the letter grouping into an image. It works as well as if we put a picture of a cat on the paper instead.

The good part about text is that we can express abstract concepts, such as 'brown-furred animal.' How would you go about trying to tell someone about a brown-furred animal if all you could use were images?You could use a bear... then someone might think you meant 'bear' instead. You could create an animal that doesn't exist, draw it, and give it brown fur. There are even more issues of that which I won't get into.

But MUDs don't use images. Besides text, they use ASCII art and maps, simple coloring, player interaction, and rate of text to stimulate player responses. The first are easy to interpret, but I may need to go over the last two.

Rate of Text - By definition (as I have coined the term for this blog, I'll be defining it also) rate of text is the grouping by which a MUD server chooses to send to a client, or a client chooses to send to a MUD. A high rate of text implies that the server or client is constantly sending messages regardless of message length. On RP MUDs, where players may wish to describe detailed actions (as the purpose is often prose and beauty of textual execution), the outgoing rate of text would be low. For players in the same room as you, incoming rate of text would also be low. It is difficult to judge how rate of text will affect a player's decisions, but I can predict that a high rate in both directions would be stressful; that a high outgoing rate but a low incoming rate would feel unresponsive; and a high incoming rate with a low outgoing rate may be "just right."

Player Interaction - Another aspect which is difficult to judge due to the fact that not all players are of the same quality. Logging on a MUD late at night you're more likely to meet the 'mellow' crowd, who's idle chitter-chatter may put some relaxing vibes into your gameplay. On the other hand, logging on right after school meets you up with all of the 'I want it all and I want it all RIGHT NOW!' children (though to a lesser degree since those kids gravitate towards graphical environments). Having those players zooming in and out of your area, snagging your quest mobs, rifling through your mob bodies, then zooming out of there before you can even say hello will definitely put an edge in your gameplay. Manipulating player interaction is not something I intend to cover in this discussion.

You may observe that my predictions for both of these concepts is rather close to how you might say they'de affect a graphical MMOG. Although there certainly isn't any scientific data recorded, my observations combined with many others show that player activities are very similar between MUDs and MMOGs, likely given the similarities between the environments themselves.

Using Color as Significance

My first suggestion to make a MUD for graphic kids is to use color in an obvious and unified way, similar to how WoW icons are used. Icons with weapons are attacks. Icons with shields typically require a shield equipped. Icons of a certain coloring reflect a certain school. (See: Warlock, Mage.) Color could easily be used the same way, even amongst different classes. Your offensive attacks might be light red (along with the damage you deal, since attacks and damage are associated), your incoming attacks might be dark red. For a mage who doesn't typically use physical attacks, their spells would be color coded the same way. Defensive magic and defensive physical tactic abilities would be light blue, and possibly defense breakers and curses/afflictions would take the magenta hues. The idea is there.

Once you've associated certain colors with certain abilities (red = offensive, cyan = protective, white = healing) you can color-code mob names according to what the mob can do. An enemy cleric who can heal and cast defensive magic gets a name of blue and dark grey letters, the colors of enemy healing and defense. Then you would be able to exclude some of the descriptive text from appraising or looking at a mob, or from it's stance description. No more "A shifty-eyed, rat-nosed man flashes a dagger between his fingers, trying to keep people from noticing." Now it's just "A shifty-eyed, rat-nosed man." I don't know what dark green means, but it must mean something about daggers or sneaking, I guess, because the symbolic/subliminal messaging says he's dangerous, and then whatever green means. Meanwhile, a friendly cleric mob who'll heal you would have a white name, and a mage mob who'll buff you would have a cyan name.

Give More Useful Information To The Player

Rate of text should be adjusted to a low volume, high speed transfer. The following four individual messages could be condensed:

MOB1 turns his attack to you!

MOB1 draws his sword back to swing!

MOB1 slashes at your arm!

MOB1 misses his attack against you.

to:

Incoming attack from MOB1!

2...

1...

MOB1 misses you: [0]

A simple countdown only detracts from flavor (the imagery) but in this case, the flavor was already in the way of function (filtering useless material from his attention instead of devising a plan to deal with the mob), which means players were getting a lesser game play experience on behalf of the developers wanting the world to look pretty. Rose bushes are also pretty, but are kept trimmed to the garden, and never allowed to grow onto the walkway. These 'thorny' messages should be treated the same way. (There may be an issue where attacks are incoming from two mobs simultaneously - I say this is a wide-arcing flaw with DIKU-style combat, and can be addressed by a queueing system, or any other number of small changes or large-scale makeovers.)

Expect Less From the Player

Text outgoing from a client, to the server, should also be truncated as much as possible. Whenever able, a single keystroke (then 'enter') should suffice. The keys 1, 2, 3 and 4 come to mind. A simple system where you could assign them as server-side macros would work well. This way, even bad typists with quick minds can keep up with happy-hacking fingers. So pre-combat, you assign basic sword attack to 1, basic defend to 2, magical attack to 3, and 'flee combat' to 4... and you're all set. Clearly, more will be needed, though with 26 letters, 10 numbers, and an assortment of other keys on the board, I doubt you'll run out of quick-combat keys to use anytime soon.

Edit 8/25: I found a mud that uses this combat system, as well as the dialogue system from my next post.

I Wouldn't Read It, So Don't Waste Time Typing It!

The biggest problem I see would be room descriptions. It's almost necessary to have a description, and typically colors are used here to describe a texture/'feel' of the area. If we already have colors associated with spells, someone might interpret a dark-red colored room as very bad (which could be useful, say, for a 'detect trap' skill which turns room names dark red if they're harmful and require disarming).

To solve it, I simply ask for a purpose. That is, what is the point of a room description? To point out interesting and noteworthy things. The caveat comes when you can't point out everything; some exits and objects are hidden and meant to be discovered. Though, since most room builds I know get lazy, typically a lengthy room description means they're trying to hide something, so you should look closer. The solution for this is quite simple: make finding hidden objects a character skill, not a player duty. A low level 'find hidden exits' skill with add a few lines of description that might now show up to the average joe, simply pointing out that something is amiss or such. A high level 'find hidden exits' will flat out show the exit in the direction list.

Another way of cutting bloat from rooms would be to not go into more depth than you might in a book. It's always tempting to describe an open field as something exciting to behold (which the Immortals want, in order to make each room feel unique, like there's never a dead spot) but I think it's important that plain rooms remain plain. A field of nine rooms (3x3) doesn't need 9 unique descriptions. The middle might be unique and short because it's simply a field, and the rooms along one edge might all the same, describing the change in terrain from mountain to field, and on the other side field to forest. Three, max of five descriptions for your nine rooms right there. A few extra lines in one for the 'find hidden' users to sneak into a rabbit hole, and you're done with that nonsense.

Concentrate Similarities

Alternatively (or maybe concurrently) reduce the number of available rooms and repeatable mobs. A 9-room field with a rabbit in each room could be reduced to maybe a 3-room field with three rabbits in each. Or just one or two rabbits in each, and increase their respawn rate so that you can go through them as fast as you could when there were more. The point is, one room does not need to represent one square  measurement of land. One room on a MUD could represent everything visible from a standing point. Such as having one room for a long hallway, and then another room for a perpendicular hallway, or after a turn in the hall.

There are definitely more topics here to discuss, but this is enough to think on at once, so I'll let it be.


Part 2 is available.