[MUD-Dev] Re: Graphic design, client questions

[J C Lawrence]

On Thu, 17 Dec 1998 09:38:14 -0800 
Caliban Tiresias Darklock<caliban at darklock.com> wrote:

> Not really. HTTP is run over a telnet connection. (Really, it
> is. So is FTP.  So is IRC. Damn near every major protocol on the
> 'net is founded on telnet.  Telnet *is* the internet.)

Slight correction:

  Most 'net protocols, like SMTP, FTP, HTTP, IRC, etc are formed of
simple 7-bit ASCII command and response pairs.  While some protocols 
involve binary data, such FTP or HTTP file transfers, they are not
actually part of the _control_ side of the protocol.

What does this mean?  It means you can telnet to the appropriate
port for that protocol/server and drive the protocol manually.

>> Standard telnet sends every character typed to the server. This
>> increases server overhead, especially if you do a lot of
>> backspaces.

> Most clients operate in line mode, or even multiple line
> mode. Using "raw telnet" is considered a rough equivalent to the
> tortures of hell by most MUD players.

This is the equivalent to the difference between:

  xterm -display host:0

and:

  xterm -e rlogin host

>> The client can force the user to only enter valid commands.

> MUD and client versions would have to match... exactly. BAD idea.

It gives a whole new meaning to DLL versioning problems.

>> The commands sent between client and server will be much shorter.

> This is definitely a concern, especially if your bandwidth is
> limited.

The difference needn't be large.  Its also a bogus concern if a
single command or reponse will fit in a reasonably sized (ie not
likely to fragment) single TCP packet.  As long as commands and
responses don't fragment packets, there really is very very little
difference between long and short commands.

>> The client can support graphics.

> Client can still support graphics with telnet-based protocol. How
> you get them to the client is up to you.

cf HTTP.

> Java is unrealistic for end users. It's a lot harder to set up
> than an O/S specific app, and it doesn't look or act like they
> want apps to look and act.

There are two additional ways to view this:

  1) Is the MUD client an actual APP, or is it a customised game
interface?

  2) Java is proliferating.  Web browsers are already the most
common and most heavily used applications on most 'net connected
desktops.

#1 is the really interesting one.  Look at other game interfaces --
even the ones that are Windows or whatever specific.  Does it really 
look and behave like a normal XXXX OS application, or does it have a 
heavily customised interface wrapped in a very thin shell of OS
normalacy?

#2 merely suggests that users will be presented with and likely
comfortable with Java-centric designs thu the simple fact that they
see a lot of them in their web browsing.  The fact that MUDs are
inherently 'net related can build on this coincidence by presenting
the game as an extension of the general 'net/web experience.

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...