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

[Lachek Butalek]

graphical MMO features to make them more appealing to the masses",
and the answer from me is a resounding NO. To clarify, I am of this
opinion because it runs contrary to the nature of MUDs.

The reason why MUDs are communicating via telnet (or ANSI-enhanced
telnet), why they're relatively hard to get started with for a
non-technical user or MUD newbie, and why documentation is (on
average) relatively poor, is because they are written by technical
users for technical users. The reason for this is historical - MUDs
originally ran on multiuser mainframes, usually running Unix, and
were usually written or modified by computer science
students. Rather than developing a separate protocol, telnet was
used because it was already there and it got the job done - people
could connect from other mainframes or even from home PCs without
having to recompile a custom client with a custom protocol
library. Most MUDs had a very limited number of users, often a
community closely knit in Real Life, and they knew the system inside
out - or could easily get a hold of the person who did. MUDs were
more experimental playgrounds than games - think Second Life moreso
than EQ.  Of course, that doesn't mean that this is how it has
always been, or even that this is the ideal - I merely provide the
above as background to *why* MUDs are the way they are, and to show
why that nature contributed to the rich ecosystem of MUDs
(especially compared with graphical MMOs).

The way I interpret your suggestions, it appears that making the
changes would cause MUDs to lose their inherent values and benefits,
which I don't believe is a good thing at all.

#1: Telnet

  Everyone has a hate-on for telnet, myself included, but it does
  really serve its purpose of ubiquitous access very well. I can
  connect to a MUD using built-in tools in every major operating
  system, while remotely logged into a Unix machine, or from most
  handheld devices with simple, downloadable software. No other
  protocol or virtual machine (I'm thinking of Java) is as flexible
  and easy to use, except possibly HTML - and HTML is not nearly as
  interactive.  Ubiquitous access is a Big Deal for MUDs, because
  with the telnet interface they've managed to do what graphical
  MMOs has so far been largely unable to - provide access to the
  game anytime, anywhere, from any device, even mobile. Most major
  MMO companies are considering or planning WAP interfaces in one
  way or another, but have yet to solve the problem. MUDs have had
  equivalent or better functionality for as long as mobile devices
  have existed, by sheer accident.  Telnet also allows you to play
  the game from just about anywhere at a moment's notice - Internet
  cafes, public terminals, HTML/telnet gateways, work - which has no
  doubt attributed to the playerbase.  What would happen if you
  implemented a new, improved MUD protocol? It's been done, many
  times, but usually as an optional modification or superset of the
  Telnet protocol to still allow for access from standard telnet
  clients.  Compression algorithms, meta-data, positioning and
  formatting data, and even graphical and audio data has been
  implemented in traditional MUDs while still retaining
  compatibility with Telnet.  So my take is - don't break telnet
  compatibility, but feel free to extend it to your heart's
  content. If some collaborative group could come out with a
  standard extended feature set for MUDs and have it incorporated
  into current MUD clients, that would be great.

#2: Ease of learning

  The assertion is that it must be as easy to get into a MUD as it
  is to get into any off-the-shelf game. First off, virtual worlds
  tend to have a higher learning curve than Quake by its very
  nature, so the comparison is unfair.  If you compare a MUD's
  learning curve to something like EQ or UO, I think most would
  prefer the MUD's. WoW or City of Heroes is a different matter, but
  these games are designed for mass appeal (and little else, as
  ranted on elsewhere). While it may be fun to romp through Liberty
  City beating up bad guys in your snazzy cape, it's not very deep
  or involving - something most MUDs aspire to be, and HAVE to be in
  order to compete with the graphical games.

  Many MUDs have gone to great lengths to allow newbies to get
  started easily, and most have succeeded much better than most
  graphical MMOs. Customized Java-based telnet clients right on the
  website and in-game tutorials are fairly common among
  higher-profile MUDs.

  Overall, while I think every opportunity should be taken to
  improve newbie experiences in MUDs and other MMOs, it seems to me
  to be a game design issue moreso than a communication protocol
  issue, and fairly easily overcome.

#3. Poor documentation

  This plays into the "newbie experience" issue above. There is no
  doubt that MUDs need to have excellent documentation in order to
  provide all the information people need to play the game,
  especially if they're unfamiliar with the particular MUD engine or
  mudlib. There is also no doubt that many MUDs currently do
  not. However, I have found a large number of MUDs and other M***s
  that have superb documentation, often to the point of surpassing
  commercial graphical MMOs. I believe that one must consider the
  fact that MUDs with poor documentation may be of the original
  sandbox type, with a closely knit community who play around with
  code and play each others' creations, who do not care much for
  outsiders anyway.

  On the other hand, many (especially older) MUDs have over the
  years built up a mudlib without any sort of rhyme or reason. A
  perfect example of this is actually UO, where the quest system and
  UI differs depending on your class and which expansion packs you
  have. The "easy" point-and-click system becomes very frustrating
  when a Necromancer plays almost completely different from a
  Blacksmith - even the UI bugs differs. In MUDs this phenomenon is
  often caused by different people building different areas with
  different themes or sets of available commands. This is
  frustrating, especially to a newbie, but is the result of poor
  design rather than something inherent in the genre. It can easily
  be solved by having a ruthless "building inspector" on staff.

  Overall, the issue of documentation is a design problem and one
  that has demonstratively been handled extremely well by some MUDs
  in the past.

#4: Graphical UIs

  My response to this is almost identical to the concern with
  telnet. A graphical UI, by definition, means you have to install a
  client on your computer, unless your UI is web-based. If you have
  to install a client, you lose a large chunk of the population who
  were relying on ubiquitous access.  You also enlarge your
  development staff by perhaps one person per platform you're
  intending to support - or lock certain OSs or devices out of
  accessing your game. No, Java is not "write once, run anywhere" -
  as a wise but frustrated software engineer once told me, Java is
  "write once, then debug it on every single platform until it runs
  properly". This is especially the case when dealing with graphical
  UIs, since the performance will suffer tremendously if you're not
  using native UI bindings, which you cannot easily do on "all
  platforms".

  Using HTML, or one of its supersets, as the UI for a MUD is a
  great idea, as long as you stick to web standards and lowest
  common denominators. You can assume that a Windows user can
  upgrade from Netscape 4.7 to IE 6.0 or Firefox, but you cannot
  assume that a Mac user can switch to IE - and even less so for
  mobile devices. AJAX and fancy DHTML may work great on all common
  desktop OSs, but perhaps not so well when connecting from a Palm
  or mobile phone.

  You also have to take into consideration that pure HTML is
  considerably less interactive than a communication protocol like
  telnet, so you would probably want to wrap telnet in with your
  HTML UI anyway - in this case, it is trivial to provide direct
  telnet access to your MUD as well, and you have killed two birds
  with one stone.

While I just complained in VERBOSE mode, I actually do agree that
MUDs should try new things. The great thing about MUDs is that you
*can* try new things relatively quickly and without spending a large
research or development budget - the issue is getting the
Comp.Sci. students to realize that the whole goblin killing business
is no longer the coolest thing since caffeinated soft drinks. And
yes, I'm a part time Comp.Sci. student, so I can say that. :)

Just my 4c (because it's twice as long as 2c would be).

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