maybe you can write it in VRML... or just in C++.... VRML isnt really that
hard to learn but it lags sometimes....
also, if you are going to do it as a client make it like a maximum of 120
users until it is totally released so you dont have to make something that
keeps making more and more sockets, etc.
if you are going to make a graphical M** please contact me because i'd
really love to help!
-Draklixa
-----Original Message-----
From: Patrick Dughi <dughi@IMAXX.NET>
To: CIRCLE@post.queensu.ca <CIRCLE@post.queensu.ca>
Date: Monday, July 31, 2000 11:44 AM
Subject: Re: [CIRCLE] Viability of a Graphical CircleMUD
>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 |
> +------------------------------------------------------------+
+------------------------------------------------------------+
| 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