/def -i -aCwhite -t" enters "
/def -i -aCwhite -t" leaves "
/def -i -aCwhite -t" has arrived from "
/def -i -aCwhite -t" left the game\.$"
/def -i -aCwhite -t" enters "
/def -i -aCwhite -t" leaves "
/def -i -aCwhite -t" has arrived from "
/def -i -aCwhite -t" left the game\.$"
You are missing the more fundamental point being made here, which is that MUDs as they are conceived today are not fundamentally like other games. They are usually single developer, hobby-driven, and they bend over backwards to support the dumbest possible clients. Ebooks have more advanced functionality than most muds today. It's just, you're arguing across paradigms and so your bound to be unable to comprehend each others points.
The fundamental point, is that you think of your game as something more fundamentally "game" like and less fundamentally "mud" like, than writing a custom client becomes a no-brainer. "MUD" as a genre seems to have a certain manifesto of things, however, which often involves a taken-for-granted belief that the important part of a mud is the size, game features, etc. even while many "games" have taught us that crappy stories and crappy elements can be absolutely overridden when a game is beautiful, or just damn fun to play.
What that means for this discussion is simply that MUD developers put their time toward one and not the other, but it would not be inconceivable for them to consider that, in fact, they are mis-allocating their efforts.
Also, read this about incentives in developing for one or many clients, protocols, standards, etc: http://www.joelonsoftware.com/items/2008...