[MUD-Dev] Fw: DESIGN: XML?

[Jon A. Lambert]

I thought I'd forward this along too...
Most of it's old territory here but if I get it into the Mud-dev archives
I can get more experience points for it. ;-)

-----Original Message-----
>From: Jon A. Lambert <jlsysinc at nospam.ix.netcom.com>
>Newsgroups: rec.games.mud.admin,alt.mud.programming
>Date: Friday, March 31, 2000 3:09 AM
>Subject: Re: DESIGN: XML?
>

>David MacFarlane wrote in message <8br4sp$39p$1 at newsmaster.pathcom.com>...
>>On Tue, 28 Mar 2000 01:00:58 -0500, Jon A. Lambert
>><jlsysinc at nospam.ix.netcom.com> wrote:
>>
>>>David MacFarlane wrote in message <8b8t0a$fbe$1 at newsmaster.pathcom.com>...
>>>
>>>By catering to the lowest common denominator of user interface, your
>>>choices as implementor are limited by the users.  Controlling the client
>>>gives the mud implementor complete and total control over presentation.
>>
>>It also gives them complete and total control over interaction and the
>>interface to the MUD, and it _will_ be in a way that some people don't like
>>(and hopefully, others do).
>
>Well there is certainly quite a bit of prior art and experience to
>point to (Zmud, Gmud, tk-MOO, Telnet, Mushclient, etc.).
>Obviously a well-written client is not going to ignore proven popular
>features and will be flexible enough to support an intelligent level
>of user customization.  Some customization support will no longer
>be necessary since the server target is _known_.
>
>>There's also the manner of bugs and such that
>>your client will have and the client of said users choice might not.
>
>Given that user's client of choice simply won't understand the mud's
>output anyway it's a moot issue.  Of course, I have to make a case
>for that.  More below.
>
>>>Portability is no longer that big of a concern.  Java, Delphi, and a number
>>>of other GUI frameworks are available across multiple platforms.
>>
>>Java is slow, and also requires a VM. Delphi, AFAIK, is only available on
>>a very small number of platforms.
>
>*sigh* No Java is not slow.  It is more than capable for this application.
>Delphi now runs on Linux, Solaris and Win/NT.  The key to client portability is
>in using existing frameworks (or failing that writing your own).  Even if I was
>writing a generic client today, I'd be using a one of these frameworks (for example
>Andrew Wilson's tkMOO-light or maybe V).
>There are at least a dozen GUI frameworks and even more network
>frameworks to pick from.  The client application code is pretty much just
>glue.  If there are platform dependencies with using a given framework,
>I would maintain that it's a poor framework and wouldn't use it.
>
>> Native executables (most clients made by
>>other people) can be a lot faster but less portable. The portability however
>>is irrelevant since any platform will have a different telnet client. With only
>>the slightest amount of effort it shouldn't be too hard to get along with
>>each of them, since they're all designed to the same standards and most of
>>said standards are designed to not interfere with other clients that don't
>>support them.
>
>I'm not quite sure where you going with the native executable issue.
>Native code is much easier to distribute than source.  In fact, I don't
>believe users are at all interested in compiling the client.  I would
>certainly distribute native executables, unless I was using a frameworks
>or languages that didn't allow it.
>
>>
>>>Loads of interesting possibilities open up once you control the client.
>>>
>>
>>Most of which involve eye/earcandy and not the actual content of the game. (If
>>you can name some that don't, go ahead.)
>
>This is _all_ about content and context.  In that regard, the poster who
>suggested XML is right.  I happen to just disagree with the choice of XML
>as a network protocol.   It is after all quite wordy.  One school of thought is
>to implement new standards of client/server information exchange like
>Pueblo's HTML subset, CML, MSP, MCP, etc. and have client authors
>integrate these new protocols and their detection into new releases of generic
>clients, while at the same time supporting an unalderated telnet text stream.
>And then there's the custom client approach.  Obviously it excludes those who
>insist upon the presence of an unalderated telnet text stream interface.  I have
>absolutely no interest in those users.  Nor do I have any interest in users using
>antiquated hardware (386s, 486s, dumb terminals) or oddball operating
>systems (DOS, OS/2, VMS).  They just aren't worth my time or effort.
>
>Here are a couple of advantages of implementing custom client/server
>communication protocols.
>
>1) Client-side caching of information to reduce server bandwidth. This
>    might include help files, room descriptions, graphics, sounds, etc.
>2) Client-side command checking, pre-parsing, spell checking, language
>    translation.
>3) Peer client to client communications when appropriate to reduce
>    server bandwidth.  (i.e. Yahoo games, MS game network, Quake)
>4) Multiple port sessions to serve up supplemental information in
>    the background.  This may include any number of things like
>    graphics, sound, client updates, a distributed server network.
>5) Automatic connection rerouting.
>6) Client side production of mapping information.
>7) Client side builder and programming interfaces.  I'm a big believer in
>   free user building and programming.  YMMV.
>8) Clients that understand and display dwarven, elven, greek, alchemy
>   symbols, mathematical symbols concurrently with one's chosen native
>   character set.
>9) Client that understand formatting - font selection, pitch, centering, indenting,
>   left and right justification, etc.
>10) Clients that have spamming governors, allow limited instancing (multiplaying),
>   automatic registering and login to a peer network (i.e. ICQ).
>11) Clients that can understand and manipulate mud objects like an inventory,
>   an equipment list, etc.  Obviously within security tolerances.
>12) Client-side message/notes/bulletin board/mail editting and processing.
>13) Avatars.  3d mapping.  Point and drool object manipulation.  yada yada
>14) All users are equal.  At least they all start on the same client playing
>     field.  If you don't allow triggers don't put them in the client.  Obviously
>     hacking the client, the protocol or shell automation are still options
>     for your creative and determined user.
>15) On the flip-side if you like client robots and automation (I do),
>     implement a form of customized scripting.  One that understands
>    context and available server-side functions.  This is analogous to
>    client-side player mobprogs (MPG).
>
>>
>>>I'm certain Zugg is a nice guy, but what the hell does he know about
>>>presenting my mud?  ;-)
>>>
>>Well, considering zMUD is one of the most popular mud clients for Windows
>>and it also somehow manages to survive being shareware in a community of
>>mainly free MUDs, he must be doing something right.
>>All zMUD does is present what you, as creator of your MUD, tell it to.
>
>This isn't about the quality of zMud as a client.  I think it's a fine client.
>I can't tell it to do anything of _value_ about the presentation. (see above).
>It knows absolutely nothing about context and the only formatting it
>understands are linefeeds and a few ansi color codes.  Don't get me wrong.
>It does its job well, it's just not the job _I_ want to do.
>
>> The
>>only thing you lose control of is how the user interacts, not what they see.
>
>I lose control of what the user sees too.
>
>>Zugg may not know how to present your MUD, which is why you write all the
>>rooms/descriptions/so on, but likewise what do you know about how I want
>>to access your MUD?
>
>I don't care about you _specifically_, I do care about Mister or Miss Mostuser.
>Neither Asherons Call, Everquest, Ultima Online or Furcadia care about
>you _specifically_.
>
>I want YOU to view my presentation the way I intend it to be seen.
>It'll stand or fall on it's own.
>
>>>> They'd need to install your software which might not be
>>>>a possibility if they were using an obscure platform that you havn't ported
>>>>it to, or if they were somewhere that's restrictive about their computers
>>>>(say, work or school).
>>>
>>>So these people just can't or won't play.  So what?
>>
>>So just that, they can't or won't. I don't know about you, but I like being
>>around a variety of people from different backgrounds and experiences. If
>>the only people who can play your mud are the (bleh) Windowsers, you've
>>narrowed down your potential userbase and where those users come from.
>
>Diversity and multi-culturalism based on platform.  That's a new one.  :-P
>Anyways the vast overwhelming majority of mud players are Windows users.
>While Linux users might form the majority of the posters and readers of this
>admin newsgroup, they are a distinct minority of the users who play muds.
>That said I'm interested in having my client run on both Windows and Linux.
>
>>>Write the client for the platform _most_  of your users will be using.
>>>If there's a big enough demand for another platform, port it, or
>>>get someone else do it.
>>>
>>
>>Assuming that most of your players will be from Windows, porting to almost
>>any other platform isn't so easy. The differences are big enough that you'd
>>probably be better off completely rewriting your client on the new platform,
>>which now doubles your work maintaining it. Now that you've got to maintain
>>a client on each platform that you plan on supporting you've shifted the
>>workload of fixing bugs in the client from someone else to you, along with
>>any bugs in the server.
>
>I think I already addressed this above with the use of frameworks which
>are in fairly wide usage and which have their own maintenance staff.
>I already use Delphi network and GUI components that exist on three
>platforms.
>
>>>>Not only that but it would be very inefficient.
>>>
>>>Inefficiency is writing and debugging hundreds of lines of code to handle
>>>the quirks and bugs of every possible user client.
>>
>>"Every possible user client" follows the same standards. Once
>>you've written the code that sends output conforming to the standards once
>>any client that can't handle it is a bug in the client's implementation of
>>said standard and therefore somebody else's problem.
>>
>
>The problem is that 90% of that standard is completely irrelevant to muds.
>Negotiation is also moot to my server.  It doesn't dither around and negotiate
>with a client.  It knows what the client will do.  ;-)
>
>>>Inefficiency is maintaining parallel levels of client capability.  Does
>>>the client do VT100, color, sound, MSP, compression, graphics, Pueblo,
>>>blah.. blah..
>>>
>>
>>Some of those protocols you can detect, others it's easy to revert to a
>>sensible default and allow the user to toggle it if you got it wrong.
>>
>>Once you've written any of these once in the server it's done. When you're
>>maintaining both the server and forcing them to use your client you've now
>>got to maintain the protocol in a) the server b) the win client and c) any
>>other platform you've ported to.
>>
>
>Mud protocols can be made much simpler.  Note there are conflicts with
>layering all those protocols because they are all designed to accomplished
>different things.  Adding a new protocol layer only serves to increase
>bandwidth.  And bandwidth is the single most important performance
>concern for a server.  I think implementing a single specific mud protocol is
>far simpler.
>
>--
>--*     Jon A. Lambert - TychoMUD Email: jlsysinc at nospam.ix.netcom.com     *--
>--*     Mud Server Developer's Page <http://jlsysinc.home.netcom.com>      *--
>--* "No Free man shall ever be debarred the use of arms." Thomas Jefferson *--
>
>
>




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