Re: ...Extra Client Dilemna...

From: Peter Ajamian (
Date: 03/23/01

Tony Robbins wrote:
> But music is nice.  But to do that, I've got a streaming mp3 system

If bandwidth is a concern you can always go with midi also.  Consider
that bandwidth may be a concern on the client side.

> So far, my best solution is to provide a maintained
> connection to my server, and then tell the client to
> get more information.

Well, there are various different solutions to this:

1.  You can provide a package that can be downloaded or you can send a CD
(for a reasonable fee, of course) with all the multimedia stuff.  This is
a nice option for some who do not have a reliable connection.  If you
have multimedia images that the player is not supposed to have access to
until they reach a ceartain level or complete a ceartain puzzle, etc,
then you can encrypt the files with different passwords which are
provided by the server at the time when they're supposed to become

2.  You can provide the multimedia on a server for a fetch on demand
system.  This can be done via http, ftp, some custom protocol, whatever.
Advantages of http are the ease of viewing the multimedia (all you need
to do is pass the URL to a browser).  Advantages of FTP are speed,
efficiency, and reliability.  A good streaming protocol can give even
better speed and reliability than FTP but is not standardized anywhere
near as much and you may have a problem with firewalls (HTTP and FTP are
far less likely to be firewalled).

3.  You can stream the multimedia right off the server in-line.  This is
probably one of the worst ideas, but it is an option so it does bear
mentioning.  This would require either switching the client into a binary
mode to recieve binary data straight off the server or using a binary to
text conversion protocol such as uuencode.

4.  Any combination of the above.

> But now we're at _3_ clients to play a MUD.

Three?  you lost me there.

> Obviously, writing my own client is an option.

I don't know of any other option.  You can modify an existing client such
as any one of the many tintin ports available.

> But now we face a couple fairly painful facts: telnet works on
> all platforms and most people have a preferred client already.

True, and I would recommend that unless you're writing something that is
fully graphical that you allow continued support for telnet.  I'll even
go a step further and say that telnet is a good protocol to base this on
because of its flexibility (am I the only person who thinks that simply
extending the telnet protocol would be more than enough for a good MUD
protocol and would allow for easy acceptance and use of older clients
that don't support the MUD protocol yet?).

>  zMUD allows writing modules, but zMUD is not
> free, and I don't think the 'vast majority' of players
> have tossed out the crash to use it.

zMUD is not the only client out there that is extendable.  There are many
free open-source clients available that you can modify to suit your needs
and not have to worry about licensing fees.  I tend to think of zMUD as a
decent all around stand-alone client, but I wouldn't use it to base a
custom client on.

> In the end, I'm probably going to have to write my own
> client, and most likely it will be in Java.


> The inherent slowness of Java will turn most people off to
> it, I fear.  But everybody will have access to it.

If you base your client off of one that is fairly easily ported across
platforms then you can start by writing it for the most popular platform
and then port it to others as time permits.  You can simply show links to
web pages which disply the content for those who do not have the client.

> Do extra clients bother players?  (For Windows,) I'm
> envisioning a mini-browser (approximately 150x150
> pixels of viewing area) that you can set to 'Always on
> Top', then set it up in a corner of your screen so that
> it doesn't interfere with your "regular" playing,

You can also "dock" it to the side or top of the screen.  Make the whole
thing one client, though.  You can have multiple windows, but I doubt
that users will want to download bits and pieces of different clients or
have to individually launch multiple programs to see all the multimedia
in your game.

> 1. Do people actually buy zMUD?

Yes, I bought it, if I were looking for a client now I might not buy
zMUD, but since I already paid the money a while ago and it's a one-time
fee, I figure I may as well use it.

> Is it worth developing for a specific _client_?

No simply because there are enough free clients out there that you can
develop just as well.

> 2. What kind of client things could be added (music,
> graphics, etc) without being considered annoyances?

Music, graphics, sound bits (not music but just effect sounds), pics,
maps, etc.  Make it so that each feature is individually customizable and
can be configured on or off so players need not be annoyed by any feature
they don't like.

> 3. How would you address the fact that telnet is a
> widely supported, cross-platform protocol, without
> writing clients for each platform?

I'm not sure I really understand the question.  Telnet is a protocol that
is intended to allow programs written on various different platforms to
communicate universally.  It is not intended to make a single program
work on different platforms.

> 4. I remember discussion of an actual MUD protocol (not
> MSP, MXP, etc).  Does the community need an open-source
> MUD client available across platforms, etc?  Will this
> happen?

Tintin (originally a Unix client) is (to the best of my knowledge) open
source and has been ported to various different platforms.

> Oh, and I'm definitely not
> advocating turning the MUD away from text-based, so
> these are just additions, that one can live without

That's key.  Make sure the playability of the MUD does not rely on the
multimedia extensions.

Regards, Peter

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/04/01 PST