At 12:14 PM 11/10/97 -0500, you wrote:
>> presented solution. In the case of a MUD, this won't work, because we
>> can't expect people to download up-to-date data and binaries for the
>> MUD everytime we change a feature or an area. So, it's something like
>> comparing apples and oranges.
>
>Why not? What if it made the mud a lot more fun to play? There are enough
>non-OS specific GUI libraries out there that a simple, portable interface
>could be written fairly quickly.
>
>Couldn't you (if you were a complete nutcase) have the client send data on
>a second port, so that you'd still get the text data, but if you had the
>client be able to get extra info as well? I dunno what good this would do
>you in a hack and slash mud, (REALLY nice 3d hp/mana/mv bar graphs :) ),
>but suppose you were playing that Mechwarrior MUD I keep seeing bandied
>about. You'd need to keep track of enough different information at once
>that a REALLY large prompt or conatantly typing 'sco' would be your only
>hope.
I've thought about this possibility before. Though I haven't acted on it, what
I've thought of is the power of Java. A Java client could be written that
would
fetch "extra data information" from the mud (if the user has this preference
turned on) and could use that extra information to either play a sound or show
a graphic from data that could either be stored locally or on a web server
somewhere.
(If I ever write this client, it will initially only fetch www data, but
the second
pass would probably allow you to save a local copy.)
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST