On Sun, 30 Jul 2000, StormeRider wrote:
> At 11:35 AM 7/30/00 -0500, I wrote:
> > The issue I get frustrated over is that people assume that telnet
> >and a graphics pump/server idea coupled using _text_ tags is actually a
> >_good_ idea.
> >
> > Graphics and telnet just don't mix :)
>
> I'd like to hear more on this thread. I've seen Daniel's objections to MXP,
> but personally I still think that it (or something like it) has a lot going
> for it.
>
> The viability of most of us being able to take our MUDs and convert them
> to something like AC or EQ is pretty much nil. However, I don't see how
> we could stand to lose by implementing some basic sound and graphic
> functionality. Icons for spells in a spellbook, images for the different
> objects,
> hyperlink-like clickability all seem like viable ways in which text-based
> MUDs can progress. Ultimately, the HTML-like scenario does _not_ seem
> like a bad way of doing things, IMHO. If someone can explain why they
> believe it is, I'd be very interested in hearing it.
>
Okay. First, we'll ignore the fact that MXP is defined by Zugg,
and is championed by him (sort of like how microsoft works).
Embedded text (human-readable) control options are a _bad_ idea.
The way MXP is described it shouldn't be too difficult for another player
to easily control someone else. All I have to do is send a few lines of
MXP code to break someone's setup - and I can probably put it in a tell,
or gossip message. Ever been on a mud where an immortal was nice enough
to gecho "You are hungry," and every scripted user eats and drinks like
clockwork?
Then, we look at the concept of html. Html is a server-oriented
protocol. It's great because the server-owner (ie you) only has to make
one change, and all the clients (your players) automatically use the new
system. The problem is that everything relies on the server. Each time
you access the menu/etc you have to download it from a server somewhere.
Imagine getting into a fight and having to wait for the graphic
icons to load over your already-lagged modem connection. Let's not assume
you're streaming the info from a mud server, but from an http page
somewhere. Let's say dns goes out for a minute, or your ISP decides
you're getting too much traffic on that page and for a while you can't
connect.
Blah!
I know html-like text is a very attractive solution, in part
because it is now so easy to generate, and because zmud already promises
to support it. However, it sucks hind tit for muds and other multi-user
situations.
The fastest, and simplest solution is simply to add a second
socket connection. This has already been done on the afforementioned RoA
mud (src has been uploaded, btw). Their custom client has (from what I'm
told), seperate mapping and identified item databases, and probably a few
more things you can't just throw into a client without knowing the server
internals. The source for the client has not been released however.
> That said, I think that nothing should really be streamed from the server.
> Regular updates and client downloads would be a must, to update the
> graphics and sounds on the client computer. But that said, being able to
> prompt the client to display or play those doesn't seem like a bad idea
> in my opinion. Perhaps this should instead be done over a separate
> socket channel. That might have its own benefits, but the concept of being
> able to specify customizeable "HTML"-like frames would give us a lot of
> control that can only be done with VT100 escape sequences, which aren't
> the friendliest to code.
>
If you're going over a seperate connection why bother with the
kludginess of html codes? Make your own protocol. You know bitvectors
from the code? Think of a control code like that... say the first 16 bits
determine execute permissions, type (upload/download), other special
circumstances, and the rest of it maybe contains a text string for a
resource reference or the sort. You don't have to go through complicated
string mechanics to decode it, instead, you can probably act directly on
it; fast, easy, and if it's done right, easily extendable.
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT