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

[Caliban Tiresias Darklock]

-----Original Message-----
From: Thinus Barnard <thinus_barnard at bigfoot.com>
To: MUD-Dev <mud-dev at kanga.nu>
Date: Thursday, December 17, 1998 12:57 AM
Subject: [MUD-Dev] Graphic design, client questions


>Telnet cons:
>Limited to text.

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.)

>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.

>No graphic capabilities.

These can be layered on either in a protocol (as HTTP does) or by the client
(as many dedicated clients do).

>No mud server specific functionality.


Slap that into the protocol.


Further pros:

SIMPLE. Easy to write.
Lots of publicly available source, so you don't have to write it yourself
anyway.
Easier debugging: no dedicated binary protocols to reverse.
You can log on from just about any machine with TCP/IP. Good for sysadmins
and roving types.
Text-mode basis makes things easier for the blind. It's hard for the blind
to socialise.

Cons:
Text? Who the hell likes text? Graphics are the future.
Lots of wasted bandwidth on long commands and responses.

>Win 32 client pros:
>Any mud server specific functionality can be added to the client.

If your protocol is text-based, the user can do this himself with many
scriptable clients.

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

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

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

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

>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.


>Win 32 client Cons:
>Limited to Win 32 platform.

A published protocol spec can change that; people who want a client for the
Foo platform just need someone to write one. If the protocol is text-based,
such a client can be scripted almost trivially using your protocol
description.

>Client has to be developed and maintaned.
>The user will have to download the client before using the mud.

If you base your MUD off a telnet-based protocol, he doesn't HAVE to get the
client, and you can have a MUD before you have a client. Then you have a
beta team for the client before you even start working on it.

>If the client is updated the user will have to download the client
>again.


Patches and updates. People don't do enopugh of those. Take this into
account in your design; use DLLs for "core" functionality, and an EXE for
the user interface. When you change a given part, just replace the
appropriate file. Ideally, all files would be 50-100K (a resource DLL should
be used; it will be larger, but only very rarely need updating). Automate
the downloading of the latest files, so the user doesn't have to check
dates -- click an "Update" button, the client goes and checks the current
version of your DLLs and then hooks into the net to look for new ones on
your official site. If it finds new versions, it fires up a web browser so
the user can choose a mirror site to download from. Ideally, the user can
download all his new files in one batch with a single click.

Further cons of a dedicated Win32 client...
Users have to download a client when most of them already have a client they
prefer.
A server author writes an end-user application: usually a Bad Idea.
A MUD designed to work with one specific client: Very Bad Idea.

Published protocol specs can offset the latter two, and may actually offset
the first.

>The other possibility is to use a Java client. The client will not be
>limited to a specific platform then. I will probably go for this option.


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.

You can see where I'm leaning on this, right? ;)

| Caliban Tiresias Darklock            caliban at darklock.com
| Darklock Communications          http://www.darklock.com/
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=-