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

Caliban Tiresias Darklock caliban at darklock.com
Fri Dec 18 11:31:49 CET 1998


-----Original Message-----
From: Thinus Barnard <thinus_barnard at bigfoot.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Friday, December 18, 1998 1:06 AM
Subject: [MUD-Dev] Re: Graphic design, client questions


>Caliban Tiresias Darklock wrote:
>
>> 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.
>
>As for text mode I see a few problems.

I can see a few solutions! :)

>1. I can send the text description of the room and append the string needed
for
>the graphics protocol. This seems like a waste if the player has got the
>graphics. Instead of sending 1 line of text for the graphics protocol I now
have
>to send 5 lines of description plus the 1 line for the graphics.


Allow the user to turn off the text descriptions. Basically, the user can
use graphics, text, or graphics/text. Only a real wiz would use neither --
but that MIGHT actually be useful. If the client cached room descriptions,
then it could automagically turn descriptions off and on depending on
whether it had the room in the cache already. (This would be buggy in some
cases and need some sort of cache control; the HTTP 1.1 specs would help as
a roadmap.)

>As for a fixed command set:
>Caliban Tiresias Darklock wrote:
>
>> >The client can force the user to only enter valid commands.
>>
>> MUD and client versions would have to match... exactly. BAD idea.
>
>Not true. The server can tell the client what commands are available.

How exactly are you going to force the user to enter proper arguments to
those commands? If you add new features, the parsing by the client has to
change. You would need to send the rough equivalent of a full-featured FSM
to the client.

This is also dangerous. If you have this feature, someone out there is going
to assume it always works, and it almost certainly won't. Really insidious
security bugs could pop up through this.

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






More information about the mud-dev-archive mailing list