And unfortunaltely also a completly different skill set than a coder has. You can have both sure, but it is pretty rare. And a GUI needs a lots of human testing to check for usability. (and are hell to test code wise as well, cause it is one thing to have a usable gui, it is another to test it everytime you change something in your code that affect it). GUI are hell (kind of why most open source project GUI sucks as well…no funding to properly develop those).

And do not accuse me of loving the command line…I hate it unless it is for mudding :)

You're not trying to rival the leading MMORPGs, you're just trying to offer something better than a terminal window. Even something very simple can make your mud more user-friendly and visually appealing than nothing at all, and if you know what you're doing it can be done in under an hour.

A GUI is just like any other feature: It should have a reason for existence before it is implemented, either with current value or future potential in the direction you are expanding.

MUDs may have been originally designed to parse text input, but that doesn't mean that we shouldn't use a GUI to assist in areas where the game content/design has altered from the original intentions.

Examples:

• Health Bars - The game I develop was not originally designed for a huge player base, specifically in consideration of the interface. Having expanded upon the original codebase for over a decade (numerous programmers/owners/etc.), the end-game combat has become much more "spammy" than the early-game combat. There are also more players at the end-game stages, more strategy is required and more instant feedback is required to be effective (without scripts). To assist clerics, I added a prompt option that displays all group members by name and their health percentage, along with color coding to show who is a current tank (colored names) and what levels of health players are at (green is healthy, red is near death, and shades in between). Even with non-verbose features to minimize the spam of combat, it can still be difficult to quickly analyze the prompt and see trends in the fight that need to be addressed (such as the mage tanking and only able to survive 1 more round of melee). The features added so far (prompt option w/ color coding) went a long way towards visual assistance, although it is only a step in the right direction for most of the players. A GUI that has an avatar for each group member, and constant HP/MP/etc. can show much more information, without being scrolled off the screen. This could be far superior in many instances (especially as group sizes for both allies and enemies increase).


• Proper Targeting - Taking the above GUI feature a bit further, we can use the same health bars and avatars for enemies. We can now easily differentiate between which of the 10 "an orc" is losing health, and we can strategize in real-time without using "consider 7.orc;consider 8.orc;…". Further, we can click on the one(s) we wish to target our next action at. This could also be used on allies for healing, etc. This may break the "2 hands on keyboard" play style, and is therefore more suitable to graphical MMOs, however it is still a better alternative to some of the other design decisions available (spamming commands to check all nearby enemies and allies health, or checking which "an orc" walked out so as not to change who you are casting at, etc.).

This isn't to say that all GUI features are useful to every MUD, nor are they appealing to every user. It does provide a huge advantage under certain preconditions (such as a requirement of not changing all the prior areas in the game which have 10 "an orc" that can end up in the same room). Additionally, a GUI isn't meant to be the 'best' or 'only' set of features that can solve the issues. It's simply an option that each developer can consider, not one that should always be implemented on a whim.