Ideas for the betterment of muds...
anonymous
Hello, i'm a beginning mud programmer, i know vbasic and basic, but im
learning C.
anyway, i think muds are missing something critical, SOUND.
i am trying to introduce this in to a rom2.4 set-up.
my ideas have it as an add-on to zmud or such that the client would
play, at a prompt;
1.) a midi file for different areas
this could be downloaded at the time off entry to a new area. small
5K-15K midi files
woundnt impead the play a great deal, or
downloaded proir and saved it on the client side disk.
2.) wav's played on certain triggers.
this may already be possible in zMud, ihave to look into it.
Features like this could make for some very popular muds and and clients
at support it.
Any and all help is appreciated. I can be contacted at;
Gr3...@hotmail.com
thanx, gr3mlin
M.A.Clubine
I think you're going about it the wrong way. Check out
http://eternal.mud.circlemud.org/~maclubin/java/eternal.html . We were
trying to add it with a java program, but had trouble starting a new
thread in java. Anyway, that's how we went about doing it.
Monroe - Eternal
.. .. . . . ......
F9 $ F $ $ :P F Michael A. Clubine
F $ J" F $ $ .$ F macl...@syr.edu
F 'k 4F F $ $"?k F"""""
F 'r P F $ $ *L F http://borogove.syr.edu/
F 9$ F $ $ '$. k.....
Mike Levine
anonymous wrote:
>
> Hello, i'm a beginning mud programmer, i know vbasic and basic, but im
> learning C.
> anyway, i think muds are missing something critical, SOUND.
-snip
Me thinks you'll introduce a lot more lag with sound. In addition,
the "typical" client used to connect to your mud would need to
support sound.
Mike Levine
mru...@ic.net
NB. Why do you submit anonymously?
Michael A. Krause
anonymous <gr3...@hotmail.com> wrote in article
<334829...@hotmail.com>...
>
> Hello, i'm a beginning mud programmer, i know vbasic and basic, but im
> learning C.
> anyway, i think muds are missing something critical, SOUND.
> i am trying to introduce this in to a rom2.4 set-up.
> my ideas have it as an add-on to zmud or such that the client would
> play, at a prompt;
> 1.) a midi file for different areas
> this could be downloaded at the time off entry to a new area. small
> 5K-15K midi files
> woundnt impead the play a great deal, or
> downloaded proir and saved it on the client side disk.
> 2.) wav's played on certain triggers.
> this may already be possible in zMud, ihave to look into it.
>
> Features like this could make for some very popular muds and and clients
> at support it.
> Any and all help is appreciated. I can be contacted at;
> Gr3...@hotmail.com
> thanx, gr3mlin
Medievia has come to an agreement with Zugg of Zmud and Ari of Mudmaster to
develop a mud sound protocol. This protocol will be called MSP. Anyone who IS
a mud imp can join in, email mkr...@intersphere.com to get on the MSP mail
list.
Medievia has most of the MSP coded in and the standard basics worked out with
the major mud clients. This MSP really has nothing to do with Medievia except
we started the idea and will be managing the MSP email list at the start. The
MSP push has been greatly needed for quite some time. The players at Medievia
want sound, the players of all muds want sounds and midi files triggered from
the mud side by way of a standard. This standard we hope will be used by all
muds and you will not be able to make a decent mud client without fully
supporting MSP (Mud Sound Protocol). The standard is very simple and easy for
all muds to code in. It allows for great flexibility in its implementation mud
side while assuring the clients stick to the rules.
In Charge of MSP right now is Zugg of Zmud, Ari of Mudmaster and
Vryce/Ozymandias of Medievia. Bonez of Necromium has also recently joined in.
We will be ready for other mud imps to join in very soon. This MSP project has
been going on for a few months now. Any comments on MSP can be sent to
mkr...@intersphere.com.
We will post the basics of MSP to this list once Zmud and Mudmaster are ready.
This MSP will only become a standard if most muds see it, like it and use it.
In the mean time Zmud, Mudmaster, Medievia, Necromium and others have all
agreed that MSP will be THE Mud Sound Protocol and we believe all muds will
embrace it quickly.
If you are a mud owner or head programmer and you want to have a say in MSP
please get on the MSP email list. Email mkr...@intersphere.com with your real
name, phone number and the mud you represent.
Ron Cole
Though sound seems like a really good idea, I have yet to see it be
more than the "little bells and whistles" that attract new players..
and that older players turn off. For instance, the Gemstone III
front-end for GEnie played music and had sound clips that played
during certain events (combat, I believe). Though these were very
interesting at first, most players ended up turning them off and
opting for their own CD's. Though sound-effects add a great deal
of depth when used with purely graphical FE's, it seems superfluous
on TEXT based games.
-= Rindar
Gr3mLiN
Ok, this is GREAT! i was unaware of the capabilites of zMud to play
audio.
I hope this post will address all 4 replies.
1.) im using commicator 4 beta2 and i dont know why it posts as
"anonymous"
i can be contacted at Gr3...@hotmail.com
2.) if the files are on the client side disk there shouldnt be too much
lag, just a quick message saying,"updating sound files" for a moment.
then its done(this is midi only)
3.) If properly integrated, sound could add a great deal of depth to the
game, and if its customizable and ppl release "theme" packs, it could
stay around.
4.) I hope to add my efforts to the force at hand in creating a
standard, i urge all interested to do so also.
5.) the sound will i am almost sure, be an option like color, it wont be
required.
-sorry about the numbering but i didnt want to wander from the subject
like im prone to do all too often. :-)
thank you all for yr help.
Gr3mlin
jav...@iaxs.net
Ron Cole wrote:
>
> Though sound seems like a really good idea, I have yet to see it be
> more than the "little bells and whistles" that attract new players..
> and that older players turn off. For instance, the Gemstone III
> front-end for GEnie played music and had sound clips that played
> during certain events (combat, I believe). Though these were very
> interesting at first, most players ended up turning them off and
> of depth when used with purely graphical FE's, it seems superfluous
> on TEXT based games.
>
> -= Rindar
>
> anonymous wrote:
> >
> > Hello, i'm a beginning mud programmer, i know vbasic and basic, but im
> > learning C.
> > anyway, i think muds are missing something critical, SOUND.
> > i am trying to introduce this in to a rom2.4 set-up.
> > my ideas have it as an add-on to zmud or such that the client would
> > play, at a prompt;
> > 1.) a midi file for different areas
> > this could be downloaded at the time off entry to a new area. small
> > 5K-15K midi files
> > woundnt impead the play a great deal, or
> > downloaded proir and saved it on the client side disk.
> > 2.) wav's played on certain triggers.
> > this may already be possible in zMud, ihave to look into it.
> >
> > Features like this could make for some very popular muds and and clients
> > at support it.
> > Gr3...@hotmail.com
> > thanx, gr3mlin
Gmud client already allows you to import sound packs and assign sounds
to whatever events messages you please, if you are desperate enough for
some sounds to be patient enough to do it. Personally, after about the
100th time I've entered an area and heard the same sound(s) I would want
to rip the sound code right out of the mud. I would consider this a
gimmick who's time could be better spent on developing some significant
towards muds. Just my 2 cents worth. Flame me if you wish.
Beavis
He does it cause he knows its a joke. ;)
Mike Levine <mru...@ic.net> wrote in article <33492...@ic.net>...
> anonymous wrote:
> >
> > Hello, i'm a beginning mud programmer, i know vbasic and basic, but im
> > learning C.
> > anyway, i think muds are missing something critical, SOUND.
>
leaven
this is great to hear,
a long time ago, i recall posting on tips/tricks zmud that
people should get together and form some standards for "magic"
signals to cue the client,
i would hope your committee does not stop with sound,
perhaps you could rename yourselves the mud standard protocol
committee and work on a few more similar projects such as
magic signals that would trigger zmud's mapper, so it could
positively know its location
magic signals that would cue up simply graphic pictures
keep up the noble work,
vingalir
Michael A. Krause <mkr...@intersphere.com> wrote in article
<01bc4371$4bafa920$06f7...@krause.intersphere.com>...
> anonymous <gr3...@hotmail.com> wrote in article
> <334829...@hotmail.com>...
> >
> > anyway, i think muds are missing something critical, SOUND.
> > Any and all help is appreciated. I can be contacted at;
> > Gr3...@hotmail.com
> > thanx, gr3mlin
>
Ron Cole
Just as long as those of us who don't want our MUDs to use graphics
or sound aren't forced to upgrade so that we HAVE to use ZMUD
<<shrug>>
leaven wrote:
>
> this is great to hear,
> a long time ago, i recall posting on tips/tricks zmud that
> people should get together and form some standards for "magic"
> signals to cue the client,
>
> i would hope your committee does not stop with sound,
> perhaps you could rename yourselves the mud standard protocol
> committee and work on a few more similar projects such as
>
> magic signals that would trigger zmud's mapper, so it could
> positively know its location
>
[snip]
Martin Keegan
leaven wrote:
> i would hope your committee does not stop with sound,
> perhaps you could rename yourselves the mud standard protocol
> committee and work on a few more similar projects such as
It would be preferable if such matters were debated publically
in the newsgroups rather than on some private mailing list.
Given that the last time we tried to discuss this people not only
failed to reach agreement on a name but also the level at which
such a system would work, restricting the discussion to people who
can be bothered to email the god of Medevia to be added to a
mailing list is NOT a sensible way to go about it.
I'll restate my idea of how a mud terminal protocol ought to work:
The server should not dictate to the client (the way HTML docs oughtn't
to say <B> but <EM> etc, to indicate the logical structure of data,
rather than just its appearance)
The protocol should have a system for marking up output from the
server so that the client can display (or otherwise utilise) it
in the most sensible way possible. Different types of data (room
descriptions, communication, status messages etc) can be marked
up to let the client display them (possibly) in different windows
or colours, etc.
The protocol ought to sit on top of existing protocols like telnet.
Telnet supports a method for identifying and negotiating the
terminal capabilities
Had it been based on complicated, closed standards, the Web would not
have been so successful. HTTP and HTML are the glue which bind together
standards like MIME, ftp, telnet, finger, GIF, JPG, gzip. The protocol
ought to attempt to act in a similar way. Audiovisual data could be
referenced simply by giving an HTTP URL etc.
Since the protocol would have to contain several types of components
(marked up information, referenced or embedded images and sounds,
status info, windowing stuff etc), it should be possible to reach
agreement on separate parts of it before the whole is accepted.
Can we have a sensible debate about this now? Informed, not inflamed.
Mk
--
http://cyburbia.net.au/~martin/
http://cyburbia.net.au/~martin/mudtree.html
David Rudy
In article 53...@not.concentric.net, Ron Cole <clo...@not.concentric.net> writes:
>Though sound seems like a really good idea, I have yet to see it be
>more than the "little bells and whistles" that attract new players..
>and that older players turn off. For instance, the Gemstone III
>front-end for GEnie played music and had sound clips that played
>during certain events (combat, I believe). Though these were very
>interesting at first, most players ended up turning them off and
>opting for their own CD's. Though sound-effects add a great deal
>of depth when used with purely graphical FE's, it seems superfluous
>on TEXT based games.
Music and sound can go a good deal towards setting the 'mood' of the
game, even if the interface is textual. Ultima IV was little more
than a text game with an overhead map icon, but the music was cool
(I have it on Midi on my machine and even sometimes play it while
I mud).
Of course finding sounds and more importantly music to use becomes
quite a challenge, as those with talents to write music (or draw
graphics, for that matter) are much harder to find than those with
talents to write a description for a room. :-)
As for usings bells and whistles to attract new players - it seems
the very hardest thing is to attract and educate people that muds
even exist. It certainly can't hurt if a few more people on the net
know about mudding.
David Rudy
dar...@aule.eng.sun.com
Jamie Norrish
Martin Keegan <mar...@cam.sri.com> writes:
> The protocol should have a system for marking up output from the
> server so that the client can display (or otherwise utilise) it in
> the most sensible way possible.
I may be misunderstanding you here, but wouldn't it be better to have
the information marked up on the server according to the protocol?
This would presumably enforce strict adherence to the protocol, rather
than relying on the data to be well-formed.
> Different types of data (room descriptions, communication, status
> messages etc) can be marked up to let the client display them
> (possibly) in different windows or colours, etc.
I think richly marked-up text would be a great asset, not so much for
display purposes (though this would be nice too), but rather for the
ability it allows to manipulate the data. Obviously this is what
happens in normal coding now, but I'm thinking in particular of
recombinant text within, for example, a room description. This is
the sort of thing SGML (Standard Generalised Markup Language) was
designed for, and I think it would be worth a look as at least a model
for both what can be done, and how.
Jamie
Chip Paul
Ron Cole wrote:
>
> Just as long as those of us who don't want our MUDs to use graphics
> or sound aren't forced to upgrade so that we HAVE to use ZMUD
> <<shrug>>
>
> leaven wrote:
> >
> > this is great to hear,
> > a long time ago, i recall posting on tips/tricks zmud that
> > people should get together and form some standards for "magic"
> > signals to cue the client,
> >
> > perhaps you could rename yourselves the mud standard protocol
> > committee and work on a few more similar projects such as
> >
> > positively know its location
> >
> [snip]
My mud has been implementing protocols on both the server and client
end.
We currently have a java client supporting image clips to be displayed,
as
well as sound, and local editing of server files (for you wizzes)
The server is configured to recognize use of the client, and only sends
the
control messages to you if you are using the Inferno client. The images
and
sound are just the first messages to be interpreted; we aspire to a
tile-based
game based on an expandable mud engine, but I thought some of you out
there
might just be satisfied with the current client.
The current release is a little buggy, but I have an in-house build that
is more
stable. It was designed under Win95, so differences in java virtual
machines/awt's
may cause undesired effects on other platforms. That much said, here is
the mud/client
homepage:
http://wakko.isdn.uiuc.edu/~inferno/
Please note that we are STILL in development, so don't expect too much,
and no,
the modified lib is not available. But please feel free to grab the
client and check
out the mud, if for no other reason than to send me a bug report :)
I'll be updating
the version on the web site shortly.
Also, if information on the protocol used on Inferno would like to be
put up for
public debate in an effort to form a standard, I will be more than
willing to
disclose it...
Martin Keegan
Jamie Norrish wrote:
>
> Martin Keegan <mar...@cam.sri.com> writes:
>
> > The protocol should have a system for marking up output from the
> > server so that the client can display (or otherwise utilise) it in
> > the most sensible way possible.
>
> I may be misunderstanding you here, but wouldn't it be better to have
> the information marked up on the server according to the protocol?
Yes. You're misunderstanding me if you think that wasn't what I was
saying :) [The server does the marking up. The marking up is defined
by the protoccol]
> > Different types of data (room descriptions, communication, status
> > messages etc) can be marked up to let the client display them
> > (possibly) in different windows or colours, etc.
>
> I think richly marked-up text would be a great asset, not so much for
> display purposes (though this would be nice too), but rather for the
> ability it allows to manipulate the data. Obviously this is what
Yup. We can't do voice-controlled muds until we can separate out
what is what from the text being chucked back.
> happens in normal coding now, but I'm thinking in particular of
> recombinant text within, for example, a room description. This is
> the sort of thing SGML (Standard Generalised Markup Language) was
> designed for, and I think it would be worth a look as at least a model
Jan Ingvoldstat said something along the lines of using a very HTML-like
subset of SGML.
> for both what can be done, and how.
Hopefully, even if people argue about what sort of representation to
use, agreement can be reached on what needs to be represented:
"you say <ROOMDESC> and I say \007\004\023", but we agree that location
descriptions ought to be marked up instead of calling the whole thing
off.
Martin Keegan
Chip Paul wrote:
>
> My mud has been implementing protocols on both the server and client
> end.
And this is the problem. Every man and his dog is going to write their
own protocols, which won't stand a chance of being compatible, and
will end up being server specific and client specific. This is why
discussion should be carried out in the mud groups.
Chip Paul
Martin Keegan wrote:
>
> Chip Paul wrote:
>
> >
> > My mud has been implementing protocols on both the server and client
> > end.
>
> And this is the problem. Every man and his dog is going to write their
> own protocols, which won't stand a chance of being compatible, and
> will end up being server specific and client specific. This is why
> discussion should be carried out in the mud groups.
>
> Mk
You should probably read the rest of people's posts before snipping
them. I said that I would like to put up what I have and work toward
a common mud protocol. But implementing my proprietary one has
given me a chance to work on other things, like handling the protocols
and doing the graphics/sound/whatever.
So, why don't you start the discussion instead of just campaigning
for one?
Jamie Norrish
Martin Keegan <mar...@cam.sri.com> writes:
> Jan Ingvoldstat said something along the lines of using a very
> HTML-like subset of SGML.
I really don't think HTML is strong enough by a long stretch. If this
is going to be done, it might as well be done at industrial-strength
level. Sure, you may end up with mark-up that few people use, but it's
better to have a robust system in place from the beginning.
> Hopefully, even if people argue about what sort of representation to
> use, agreement can be reached on what needs to be represented:
Well, let's start a list. And also, advance some design thoughts as
criteria for what goes on the list. I think there are two main parts
to this:
1) To allow players using appropriate client software to display the
text of the game according to their own style declarations; and
2) To allow for manipulation of text, either on the part of the player
or the MUD system.
Niether are new to MUDs, of course, but the extent to which we seem to
be suggesting is, as far as I'm aware. Text is already manipulated by
the system to give varying outputs - such as objects in inventory
lists and objects within a room. It's only a matter of extending the
markup to make it more flexible.
I haven't yet thought enough about this to make a useful list of
possible markup. I will however give a simple example of what might be
useful in terms of potentially manipulable text:
<ROOMDESC>
<SIGHT LIGHT="10">You are standing within a large cavern, whose
ceiling forms a natural dome high above your head.</SIGHT>
<SIGHT LIGHT="20">On the opposite side of the chamber from you can see
what looks to be a statue or monument of some size.</SIGHT>
<SMELL>The air here carries the smell of sulphur.</SMELL>
</ROOMDESC>
Yes, I did say simple, and it might be argued that it would be better
to attach some of the information to the objects in the room
themselves. However, all that aside, I hope it is clear that at least
one interesting thing is possible based on that markup when it is time
to present the description to a player.
Jamie
John Hart
Martin Keegan (mar...@cam.sri.com) wrote:
: Chip Paul wrote:
: >
: > My mud has been implementing protocols on both the server and client
: > end.
I, too, have written two protocols for my MUD, as well as a MUD Interconnection
system.
The first protocol is for client to server communications, while the second
protocol is used for server manager to server communications. The second
protocol was developed by someone else on here (forget his name off hand), but
he is away from the net for the next few months. The interconnection system
was discussed here a bit ago, and overall would allow better packet compression
techniques for multiple people playing from one outside site. The client to
server protocol is used so I can compress common data that gets sent, so that
even on a 14.4k connection, you will be able to see all of my graphics, and
hear all of the sounds, as if you were on ISDN.
: And this is the problem. Every man and his dog is going to write their
: own protocols, which won't stand a chance of being compatible, and
: will end up being server specific and client specific. This is why
: discussion should be carried out in the mud groups.
It would be a good idea to start a group that could help set down the standards
for the MUD protocols, so that there will be an actual standard to stick with
and upgrade/etc.
Anyone willing to join? I would be happy to introduce the work I have done.
(With the exception of my client.)
DaShadow
--
_______________________________________________________________________________
System Administrator / Webmaster
Usenix, Sage, SBN2, HTML Writers Guild
_______________________________________________________________________________
Ron Cole
David Rudy wrote:
[snip]
> Music and sound can go a good deal towards setting the 'mood' of the
> game, even if the interface is textual. Ultima IV was little more
> than a text game with an overhead map icon, but the music was cool
> (I have it on Midi on my machine and even sometimes play it while
> I mud).
Music can make stand-alone games.. or at least add to them.
The problem is that, when mudding, people spend hours a week in the
same places hunting. After a few hours, the music starts driving
most players nuts and they turn it off.. even though it can set the
mood for a stand-alone game. If anyone here has played Drakkar on
MPG-NET, they know what I mean <<shudder>>
> As for usings bells and whistles to attract new players - it seems
> the very hardest thing is to attract and educate people that muds
> even exist. It certainly can't hurt if a few more people on the net
> know about mudding.
It may very well do that. When people are creating FE's,
however, they should keep in mind that not every MUD/player will
want or use these new sound protocols. Just something to keep in mind
(IE, OFF SWITCH).
-= Rindar
Tatu P Saloranta
Jamie Norrish <ja...@tao.sans.vuw.ac.nz> writes:
>Martin Keegan <mar...@cam.sri.com> writes:
>> Jan Ingvoldstat said something along the lines of using a very
>> HTML-like subset of SGML.
>I really don't think HTML is strong enough by a long stretch. If this
>is going to be done, it might as well be done at industrial-strength
>level. Sure, you may end up with mark-up that few people use, but it's
>better to have a robust system in place from the beginning.
He didn't mean HTML (AFAIK), but a language defined in SGML,
(Standard Generalized Markup Language, a metalanguage).
HTML is defined in SGML as well (though it's not exactly a subset, nor
is is SGML its superset... but that's nitpicking).
In any case, I think that using SGML to define the markup language
would be Good Thing (tm). Not the only way to do it, but one of the
better ways in any case.
><ROOMDESC>
><SIGHT LIGHT="10">You are standing within a large cavern, whose
>ceiling forms a natural dome high above your head.</SIGHT>
><SIGHT LIGHT="20">On the opposite side of the chamber from you can see
>what looks to be a statue or monument of some size.</SIGHT>
><SMELL>The air here carries the smell of sulphur.</SMELL>
></ROOMDESC>
Problem here is that different muds have different needs for various
descriptions. Also, I think what you are suggesting here is something
that server should do before sending data to client (ie. checking whether
the player can sense these things, can he/she see here etc. etc.).
You could probably put additional information about what sort of
graphics should be used in addition to text, or something..
Anyways, that would be up to the protocol-development group to
discuss and decide.
Anyways, it'd be very interesting to get even a basic protocol that
muds could use when communicating with clients. Having n+1 different
more or less proprietary protocols is the worst possible thing IMHO.
--
Tatu Saloranta, aka Doomdark.
doom...@cc.hut.fi
Timothy Philip Vernum
doom...@alpha.hut.fi (Tatu P Saloranta) writes:
>Jamie Norrish <ja...@tao.sans.vuw.ac.nz> writes:
>><ROOMDESC>
>><SIGHT LIGHT="10">You are standing within a large cavern, whose
>>ceiling forms a natural dome high above your head.</SIGHT>
>><SIGHT LIGHT="20">On the opposite side of the chamber from you can see
>>what looks to be a statue or monument of some size.</SIGHT>
>><SMELL>The air here carries the smell of sulphur.</SMELL>
>></ROOMDESC>
[snip]
>Also, I think what you are suggesting here is something
>that server should do before sending data to client (ie. checking whether
>the player can sense these things, can he/she see here etc. etc.).
I got the same impression when i first read it, but i suspect that what
he was suggesting was something slighlty different.
The LIGHT settings only give additional display descriptions regarding
the desriptions coming up. Like saying DISTANCE=30 and DISTANCE=10 to
allow some resourceful client writers to provide a way of spacing the
descriptions in some way appropriate for the attributes.
Some sort of XYZ co-ordinates could be very cool here.
ie: The server has already checked that the player can see in LIGHT(10),
and is telling the client this info only so it can put the things in brighter
light in bold, if the user so chooses.
>You could probably put additional information about what sort of
>graphics should be used in addition to text, or something..
I agree, but he did say this was a simple example.
Ed Snible
In article <doomdark....@snakemail.hut.fi>, doom...@alpha.hut.fi
says...
>In any case, I think that using SGML to define the markup language
>would be Good Thing (tm). Not the only way to do it, but one of the
>better ways in any case.
I've recently look into MUD protocols. I've been playing around with
the Pueblo client (an HTML/VRML + extra stuff). (Pueblo is a Win32
client for now, see http://www.chaco.com/pueblo/).
I am finding it very tedious and error prone to write a MUD server which
works with both traditional (telnet-based) clients and HTML clients. I
feel it if a single server is to handle both telnet and HTML clients that
some kind of meta-layout which can be translated into both will be
required on the server end. The SGML idea seems interesting. I'm afraid
I don't have any SGML experience. I want to define a design pattern so that
I can create different kinds of output:
telnet:
Exits: [north] [east]
Pueblo:
<b>Exits:</b>
<a xch_cmd=n xch_hint="Go North">North</a>
<a xch_cmd=e xch_hint="Go East">East</a>
It would be ideal if I could define the meta-layout in such a way that
the HTML (Pueblo) and ANSI colors (telnet) could be altered at run-time,
and that I could code new client types in the future without changing the
database.
Would SGML be the ticket for this?
Slash
esn...@goodnet.com
Matthew Griffin
There are already a number of muds out there that use sound - both in a
fixed way and a definable one (IE The players can match a sound to an
action/ event etc) - have a look on the mud connector - either way there
are quite a few about.
Matt
In article <334E17...@uiuc.edu>, Chip Paul <r-p...@uiuc.edu> writes
>Ron Cole wrote:
>>
>> Just as long as those of us who don't want our MUDs to use graphics
>> or sound aren't forced to upgrade so that we HAVE to use ZMUD
>> <<shrug>>
>>
>> leaven wrote:
>> >
>> > this is great to hear,
>> > a long time ago, i recall posting on tips/tricks zmud that
>> > people should get together and form some standards for "magic"
>> > signals to cue the client,
>> >
>> > i would hope your committee does not stop with sound,
>> > perhaps you could rename yourselves the mud standard protocol
>> > committee and work on a few more similar projects such as
>> >
>> > magic signals that would trigger zmud's mapper, so it could
>> > positively know its location
>> >
>> [snip]
>
>My mud has been implementing protocols on both the server and client
>end.
Matthew Griffin
>You should probably read the rest of people's posts before snipping
>them. I said that I would like to put up what I have and work toward
>a common mud protocol. But implementing my proprietary one has
>given me a chance to work on other things, like handling the protocols
>and doing the graphics/sound/whatever.
>
>So, why don't you start the discussion instead of just campaigning
>for one?
TONS of people have attempted protocols before but none have ever worked
- the best example of this is a protocol for area creation and
implementation which, although some people are still trying to make one
fell flat on its face.
Basically the trouble with muds and protocols is this: muds are created
by hobbists (in the main) and as such everyone does what they want to
and with the code irrespective of protocols or not. Protocols will work
to a degree but about 99% of mud admin ignore them and do it their own,
better way.
Matt
Abigail
On 12 Apr 97 08:57:45 GMT, Tatu P Saloranta wrote in
alt.mud.programming,rec.games.mud.admin,rec.games.mud.diku <URL: news:doomdark....@snakemail.hut.fi>:
++
++ He didn't mean HTML (AFAIK), but a language defined in SGML,
++ (Standard Generalized Markup Language, a metalanguage).
++ HTML is defined in SGML as well (though it's not exactly a subset, nor
++ is is SGML its superset... but that's nitpicking).
++ In any case, I think that using SGML to define the markup language
++ would be Good Thing (tm). Not the only way to do it, but one of the
++ better ways in any case.
++
++ Problem here is that different muds have different needs for various
++ descriptions. Also, I think what you are suggesting here is something
++ that server should do before sending data to client (ie. checking whether
++ the player can sense these things, can he/she see here etc. etc.).
Different needs for various descriptions is not a problem. That's why
there are CSS and DSSSL next to SGML. (CSS and DSSSL are style sheet
descriptions; style sheets handle the presentation issues. CSS is being
implemented in various WWW browsers, Netscape, MSIE, Amaya, EmacsWWW,
Arena can or will all be able to deal with CSS. DSSSL is a more
powerful (Turing equivalent) style sheet descriptor).
Abigail -- Follow ups set.
Abigail
On 12 Apr 1997 15:23:48 GMT, Ed Snible wrote in
alt.mud.programming,rec.games.mud.admin,rec.games.mud.diku <URL: news:5io9e4$a...@alice.walrus.com>:
++ In article <doomdark....@snakemail.hut.fi>, doom...@alpha.hut.fi
++ says...
++
++ >would be Good Thing (tm). Not the only way to do it, but one of the
++ >better ways in any case.
++
++ the Pueblo client (an HTML/VRML + extra stuff). (Pueblo is a Win32
++ client for now, see http://www.chaco.com/pueblo/).
++
++ I am finding it very tedious and error prone to write a MUD server which
++ works with both traditional (telnet-based) clients and HTML clients. I
++ feel it if a single server is to handle both telnet and HTML clients that
++ some kind of meta-layout which can be translated into both will be
++ required on the server end. The SGML idea seems interesting. I'm afraid
++ I don't have any SGML experience. I want to define a design pattern so that
++ I can create different kinds of output:
++
++ telnet:
++ Exits: [north] [east]
++
++ Pueblo:
++ <b>Exits:</b>
++ <a xch_cmd=n xch_hint="Go North">North</a>
++ <a xch_cmd=e xch_hint="Go East">East</a>
++
++ It would be ideal if I could define the meta-layout in such a way that
++ the HTML (Pueblo) and ANSI colors (telnet) could be altered at run-time,
++ and that I could code new client types in the future without changing the
++ database.
++
++ Would SGML be the ticket for this?
Not in the way you are suggesting it. SGML is used to separate content
and presentation. If you use SGML, then you tell the client, "here's
a list of exits", and leave it up to the client how to display it.
If your client has style sheet support, you can use style sheets to
suggest certain rederings, but that's all.
I would do your exit example as:
<EXITS>
<EXIT code = "north">A road leading north.</EXIT>
<EXIT code = "east">A door to the east.</EXIT>
</EXITS>
And leave it up to the client how to display the exits. It would be
an application issues what the client needs to send back when the
player selects an exit.
Abigail
john
: : And this is the problem. Every man and his dog is going to write their
: : own protocols, which won't stand a chance of being compatible, and
: : will end up being server specific and client specific. This is why
: : discussion should be carried out in the mud groups.
this is not necessarily a problem. not everyone wants compatible
protocols. i rather like my own server and client protocols. but, the
"standard" protocols idea is also good, and should be discussed
here.
Erik Lavander
Aye, I would like a markup-language for rooms,
with if-like statements to send different
lines of text to the player depending on time
of day, season, recent things that has happened
in the area (battle, fire). This could of
course be done in code, but such things often
end up being printed after the description of
the room.
Having such information integrated in the
roomdesc would IMHO add a lot tho the story-feel
of the MUD in question.
/Erik Lavander
eril...@student.luth.se
Nathan F. Yospe
In article <33510E...@student.luth.se>, Erik Lavander
<eril...@student.luth.se> wrote:
Sounds like you have confused internal markup with external... there are
muds with both. (Mine has internal, I've not really seen a good reason to
use an external markup language. Physmud++ uses internal markup in much
the way you describe, based on sensory level, which will be tweaked by
external factors, such as light level, background noise, background scent,
etc, and presented to the player based on their character's perception in
each sense... but that's totally independent of any protocol, as it is
an internal thing, and all processed before the stuff gets sent down the
pipe. In fact, the only people with reason to care are builders, and they
are building for the Physmud++ platform alone. External markup means that
the client/terminal would be interpreting tags in the text... this might
be nice, in the case of graphics and sound, but is pointless for
modification of text. Another note: adding this sort of thing after the
description of the room is mostly a reflection of limitations of the
technique for adding these conditional descriptions. I discourage strongly
the seperation of static and dynamic text in descriptions of a room... it
sort of results in a glance at the bottom of the blurb, nothing more.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!
Walter Goodwin
>Aye, I would like a markup-language for rooms,
>with if-like statements to send different
>lines of text to the player depending on time
>of day, season, recent things that has happened
>in the area (battle, fire). This could of
>course be done in code, but such things often
>end up being printed after the description of
>the room.
>Having such information integrated in the
>roomdesc would IMHO add a lot tho the story-feel
>of the MUD in question.
Actually, if you implement an html-like interface for room descriptions,
you might as well extend it to all the character strings. I've been toying
with the idea as of late (no real code, for back burner projects I always
use pseudo code :) My main problems are: How to parse the text so that
the if checks can be done easily, when to parse the checks, and depending
on when the checks are checked, the security issues. (not to mention
handling the formatting of text so that descripts don't look like crap)
For instance, if all the text to be sent out to a character is buffered,
then you could parse the checks right before they are sent out, but then
what's to stop a vindictive player from shouting some destructive string
like "<check this", of course, when the text is buffered you could check
where the text is coming from, and then do the checks if it is coming
from a "secure" source. Or perhaps use something like smash_tilde on all
incoming player strings.
I thought that the actual parsing could be done by a special client,
but that has its downfalls, 1. you require a special client to be installed
which limits who can play, 2. security, again, a player could theoretically
alter, or just use telnet :), the client to display the codes and get
hidden info, for instance, in a quest the character might have to find
a potion to see through an illusion, but thanks to the altered client
he can now see <see_illusion> Scrawled on the altar are the words DSSIDIFS
OGIGI.</see_illusion> Which is the password to get past a guard. 3. the
client needs specialized info about the character, which means A) the
client has to query the server whenever it needs something, or is updated
whenever it is sent new stuff, or B) it keeps track of the player object
and updates the server when queried. Both of these are extremely bad when
considering a bad link. Security issues also pop up for the second when
hacked clients are involved, not to mention all the headaches of keeping
everything in synch, like if "lost packets" arive a few minutes later
with a character update after an update had already arrived. (suffice
it to say, I'm not going to go through a client to do this :)
I haven't really put much work in the concept at all, (its on the backburner)
and would be extremely interested in hearing about anyone that has done
anything interesting with this. (I imagine it would be mainly used to
make areas and descriptions much more, er, alive, and to give a builder
the opportunity to do some really special things with an area. :)
Martin Keegan
> : And this is the problem. Every man and his dog is going to write their
> : own protocols, which won't stand a chance of being compatible, and
> : will end up being server specific and client specific. This is why
> : discussion should be carried out in the mud groups.
>
> for the MUD protocols, so that there will be an actual standard to stick with
> and upgrade/etc.
Or ... we could just use the normal newsgroups like rec.games.mud.admin
and alt.mud.programming (preferably the former).
> Anyone willing to join? I would be happy to introduce the work I have done.
Perhaps people SHOULD all post what they've done so far ...
We should not expect anyone's system to be adopted, and
should share this info only for demonstration purposes.
Martin Keegan
Jamie Norrish wrote:
> > Jan Ingvoldstat said something along the lines of using a very
> > HTML-like subset of SGML.
>
> I really don't think HTML is strong enough by a long stretch. If this
> is going to be done, it might as well be done at industrial-strength
> level. Sure, you may end up with mark-up that few people use, but it's
> better to have a robust system in place from the beginning.
HTML-like. Not HTML. Exactly the same sort of thing as you've included
below! Read more carefully :).
> be suggesting is, as far as I'm aware. Text is already manipulated by
> the system to give varying outputs - such as objects in inventory
> lists and objects within a room. It's only a matter of extending the
> markup to make it more flexible.
Exactly! :)
> I haven't yet thought enough about this to make a useful list of
> possible markup. I will however give a simple example of what might be
> useful in terms of potentially manipulable text:
> <ROOMDESC>
> <SIGHT LIGHT="10">You are standing within a large cavern, whose
> ceiling forms a natural dome high above your head.</SIGHT>
> <SIGHT LIGHT="20">On the opposite side of the chamber from you can see
> what looks to be a statue or monument of some size.</SIGHT>
> <SMELL>The air here carries the smell of sulphur.</SMELL>
> </ROOMDESC>
Yep. You're singing my tune :). I posted something like this a few
months ago, and it was ripped apart by people who wanted to do
binary encryption and other irrelevant shit.
(This is actually better than what I was posting a while back, but
has the problem of being more mud-specific and less generalised.)
> Yes, I did say simple, and it might be argued that it would be better
> to attach some of the information to the objects in the room
Sure sure. Early days yet.
Martin Keegan
Walter Goodwin wrote:
>
> In article <33510E...@student.luth.se>,
> Erik Lavander <eril...@student.luth.se> wrote:
>
> >Aye, I would like a markup-language for rooms,
> >with if-like statements to send different
> >lines of text to the player depending on time
> >of day, season, recent things that has happened
> >in the area (battle, fire). This could of
> >course be done in code, but such things often
> >end up being printed after the description of
> >the room.
> >Having such information integrated in the
> >roomdesc would IMHO add a lot tho the story-feel
> >of the MUD in question.
>
> For instance, if all the text to be sent out to a character is buffered,
> then you could parse the checks right before they are sent out, but then
> what's to stop a vindictive player from shouting some destructive string
> like "<check this", of course, when the text is buffered you could check
Why would you allow players the ability to do this?
> where the text is coming from, and then do the checks if it is coming
> from a "secure" source. Or perhaps use something like smash_tilde on all
> incoming player strings.
smash_tilde? Is this some Diku thing?
> I thought that the actual parsing could be done by a special client,
> but that has its downfalls, 1. you require a special client to be installed
> which limits who can play, 2. security, again, a player could theoretically
Having a single sane protocol would maximise the number of clients
you'd get to support it.
> alter, or just use telnet :), the client to display the codes and get
Since the use of telnet programs is generally detectable by the
server, telnet users wouldn't get to see the raw text unless they
explicitly asked for it.
> hidden info, for instance, in a quest the character might have to find
If it's hidden info, then you don't go sending it down the wire to
the players!
> a potion to see through an illusion, but thanks to the altered client
> he can now see <see_illusion> Scrawled on the altar are the words DSSIDIFS
> OGIGI.</see_illusion> Which is the password to get past a guard. 3. the
> considering a bad link. Security issues also pop up for the second when
> hacked clients are involved, not to mention all the headaches of keeping
Only if the protocol is stupid enough to trust the client in any way.
If you don't want the players to be able to do something, don't let
them. If you don't want them to see something, don't show it to them.
> everything in synch, like if "lost packets" arive a few minutes later
> with a character update after an update had already arrived. (suffice
> it to say, I'm not going to go through a client to do this :)
Que? If you're using TCP, is this going to happen? No.
Martin Keegan
john wrote:
>
> : : And this is the problem. Every man and his dog is going to write their
> : : own protocols, which won't stand a chance of being compatible, and
> : : will end up being server specific and client specific. This is why
> : : discussion should be carried out in the mud groups.
>
> protocols. i rather like my own server and client protocols. but, the
> "standard" protocols idea is also good, and should be discussed
> here.
Most people would want a common standard. Probably like HTML -
people can add their own bits, and so long as these additions conform
to the overall spirit of the system, they can be included in the
next version.
Martin Keegan
Ed Snible wrote:
> >In any case, I think that using SGML to define the markup language
> >would be Good Thing (tm). Not the only way to do it, but one of the
> >better ways in any case.
I don't personally know what SGML is exactly, but I have a very good
idea of what it's about and the principles involved. I suspect this
holds for a lot of the people posting in this thread. Would someone
who knows what SGML is explain with some detail? It's like HTML,
but more generalised, right?
> I've recently look into MUD protocols. I've been playing around with
> the Pueblo client (an HTML/VRML + extra stuff). (Pueblo is a Win32
> client for now, see http://www.chaco.com/pueblo/).
I can never find the actual definition of the Pueblo protocol. If
someone has FOUND this on the web, can they send me a pointer to it.
Until then, I shall assume that it's proprietary.
[big snip]
> It would be ideal if I could define the meta-layout in such a way that
> the HTML (Pueblo) and ANSI colors (telnet) could be altered at run-time,
> and that I could code new client types in the future without changing the
> database.
This probably isn't too hard.
Ed Snible
In article <335236...@cam.sri.com>, mar...@cam.sri.com says...
>
>I can never find the actual definition of the Pueblo protocol. If
>someone has FOUND this on the web, can they send me a pointer to it.
>Until then, I shall assume that it's proprietary.
From what I have gathered, the Pueblo protocol has some standard-based
components and some non-standard components. It definately supports
something almost exactly like HTML (with a few minor changes, like newlines
actually do a newline.)
For documentation you can read in your browser, see
http://www.chaco.com/pueblo/doc/enhancing.html
Unfortunately, this isn't the actual defininition. That comes in the
Windows .HLP file that comes with the client. (I feel this is a poor
choice. If anyone is interested in seeing this, I'll try to suck a
copy of the text out of the help system.)
As for the actual network protocol, it appears to be the non-standard.
(It's tintin protocol, which has no RFC as far as I know.)
I'm just beginning to look at what can be done with their client. It
has been pretty easy so far. I haven't touched the VRML stuff, though.
Slash
Here is some snips from the documentation on Pueblo's extensions: In the
actual documentation, all of the tags are hyper-linked to their meaning
-------------------------------------------------------------------------
Basic extensions to HTML:
This section lists some general HTML extensions Chaco has made with the
intent of improving usability of HTML documents, streams, and clients.
event xch_hint <xch_page> <xch_pane> <xch_prefetch>
xch_prob
Extensions for interactivity:
This section lists the HTML extensions Chaco has made to allow interactive
HTML sessions.
xch_cmd xch_mode xch_mudtext
Extensions for graphics:
This section describes the HTML extensions Chaco has made to allow an HTML
session to control a VRML scene.
xch_graph
Extensions for sound:
This section describes the HTML extensions Chaco has made to allow an HTML
session to control sound.
xch_sound xch_volume xch_alert xch_device
Extensions for interactivity:
This section lists the VRML extensions Chaco has made to allow interaction
between VRML world files and Pueblo.
xch_cmd Info
Extension Nodes:
This section describes the VRML extension nodes Chaco supports.
BackgroundColor Info BackgroundImage Info SpinGroup Spin
Nathan F. Yospe
In article <yuezpv1...@tao.sans.vuw.ac.nz>, Jamie Norrish
<ja...@tao.sans.vuw.ac.nz> wrote:
:yo...@hawaii.remove.this.edu (Nathan F. Yospe) writes:
:
:> External markup means that the client/terminal would be interpreting
:> tags in the text... this might be nice, in the case of graphics and
:> sound, but is pointless for modification of text.
:
:Well, not exactly - one could potentially allow for the player to
:specify that the different parts of the description, for example, be
:reordered, giving the presentation that the player wishes.
I will admit, there are usages such as this that are nice, but nothing
that can be justified as a general protocol. I have nothing that looks
like a hitpoint, for example. And if there was support for this sort of
thing, it would only encourage stockishness. Things like presentation
style make sense, but not mud specific info.
:BTW, I was wondering, while I wrote my short, very simple example
:previously, to what extent it would be useful to have internal and
:external markup be the same - that is, marked up with the same tags.
:This would seem remove some redundancy, and make the external markup
:more useful.
It has the unfortunate results of allowing easy accidental tranmission
of internal workings (having the internal markup differ from text allows
an exception throw...) but is otherwise not hazardous. Does suggest a
rather limited internal markup system, though, doesn't it? *shrug*
Jamie Norrish
yo...@hawaii.remove.this.edu (Nathan F. Yospe) writes:
> External markup means that the client/terminal would be interpreting
> tags in the text... this might be nice, in the case of graphics and
> sound, but is pointless for modification of text.
Well, not exactly - one could potentially allow for the player to
specify that the different parts of the description, for example, be
reordered, giving the presentation that the player wishes.
BTW, I was wondering, while I wrote my short, very simple example
previously, to what extent it would be useful to have internal and
external markup be the same - that is, marked up with the same tags.
This would seem remove some redundancy, and make the external markup
more useful.
Jamie
Matthew Julius
Martin Keegan wrote:
>
> Jamie Norrish wrote:
>
> > possible markup. I will however give a simple example of what might be
> > useful in terms of potentially manipulable text:
>
> > <ROOMDESC>
> > <SIGHT LIGHT="10">You are standing within a large cavern, whose
> > ceiling forms a natural dome high above your head.</SIGHT>
> > <SIGHT LIGHT="20">On the opposite side of the chamber from you can see
> > what looks to be a statue or monument of some size.</SIGHT>
> > <SMELL>The air here carries the smell of sulphur.</SMELL>
> > </ROOMDESC>
>
> Yep. You're singing my tune :). I posted something like this a few
> months ago, and it was ripped apart by people who wanted to do
> binary encryption and other irrelevant shit.
This example is good, don't misunderstand me there. But, I think
this is still too specific to be of any use. Well, that and I'd
like to see a few differences ...
I would prefer the beginning and ending of the 'packet' be delimited
by a special token, instead of, for example, <ROOMDESC>.
I'll just use packet for lack of a better word ...
<PACKET ROOMDESC>
...
</PACKET>
Thus, if the client gets in one blurb a bunch of these 'packets'
it would have a better means to distinguish them. Beyond this
little nitpick I like the system and I think it would be very
easy to implement on most muds.
After this, I think a common set of tokens be in the protocol.
These would be the things that have the most in common amongst
all the types of muds. Then, the mud itself can use its own
tags if any vary from the 'standard' ones. The standard tags
being anything in common in any of the mud families (DIKU, LP
and all others). These are things in common with the mud type
itself, not *all* muds. So, there are some standard things
like maybe 'health' and then there are things that would be
specific to LP's or some other type of mud.
Thus, it is important for the *client* to be generalized, not
the mud. The client should, for example, allow its user to
direct various 'packets' to certain windows (or equivalent) then
to allow its user to further modify the packet by the tags
inside that packet (reordering them, deleting some, other
modifications like color, sound ...).
In this way, a mud can send whatever tags it wishes and the
user should be able to do whatever they wish with them,
including ignoring them completely. Furthermore, the client
itself should then be able to work on as many different
types of muds as possible. Only then would I even consider
this to be a standard. If the means to accomplish it, as I
have outlined here, doesn't accomplish this then some new
method needs to be thought up.
Adding 'links' in the text (which I think is the purpose of
hyper text, am I wrong ?) should be fairly easy. For example,
clicking on an 'exit' with your mouse (or highliting it and
hitting enter ... whatever) should take you in that direction,
if it were a 'link'. Sound and images could all be done in
the same manner. It should be left up to the client and the
user to specify whether or not they want to play sounds or
play specific sounds (or images, etc). I suppose there should
be a different tag to distinguish just an effect sound, like
a sword clash, between a background sound, like music.
The things mentioned like <* LIGHT="10"> ... the LIGHT is too
specific to be in the protocol. SIGHT, HEAR and SMELL are
all very good though. That's just another nitpick. I think
the example was only given to demonstrate the power, not
become the actual protocol ... I assume.
I'm pretty much rambling here, but I just wanted to say
the kind of system I would go out of my way to support. I
hope others will agree with me at least on the goals of
the protocol, not necessarily the protocol itself.
--
Matthew Julius o_o
( _ )
s01...@discgate.wright.edu ( | | )
Matthew Julius
I hate to reply to myself, but after thinking this over a bit more
I'm gonna do just that. Heh ...
Matthew Julius wrote:
>
> > Jamie Norrish wrote:
> >
> > > <ROOMDESC>
> > > <SIGHT LIGHT="10">You are standing within a large cavern, whose
> > > ceiling forms a natural dome high above your head.</SIGHT>
> > > <SIGHT LIGHT="20">On the opposite side of the chamber from you can see
> > > what looks to be a statue or monument of some size.</SIGHT>
> > > <SMELL>The air here carries the smell of sulphur.</SMELL>
> > > </ROOMDESC>
>
> This example is good, don't misunderstand me there. But, I think
> this is still too specific to be of any use. Well, that and I'd
> like to see a few differences ...
>
> I would prefer the beginning and ending of the 'packet' be delimited
> by a special token, instead of, for example, <ROOMDESC>.
> I'll just use packet for lack of a better word ...
>
> <PACKET ROOMDESC>
> ...
> </PACKET>
>
> Thus, if the client gets in one blurb a bunch of these 'packets'
> it would have a better means to distinguish them. Beyond this
> little nitpick I like the system and I think it would be very
> easy to implement on most muds.
I should've thought about it a bit more, this really ought to
be something like
<PACKET>
<ROOMDESC>
... internal tags ...
</ROOMDESC>
</PACKET>
> Adding 'links' in the text (which I think is the purpose of
> hyper text, am I wrong ?) should be fairly easy. For example,
> clicking on an 'exit' with your mouse (or highliting it and
> hitting enter ... whatever) should take you in that direction,
> if it were a 'link'. Sound and images could all be done in
> the same manner. It should be left up to the client and the
> user to specify whether or not they want to play sounds or
> play specific sounds (or images, etc). I suppose there should
> be a different tag to distinguish just an effect sound, like
> a sword clash, between a background sound, like music.
This is the part I put some thought into. Let's just assume
we have a tag like so ... I think everyone can see what it does.
There is a <CMD examine door>door</CMD>
to the <CMD north>north</CMD>.
Of course, the beauty of it is that the commands could be
anything. And thus, any kind of similar situation should be
workable on all muds. However, a problem arises as to when
the link becomes invalid, if ever. What if the person clicks
on the north, moves, then clicks on the north again. If the
link remains active then the person could just keep clicking
on it when they're no longer in that room. Looking at this
scenario I think instead of introducing an even more confusing
syntax to toggle on or off various links that they should
all remain active instead. If the person's dumb enough to
click on them, so be it.
Another thing ...
Should the client become somewhat graphical ?
That is, make certain text into icons (or just pure text) and
allow the person to drag and drop it somewhere ? In particular,
anything like an inventory (be it in a room or your own). Can
you click on a sword lying on the ground and drag it to a bag
that's in your inventory ? Does the mud define this ? Does
the client define this ? Very good question I think. If the
mud does it then it gets rather complex, and I think a complex
protocol is something to avoid ... If the client does it then
it still needs some data from the mud.
I don't know ... maybe something like
<ROOMDESC>
...
<ROOMINV>
<OBJECT blue ball>A <CMD examine blue ball>blue ball</CMD>
is here.</OBJECT>
</ROOMINV>
</ROOMDESC>
Now the client at least knows that the blue ball is an object
that can be manipulated. So, it's possible that the user has
defined certain things to happen when they click on that *line*
of text. For example, they click on that line and they've
defined the appropriate command to get it. Or, they defined
something to happen when they double click on it. I certainly
don't think the mud should have to specify what happens when
the user does something (that gets tooo intensive for the mud).
However, look at the all the extra syntax to allow such a
thing. Is it worth it ?
Hmm ... another thing maybe.
<DOWNLOAD desc="A cool sound file"
local_file="doorcreak.wav"
remote_file="public/sounds/doorcreak.wav">
...
</DOWNLOAD>
The client asks the user,
Download "A cool sound file"
Yes No
Prolly in a window of sorts.
Thing you gotta take into consideration ...
Do you download it with the tag, or do you do it only if
the person wants it ? Or, should the protocol not even
bother with such a thing ?
These kinds of questions I think are the ones that should be
focused on. That is, defining what the protocol should allow.
Anything that it implements should be 1) easy to install on
a mud and 2) be relevant to most muds.
Anyways, I'm reallly rambling here. I just want to see this
work and be good enough to actually use.
Erik Lavander
Exactly.
And why stop with tags for room descriptions? Use such tags for items
(Runes in languages, requiring sufficient skill in that language),
monsters (Is this an ordinary peaceful monk? Is it a dark elf in
disguise,
p'rhaps?) and players (I can't notice any weapon on him - then what is
this sharp object in my back?). Of course, such tagged descriptions
could
get huge, if all different types of perception is considered (infrared,
magic, hearing, smell, radioactivity, magnetic anomalies, perception
skill
ranging from 0-100 an so on. :)
EriK L
Jamie Norrish
yo...@hawaii.remove.this.edu (Nathan F. Yospe) writes:
> In article <yuezpv1...@tao.sans.vuw.ac.nz>, Jamie Norrish
> <ja...@tao.sans.vuw.ac.nz> wrote:
> :Well, not exactly - one could potentially allow for the player to
> :specify that the different parts of the description, for example,
> :be reordered, giving the presentation that the player wishes.
> I will admit, there are usages such as this that are nice, but
> nothing that can be justified as a general protocol. I have nothing
> that looks like a hitpoint, for example. And if there was support
> for this sort of thing, it would only encourage stockishness. Things
> like presentation style make sense, but not mud specific info.
I think you misunderstand. If there was a room description, it might
be displayed in different orders by different people who have set
their client to order the marked up sections in the description
differently. This isn't MUD specific info, at least as I understand
your term.
> :BTW, I was wondering, while I wrote my short, very simple example
> :previously, to what extent it would be useful to have internal and
> :external markup be the same - that is, marked up with the same tags.
> :This would seem remove some redundancy, and make the external markup
> :more useful.
> It has the unfortunate results of allowing easy accidental
> tranmission of internal workings (having the internal markup differ
> from text allows an exception throw...) but is otherwise not
> hazardous. Does suggest a rather limited internal markup system,
> though, doesn't it? *shrug*
Not necessarily - mark up can be hugely comprehensive.
Jamie
Jamie Norrish
Here's a very small proposal for some of the element tags that might
be useful in dealing with room descriptions.
To begin, an element for room descriptions. I prefer <ROOMDESC> with
an ID attribute, but whatever - it's the underlying ideas that are
currently important; element names are gloss.
What follows is simply each element listed, followed by what elements
it contains (either must or can; I'm not concerned with anything that
fancy yet).
ROOMDESC contains FAKEOBJECT, REALOBJECT
FAKEOBJECT and REALOBJECT contain SIGHT, SOUND, SMELL, TASTE, TACTILE
Fakeobject for objects which do not exist as objects in the database
(such as the room itself, in most instances, and "scenery" objects)
SIGHT, SOUND, SMELL, TASTE, TACTILE contain text
So, everything has its description subdivided into its sensory
components. One might then go on to add attributes to some of those
tags - such as, for REALOBJECT, a CLASS, which might allow a value of
"inanimate", "plant", or "animal".
Really, it's conceivable to have elements and attributes for just
about everything - size of an object, weather information, proper
nouns. All could be the basis for different presentation on the part
of the client. But again, I think the real strength in such a system
is the chance it affords to mess about with the actual data. Yes, it
gets into the matter of internal and external mark up, but it's
something I think is worth exploring.
Jamie
Chip Paul
Erik Lavander wrote:
> Exactly.
> And why stop with tags for room descriptions? Use such tags for items
> (Runes in languages, requiring sufficient skill in that language),
> monsters (Is this an ordinary peaceful monk? Is it a dark elf in
> disguise,
> p'rhaps?) and players (I can't notice any weapon on him - then what is
> this sharp object in my back?). Of course, such tagged descriptions
> could
> get huge, if all different types of perception is considered (infrared,
> magic, hearing, smell, radioactivity, magnetic anomalies, perception
> skill
> ranging from 0-100 an so on. :)
>
> EriK L
The problem with this is that the skills will need to be known to
the client, which presents several problems:
(1) The client becomes mud-specific
(2) A clever person can write a client to bypass or fake skills
My client will support things like this, but then again, my client
is specific to my mudlib, because it has to do necessary tasks
for tile based graphic rooms.
I like the idea of a generalize markup scheme for muds, but stuff
like illusions and disguises are better left handled by the server.
Tatu P Saloranta
Matthew Julius <s01...@discgate.wright.edu> writes:
>Matthew Julius wrote:
>This is the part I put some thought into. Let's just assume
>we have a tag like so ... I think everyone can see what it does.
>There is a <CMD examine door>door</CMD>
>to the <CMD north>north</CMD>.
Actually, these perhaps should be tagged as "items"?
One attribute (or a tag) could then be the default command to use with
the item... although, most of the time it probably would be a command
to examine the item in question?
>Of course, the beauty of it is that the commands could be
>anything. And thus, any kind of similar situation should be
>workable on all muds. However, a problem arises as to when
>the link becomes invalid, if ever. What if the person clicks
>on the north, moves, then clicks on the north again. If the
>link remains active then the person could just keep clicking
>on it when they're no longer in that room. Looking at this
>scenario I think instead of introducing an even more confusing
>syntax to toggle on or off various links that they should
>all remain active instead. If the person's dumb enough to
>click on them, so be it.
That was the first thing I thought of when I read your first
article (when do links get inactive... they should IMHO)...
However, if we are willing to make the protocol more than a
simple markup-language, we could solve this quite easily.
And as mud-communication by its nature is different from a 'real'
document handling (documents are static, can be parsed in one pass;
mud communication is stream-based; one has to parse it on-the-fly,
piece by piece), this shouldn't be all that radical a change?
Each item/link should probably have a unique id (as I'm mostly
familiar with LP-muds, filename() could produce just such an id),
which allows client to distinguish between different items.
So, something like (just an example; my SGML is bit rusty):
<PACKET>
<ROOMDESC id=room#2546>
...
<ITEM id=blue_thing#125>A blue thing</ITEM>
...
</ROOMDESC>
</PACKET>
Now, client can display this output whatever the way it wishes to;
perhaps by adding links to the output; or perhaps dividing things
into multiple windows.
However, these links should disappear when (for example):
- Player leaves the location (room). All links that were 'inside'
the room description should be de-activated.
- Someone else takes the blue thing, in which case just that link
should be deactivated.
- Player goes blind for some reason (or lights go out)
It should be fairly easy to send such event-messages as:
<ITEM_REMOVE>room#2546</ITEM_REMOVE>
<ITEM_REMOVE>blue_thing#125</ITEM_REMOVE>
These messages should probably be sent along the action messages
otherwise sent:
<ACTION>Foobar takes the <ITEM_REMOVE id=sword#14>sword<ITEM_REMOVE>.
</ACTION>
>Another thing ...
>Should the client become somewhat graphical ?
Protocol could allow for mud to hint which graphical icons/pics
should be used if items are presented graphically I think?
>That is, make certain text into icons (or just pure text) and
>allow the person to drag and drop it somewhere ? In particular,
Drag and drop sounds good; player could take/drop items by dragging
them from the room-display to inventory-display and vice versa.
Client would have to know something about command-syntaxes though..
Also, I think mud should then understand these mud-protocol-dependant
item ids; if you just pass "sword" to the mud, and there are more
than one present, it can't decide which was referred to... Of course,
this is more of an implementation detail, and can be handled. But
it'd be essential that protocol doesn't require too much changes
to the mud servers I think.
>anything like an inventory (be it in a room or your own). Can
>you click on a sword lying on the ground and drag it to a bag
>that's in your inventory ? Does the mud define this ?
Good questions... It might be best to make these customizable
by player, and just use some (hopefully) sensible default values
otherwise. Take/drop/take+put/take+drop
Mathue Moyer
Jamie Norrish (ja...@tao.sans.vuw.ac.nz) wrote:
> Here's a very small proposal for some of the element tags that might
> be useful in dealing with room descriptions.
[...]
> ROOMDESC contains FAKEOBJECT, REALOBJECT
> FAKEOBJECT and REALOBJECT contain SIGHT, SOUND, SMELL, TASTE, TACTILE
> Fakeobject for objects which do not exist as objects in the database
> (such as the room itself, in most instances, and "scenery" objects)
Looks like a good start. I'm curious, though, about the motivation behind
distinguishing between "FAKE" and "REAL" (logical and literal? implicit and
explicit?) objects. The existence of the distinction is, I think, unarguable,
but I don't see what benefit will be derived from including that distinction
in the protocol...?
On another note... might I humbly suggest that somebody with a good news feed
start archiving elements of this thread, now that it seems to be settling into
productive posts?
--
Mathue Moyer | Anyone who says they have only
Email: mat...@cts.com | one life to live must not know
URL: http://www.users.cts.com/king/m/mathue | how to read a book.
Jamie Norrish
mat...@king.cts.com (Mathue Moyer) writes:
[Snip my example of some elements.]
> I'm curious, though, about the motivation behind distinguishing
> between "FAKE" and "REAL" (logical and literal? implicit and
> explicit?) objects. The existence of the distinction is, I think,
> unarguable, but I don't see what benefit will be derived from
> including that distinction in the protocol...?
My thinking was nothing more than allowing for a client to display the
two differently, so that the player might immediately be able to see
the difference between an object that can be manipulated, and one that
isn't actually there. Actually, I'm not really sure this is a good
thing, now, but there you go.
> On another note... might I humbly suggest that somebody with a good
> news feed start archiving elements of this thread, now that it seems
> to be settling into productive posts?
Well, I'm not about to volunteer, but given that this is a subject
which interests me, I'll most likely start writing something to
incorporate all the good ideas I come across. I must admit I don't
much like USENET as a forum for this sort of thing, but that is likely
empty prejudice on my part, and I'll cope.
Jamie
Erik Lavander
This post is not meant as a reply to Jamies, more like a waitaminute-
heyheyheyholditnow. Read on and get the idea... :)
Logging ideas seems like a good idea, this *is* interesting. However,
many posts mention some kind of client to do the parsing of the tags.
Why use clients? Let the mud do the parsing instead of sending secret
info to a hackable client. This would of course increase the workload
on the server, but I think this if preferable to forcing players to use
a special client. (Maybe my addiction to mudding was clearly visible in
that last sentence; I wouldn't stand waiting for clients for *my*
platform... :)
No, let the server parse, the clienthackers rest and Telnet reign
supreme :)
EriK
Mathue Moyer
Erik Lavander (eril...@student.luth.se) wrote:
> This post is not meant as a reply to Jamies, more like a waitaminute-
> heyheyheyholditnow. Read on and get the idea... :)
> Logging ideas seems like a good idea, this *is* interesting. However,
> many posts mention some kind of client to do the parsing of the tags.
> Why use clients?
I'll take a stab at answering this, although other people involved in the
issue may disagree with my explanation. Most of the discussion about this
protocol to date has centered, not around controlling WHAT is displayed to
a user, but HOW things are displayed to the user. Several people (and I'd
be inclined to include you) have mentioned a desire to use some sort of
markup scheme internal to the MUD. This would, as an example, serve to
control things like variable portions of room descs based on ambient lighting,
items that will only be seen by sufficiently perceptive individuals, etc.
Most people seem to agree that an internal markup scheme like this is fine,
and should be __complete internal__ to the mud, since you can't really trust
a client to hide any information from a user.
The gist of this topic, then, is an EXTERNAL markup scheme with tags that are
passed to the user. Rather than controlling what the user can or can't see,
these tags could be used by clients to control how data is presented. For
instance, a windows client might separate room names and descriptions into one
window, room contents into another, communication into yet another, and combat
messages into a fourth. Additional functionality is being proposed that would
allow a client to generate hypertext-ish interaction with this marked-up mud
output. This would allow the user to perform actions by selecting text that
had been received from the mud. Once selected, the client could then generate
an appropriate command string (or some sort of command data) to send back to
the mud.
While the former should certainly be handled by the mud itself, the latter
should not. By moving the details of display onto the client side, the mud is
no longer required to be aware of all the possible display systems (different
OS's, different hardware, graphics, text, etc.).
<Change in topic>
A few people have remarked so far that the notion of adding hypertext-style
interaction with objects using this protocol may be undesirable because it
requires that the client have knowledge of (the command syntax of) the mud with
which it is attempting to interact. I don't feel that this is a problem.
As longs as the protocol itself is totally generic, a client could use
configuration files to determine the details of interacting with each particular
mud. As a simple example, let's say I play on ReallyCoolMud and ReallyWeirdMud.
On ReallyCoolMud, you acquire items from a room by doing "take <item>", and you
can study items in detail by doing "look at <item>". On ReallyWeirdMud, the
same functionality is available via "get <item>" and "examine <item>",
respectively. Now, as long as the protocol is handing my client suitable text
for the <item> field (e.g. "sword 3", "3.sword", "third sword", etc.), the
date sent back to the mud when I select hypertext corresponding to <item> can be
determined based on the configuration I've loaded. In fact, not only can I use
the configuration to provide the correct syntax... I can also specify totally
different default commands for different muds (e.g. selecting SWORD on
ReallyCoolMud might generate the output "take sword 3" while doing the same on
ReallyWeirdMud could generate "examine sword 3"). Note that this is completely
outside the scope of the protocol, and requires no real support unless we want
to provide a mechanism by which muds can upload a generic default configuration
to the user.
<Another change in topic>
Although I do think this is a pretty good subject, I'm a bit concerned about
the adoption of an SGML-ish or HTML-ish approach. I may be just a bit paranoid,
but doesn't it seem like bandwidth is already getting plenty scarce these days
without muds doubling the amount of output they generate? (And yes, I do think
doubling is an accurate guess at how much a really useful markup protocol would
increase overall output.)
mathue
Mathue Moyer
Tatu P Saloranta (doom...@alpha.hut.fi) wrote:
> Each item/link should probably have a unique id (as I'm mostly
> familiar with LP-muds, filename() could produce just such an id),
> which allows client to distinguish between different items.
> So, something like (just an example; my SGML is bit rusty):
Hmmm... I just came up with an idea for a different approach that might be
useful. I think we can all agree that anything coming from a mud that the
user can interact with can be associated with a context of some sort. Gold
in my purse and the lantern in my backpack can be associated with a context
arbitrarily named "inventory", my pants and shirt can be associated with a
context arbitrarily named "equipment", spells I have memorized can be
associated with a "grimoire" context, room contents in a "room" context,
global stuff (people on a "who" list, for instance) could be in a "world"
context... you get the idea. The important point is that anything you might
want to interact with can be associated, by the mud, with an arbitrarily
named context.
Given that framework, we can easily add syntax (tags?) for adding/removing
items to/from particular contexts, as well as creating and deleting contexts.
An example:
I log in to the game, and am placed in a room. As part of the login process,
the mud sounds out instructions to generate (as an example, and using arbitrary
names) contexts named: world, room, inventory, equipment, and spells.
It then sends data attempting to add relevant items to those contexts... perhaps
including lists of syntaxes for interacting with the items in those contexts.
It would also send data to other people in the room (and possibly the world as
well... totally up to each particular mud) to add _me_ as an item to room and
world contexts. Now, when I move to another room, the mud would (_could_,
rather) send data indicating that my client should delete a context named "room"
and create a context named "room" (or just reset the "room" context, if that's
easier).
I'm no protocol wiz, but I think I've managed to explain myself well enough for
more adept folks to figure out what I mean. :)
Craig Hackenmueller
You guys should go take a look at Pueblo. It can already do just about
everything said in this post. Ebon Mists is partially "Pueblo Enhanced".
It can trigger sounds, graphics, and additional windows in a Win95
environment. You can click on exits to move. Click on your inventory
to wear items, click on your eq to remove items. People who don't have
the pueblo client just get all the html stripped from the text before
it gets sent out to them.
When we go back online, come and check out ebonmists.cloudnet.com 8888
We are currently revamping the system right now, but will be back online
in around a week or so (April 22nd?).
Mathue Moyer (mat...@king.cts.com) wrote:
:
: mathue
Martin Keegan
> > Well, I'm not about to volunteer, but given that this is a subject
> > which interests me, I'll most likely start writing something to
> > incorporate all the good ideas I come across. I must admit I don't
> > much like USENET as a forum for this sort of thing, but that is likely
> > empty prejudice on my part, and I'll cope.
DejaNews will do it all for us. Don't worry :)
> > Jamie
>
> This post is not meant as a reply to Jamies, more like a waitaminute-
> heyheyheyholditnow. Read on and get the idea... :)
> Logging ideas seems like a good idea, this *is* interesting. However,
> many posts mention some kind of client to do the parsing of the tags.
> Why use clients? Let the mud do the parsing instead of sending secret
The mud isn't going to send any secret info back down the socket. Who
on earth would be stupid enough to do that? (Don't answer that ;)).
> info to a hackable client. This would of course increase the workload
> on the server, but I think this if preferable to forcing players to use
You use a telnet client as it is, which parses loads of option
negotiation for you.
> No, let the server parse, the clienthackers rest and Telnet reign
> supreme :)
Sorry, what would the server parse? What are you actually talking about?
Mk
http://cyburbia.net.au/~martin/
http://cyburbia.net.au/~martin/mudtree.html
Nathan F. Yospe
s01...@discgate.wright.edu wrote:
:This example is good, don't misunderstand me there. But, I think
:this is still too specific to be of any use. Well, that and I'd
:like to see a few differences ...
The problem is that every person has their own system as a bias toward
what a mud has in it. The above example was rather strange, really.. a
lot of info that should have been resolved by the server, not the client.
:I would prefer the beginning and ending of the 'packet' be delimited
:by a special token, instead of, for example, <ROOMDESC>.
:I'll just use packet for lack of a better word ...
:
:<PACKET ROOMDESC>
:...
:</PACKET>
:
:Thus, if the client gets in one blurb a bunch of these 'packets'
:it would have a better means to distinguish them. Beyond this
:little nitpick I like the system and I think it would be very
:easy to implement on most muds.
I dunno about roomdescs as packets... guess so. I posted earler with the
idea of packages: a sprite support package, a sound package, a vectorized
polygon package, etc.
:After this, I think a common set of tokens be in the protocol.
:These would be the things that have the most in common amongst
:all the types of muds. Then, the mud itself can use its own
:tags if any vary from the 'standard' ones. The standard tags
:being anything in common in any of the mud families (DIKU, LP
:and all others). These are things in common with the mud type
:itself, not *all* muds. So, there are some standard things
:like maybe 'health' and then there are things that would be
:specific to LP's or some other type of mud.
Health sounds pretty damned specific to me. LPs and Dikus only, I would
think. Certainly not in my own system, which only tells a player of the
condition of his/her character in terms of the pain and the dizzyness of
blood loss, feelings of weakness, etc. And certainly not in most tiny
family muds.
:Thus, it is important for the *client* to be generalized, not
:the mud. The client should, for example, allow its user to
:direct various 'packets' to certain windows (or equivalent) then
:to allow its user to further modify the packet by the tags
:inside that packet (reordering them, deleting some, other
:modifications like color, sound ...).
OK... so... a windows package, a sprites package, a text package, a sound
package, a polygons package... any others? We might actually have a basis
for a good project here.
:including ignoring them completely. Furthermore, the client
:itself should then be able to work on as many different
:types of muds as possible. Only then would I even consider
:this to be a standard. If the means to accomplish it, as I
:have outlined here, doesn't accomplish this then some new
:method needs to be thought up.
Agreed. We need to come up with a set of things that are useful tools
for muds, not common factors in muds. Rather than something like health,
or hitpoints, or whatever, make something like <table>, which might
place text into a table for display, or bargraph, piechart, graphic,
etc. Include a set of color management tags that can be applied to
anything, perhaps. The point is that any working protocol will not be
based on a preconcieved notion of a "mud", but instead on a concept of
assembled units of tools that can be displayed. Include a package of
graph types and display tools... perhaps tables could be used to
display stats, and so forth.
:Adding 'links' in the text (which I think is the purpose of
:hyper text, am I wrong ?) should be fairly easy. For example,
:clicking on an 'exit' with your mouse (or highliting it and
:hitting enter ... whatever) should take you in that direction,
:if it were a 'link'. Sound and images could all be done in
:the same manner. It should be left up to the client and the
:user to specify whether or not they want to play sounds or
:play specific sounds (or images, etc). I suppose there should
:be a different tag to distinguish just an effect sound, like
:a sword clash, between a background sound, like music.
I like the idea of being able to imbed one set of text into anoter...
IE, having a table, click on that, imbeded text sends back across the
line a request for the table's description. Click on a door, and perhaps
imbeded text may allow a menu, including open, describe, approach, etc.
The best part is, most of this is not even limited to text or graphics.
If there is a sprite support protocol active, the table might be in a
window that has a room layout with the table being a picture. Click it
and zoom in for detail. Likewise with polygon support. Background sounds
could be tagged persistant, or repeating, or some such, and effect sounds
might be activated by an inline tag saying play sound "<mudname>/<number>",
where the mudname is always assumed to be this particular mud, and the
implementation determines how sounds are stored, cached, whatever.
:The things mentioned like <* LIGHT="10"> ... the LIGHT is too
:specific to be in the protocol. SIGHT, HEAR and SMELL are
:all very good though. That's just another nitpick. I think
:the example was only given to demonstrate the power, not
:become the actual protocol ... I assume.
The things described are great for use internally by a mud, but have
little place in a protocol like this.
:I'm pretty much rambling here, but I just wanted to say
:the kind of system I would go out of my way to support. I
:hope others will agree with me at least on the goals of
:the protocol, not necessarily the protocol itself.
Sounds good.
Nathan F. Yospe
Erik Lavander <eril...@student.luth.se> wrote:
:Exactly.
I'm not sure how I feel about making internal markup the same syntax as
external... but I do use a LOT of internal markup...
:And why stop with tags for room descriptions? Use such tags for items
:(Runes in languages, requiring sufficient skill in that language),
:monsters (Is this an ordinary peaceful monk? Is it a dark elf in
:disguise,
:p'rhaps?) and players (I can't notice any weapon on him - then what is
:this sharp object in my back?). Of course, such tagged descriptions
:could
:get huge, if all different types of perception is considered (infrared,
:magic, hearing, smell, radioactivity, magnetic anomalies, perception
:skill
:ranging from 0-100 an so on. :)
I have markup for just about every range of detection, with every sense,
and every level of perception, as well as situational markup that takes
into account the moods of characters, the attitudes of characters, the
prejudices of characters... not that I force builders to use all of them.
Some things might be hidden from all but the most perceptive (the hidden
type tag became rather pointless on my mud long, long ago.) or even from
all but those with a special sensory advantage (like admins, who can see
things with the admin-only and commentary markups varying by level of the
admin... including a special markup that allows typos to be logged to a
room as a markup visible to the level of imm capable of repairing typos.)
I've found that the increase in description size is mainly due to
increased detail, a good thing, as opposed to a lot of tag space. Then
again, my tags are compact, one to three characters apiece.
Ed Snible
In article <33534E...@student.luth.se>, eril...@student.luth.se says...
>And why stop with tags for room descriptions?
Why stop with tags?
I've been investigating HTML marked MUDs for some time with Pueblo.
(Although Pueblo might as well be proprietery, having something concrete
to work with has given me some thoughts.)
HTML markup is great for some things (like, say, the note system), but
it isn't a general system for all the things I want to do.
I'm thinking of looking into java. I'm thinking of a Corba/COM-like
system where the client has a proxy to each actual object. Some attributes
can be cached on the client side. So, for example, the client side of the
sword might be able to handle a "look" request, but a "get" request would
mean the server would get involved.
Slash
Erik Lavander
Chip Paul wrote:
>
> Erik Lavander wrote:
>
> > Exactly.
> > And why stop with tags for room descriptions? Use such tags for items
> > (Runes in languages, requiring sufficient skill in that language),
> > monsters (Is this an ordinary peaceful monk? Is it a dark elf in
> > disguise,
> > p'rhaps?) and players (I can't notice any weapon on him - then what is
> > this sharp object in my back?). Of course, such tagged descriptions
> > could
> > get huge, if all different types of perception is considered (infrared,
> > magic, hearing, smell, radioactivity, magnetic anomalies, perception
> > skill
> > ranging from 0-100 an so on. :)
> >
>
> The problem with this is that the skills will need to be known to
> the client, which presents several problems:
Not if the interpretation of player-specific tags is left to the server.
> (1) The client becomes mud-specific
> (2) A clever person can write a client to bypass or fake skills
>
> My client will support things like this, but then again, my client
> is specific to my mudlib, because it has to do necessary tasks
> for tile based graphic rooms.
>
> I like the idea of a generalize markup scheme for muds, but stuff
> like illusions and disguises are better left handled by the server.
Hmm...that's a way to look at it, some tags for the server (secrets &
such),
and another set of tags for a client (graphics, sound, VRML(gulp!)).
EriK
Tatu P Saloranta
esn...@goodnet.com (Ed Snible) writes:
>In article <33534E...@student.luth.se>, eril...@student.luth.se says...
>>And why stop with tags for room descriptions?
>Why stop with tags?
Well, tags would be the general mechanism with which to specify types
of messages; simple yet powerful way to allow client to distinguish
between control data, and normal (typed) text data. So, there might not
be need for any alternate mechanism. However, I'm thinking of tags as
just sort of containers in the text stream; tags could contain active
info as well passive info.
>I've been investigating HTML marked MUDs for some time with Pueblo.
>(Although Pueblo might as well be proprietery, having something concrete
>to work with has given me some thoughts.)
The problem with Pueblo seems to be that there are no good specification
on it... Or is it documented well somewhere? (would be interested to have
a look)
>I'm thinking of looking into java. I'm thinking of a Corba/COM-like
>system where the client has a proxy to each actual object. Some attributes
>can be cached on the client side. So, for example, the client side of the
>sword might be able to handle a "look" request, but a "get" request would
>mean the server would get involved.
One problem is that in some muds (at least on the one I'm building),
descriptions are not static. They are (or can be) affected by dozens of
things; time of day, season, whether player has identified the object etc. etc.
So, sometimes you could cache things like descriptions, sometimes not.
It could be done so that server only sends data to be cached for those items
of which desc doesn't change... As they probably still are majority of all
items.
Caching can be neat at times as it can lower the bandwidth needed, but
at least in the case of passing descs, it can actually lead to increased
bandwidth usage. That is, if you pass lots of information, of which only some
is usually used, you are wasting the bandwidth... If players seldom examine
items, passing descriptions is usually in vain.
Erik Lavander
Abovementioned secret info.
> What are you actually talking about?
Not the same thing as you. :)
I should have been more specific in the internal/external distinction.
EriK
Martin Keegan
>
> The problem with this is that the skills will need to be known to
> the client, which presents several problems:
Which is what we don't want, so we have to start thinking of ways
around this. Either a highly generalised system, or some system
for defining what a mud needs, which will allow the server to tell
the client its requirements, and the client to do what it wants
with the info.
> (2) A clever person can write a client to bypass or fake skills
Look. No-one is going to want to have to use a protocol which trusts
the client! You don't go telling telnet users "secret exit here". Why
should this change?
You can't say: "Here, client. Here's some secret info you're not
to show the human user", because some humans are going to write their
own clients which display this stuff. Hence, don't even think about
doing it in the first place.
Martin Keegan
Erik Lavander wrote:
:)
> >
> > Sorry, what would the server parse?
>
> Abovementioned secret info.
AH yes. Instead of splurging it out over the net as some seemed to
think likely! :)
> > What are you actually talking about?
>
> Not the same thing as you. :)
I see :)
> I should have been more specific in the internal/external distinction.
Ok. I don't really see point of discussing the internal markup
a mud may use, as that'll be server-specific.
Pierre-Antoine Champin
On Wed, 16 Apr 1997, Nathan F. Yospe wrote:
> s01...@discgate.wright.edu wrote:
>
> :The things mentioned like <* LIGHT="10"> ... the LIGHT is too
> :specific to be in the protocol. SIGHT, HEAR and SMELL are
> :all very good though. That's just another nitpick. I think
> :the example was only given to demonstrate the power, not
> :become the actual protocol ... I assume.
>
> The things described are great for use internally by a mud, but have
> little place in a protocol like this.
>
Well, I agree with you about the mud-independent nature of packages,
but that last point seems to me not to be too mud-dependent. I think
in every mud, people are supposed to observe the world through their 5
senses. So that could be interesting to send separate informations to
the client, not to filter depending of eventual blindness or deafness of
the player, but to allow customized presentation.
Filtering should of course be achieved by the server, but actually, I thought
about it in my own mud, put it raises a problem : text description often mixes
senses, and de-mix it would give bad looking descriptions, like :
In this big room, you can see this and that.
The sound of machines is very loud.
There is a smell of oil in the air.
which could be kind of functionnal, but not very aesthetic...
Ideas are welcome ;)
Pierre-Antoine
Martin Keegan
> Hmm...that's a way to look at it, some tags for the server (secrets &
> such),
> and another set of tags for a client (graphics, sound, VRML(gulp!)).
Can we cut internal markup from the discussion? It has little relevance
the the practical issues of external markup, and confuses people into
thinking the server needs to trust the client.
How muds do internal markup, if at all, is hardly needing of
standardisation through a MUD protocol.
Mk
cdk
> It may very well do that. When people are creating FE's,
>however, they should keep in mind that not every MUD/player will
>want or use these new sound protocols. Just something to keep in mind
>(IE, OFF SWITCH).
>
the same feeling is true of web sites - alot of web designers and goers
hear the music once, a few times more then turn it off. MUDs would be
able to more dynamically implement it but many muds especially in the UK
are played by people at school where they are akin to games so sound in
these cases would generally stay turned off.
Sound offers an intriguing addition to muds but they have come this far
based only on their textual roots without the need for sound so while
some people will like having it most will either leave it at very low
volume or just off. To get peoples attention the sound would have to be
complex, envolving and dynamic. Dolby are coming out with new protocols
for PC systems - a pro logic mud would take the step further but even
with this all surrounding sound muds are successful because they force
people to use their imagination, if you subtract from that involvement
then you are in fear of becoming akin to the PC games - graphical muds +
sound = primative pc games essentially. Some people will say that sound
is good, options are good but are people adding things into MUDs now
just because they can. Is it a case of the more features a mud has the
better? Recent trends would seem to indicate that - of course there are
pros and cons to all this but that's my 2c if someone wants to go down
the avenues then so be it ;)
CDK
Nathan F. Yospe
Pierre-Antoine Champin <pcha...@ifhamy.insa-lyon.fr> wrote:
On Wed, 16 Apr 1997, Nathan F. Yospe wrote:
:> s01...@discgate.wright.edu wrote:
:>
:> :The things mentioned like <* LIGHT="10"> ... the LIGHT is too
:> :specific to be in the protocol. SIGHT, HEAR and SMELL are
:> :all very good though. That's just another nitpick. I think
:> :the example was only given to demonstrate the power, not
:> :become the actual protocol ... I assume.
:Well, I agree with you about the mud-independent nature of packages,
:but that last point seems to me not to be too mud-dependent. I think
:in every mud, people are supposed to observe the world through their 5
:senses. So that could be interesting to send separate informations to
:the client, not to filter depending of eventual blindness or deafness of
:the player, but to allow customized presentation.
Ah, I see... that, I suppose, would depend on the mud a great deal,
though. I'll include some samples from Singularity 2 (Physmud++) to
demonstrate effective use of internal filters.
:Filtering should of course be achieved by the server, but actually, I thought
:about it in my own mud, put it raises a problem : text description often mixes
:senses, and de-mix it would give bad looking descriptions, like :
: In this big room, you can see this and that.
: The sound of machines is very loud.
: There is a smell of oil in the air.
:which could be kind of functionnal, but not very aesthetic...
:
:Ideas are welcome ;)
From the area file mindscape.are:
#ROOMS [
> central { // reference name 'mindscape:central'
R Cocooned within the heart of the gray mist~, this single occurance of
clear, open air seems strangely cool... <s1>The faint scent of thick,
dry fog wraps itself around you. </s><h4>A gentle hum fills the space
within the mist. </h><v6>Tiny beads of water drift in and out of the
near weightless center of the space, a rainbow trapped within each
gleaming sphere. </v>
~
// default atmosphere = earth normal
T none // no ground
G .25 // quarter strength gravity
// default temperature = room temp
D -1 mist { // an exit set for all directions to 'mindscape:mist'
L The mist is inpenetrably thick.
~
M As you approach the mist, tendrils seem to reach out for you,
enveloping you in cool dampness. A final step, and it closes behind you.
~
L $n disappears into the mist.
~
E <h2>A faint sucking sound reaches your ears. </h>Something seems to
have entered the mists. <v1>A shape resolves itself to your eyes as $n.</v>
~
}
}
From a test run log:
> look
The flat green plain stretches away into a distant ridge of hills to
your right. Sixty meters to your left, a crop of trees springs up, thick
and forbidingly twisted. The strange, flat grass crunches under your
feet, releasing a pungent scent. Ahead, thirty meters off, a twisting
blue stream makes its slow, twisting way out of the small dark forest.
Sparse clouds drift by overhead.
Something streaks by overhead with a roar. A cluster bomb explodes ten
meters off ahead to your right! A piece of turf flies by, but misses
you.
> run
You start running toward the stream.
> run forest
You turn toward the forest, running as fast as you can. A roaring sound
reaches your ears. The forest is thirty meters away. Something roars by
overhead, leaving the impression of a silver streak in your eyes. A
whistling sound reaches your ears. An impulse makes you dodge left, and
a reddish object streaks by your right ear. The missile starts to climb,
but impacts into the forest. You keep running. The forest is ten meters
away. You dodge as branch as you reach the edge of the forest. You stop,
winded, to catch your breath. You are just within the edge of a small,
gnarled forest. Ahead and to each side, crooked black branches tangle
together, making it impossible to pass without considerable effort.
Mushrooms grow out of the mulch and rot at your feet, and there is a
damp smell to the air. The sun filters through the treetops, almost
entirely gone by the time it reaches you.
> look plain
You turn around and stare out through the edge of the forest. The plain
stretches out into the distance. Far ahead, the flat green plain
stretches away into a distant ridge of hills. Thirty meters ahead and to
the left, a twisting blue stream makes its slow, twisting way out of the
small dark forest. Far off to the right, a fence surrounds a complex of
buildings.
> hold rifle
You pull your plasma rifle out of the leather holster across your back
and cradle it in your arms.
> reload rifle
The current bolt has a full charge. You don't need to reload.
> hold grenade
Shifting your plasma rifle into one hand, you detatch a sonic grenade
from the strap across your chest and prime it.
A pack of about twelve Logran drones is approaching from the direction
of the complex of buildings. They are about 300 meters away.
> focus logran
You adjust your optical cybernetics to focus on the pack of Logran
drones. There are fourteen of them. Magnification is at x300. The pack
is led by a class three hunter. The Logran drones are carrying laser
rods. The Logran hunter c3 is carrying a rail cannon. They are heading
in your direction. They are about 250 meters away.
. . .
Imbedment here is inherent in every sensory impulse, as well as in
positioning, quantity, and noticability of scenery. The game tracks
your character's mood state, and what you notice is dependent on how
calm, afraid, paniced, paranoid, etc. you are. There are tags that
relate to this, though none are used in the mindscape area yet.
Matthew Julius
Ed Snible wrote:
>
> I've been investigating HTML marked MUDs for some time with Pueblo.
> (Although Pueblo might as well be proprietery, having something concrete
> to work with has given me some thoughts.)
>
> HTML markup is great for some things (like, say, the note system), but
> it isn't a general system for all the things I want to do.
>
> I'm thinking of looking into java. I'm thinking of a Corba/COM-like
> system where the client has a proxy to each actual object. Some attributes
> can be cached on the client side. So, for example, the client side of the
> sword might be able to handle a "look" request, but a "get" request would
> mean the server would get involved.
This sounds to me like it has a specific kind of mud server in
mind. Which is exactly what this protocol should avoid.
If I'm not mistaken, it's suggested that various aspects of an
object like short and long descriptions (at a minimum) be sent to
the client when the object is first encountered ?
This solves nothing, and even introduces some new problems.
I know at least an LP type mud has the potential to have dynamic
descriptions for the look or examine commands. Furthermore, various
aspects of the game may depend on knowing when a player performs
something, or does something. Just as an example, the player
examines the mysterious green bubble, breaking it in the process
which in turn emits a toxic gas that kills them. You can either
send the 'code' to do this to the client, or you can inform the
client to call back the server with any look or examine command.
If you start including things beyond just the description then
you introduce even fishier scenarios. All told, the server is
sending gobbles of data to the client for no noticeable gain in
the server's performance or the client's performance.
Next thing is that after the first examination of an object the
player is not likely to need to examine it again. Then it needs
to be questioned that if the data is not likely going to be used
then why waste bandwidth sending it ?
This does not take into account at all any time where the data is
not dynamic, but is changed in the course of gameplay. The server
must then inform the client of the change--data which, as described
above, may never even be used by the player.
All of these are quite likely in an LP.
I cannot say for sure of other servers but I have the impression
that one or more of the above cases holds for almost all of the
various mud servers.
Though, with a room (or environment), the data is much more likely
to be used by the player. But, the room case has already been
discussed in this thread. Syntactic candy aside, I think some
very positive looking things have been said for rooms so far. The
manipulation of objects is another story entirely and I think at
the moment it's a dodgy topic in this thread. The solution given
above may be good for a single mud/client game but does not work
well as a community wide mud standard, I don't think.
I don't think this layer of depth is of much use. And, in my
opinion, it violates one of the primary goals of the protocol
which is to keep it simple for the administrator/builder.
Ed Snible
In article <3366FA...@discgate.wright.eduX>,
Xs01...@discgate.wright.eduX says...
>
>If I'm not mistaken, it's suggested that various aspects of an
>object like short and long descriptions (at a minimum) be sent to
>the client when the object is first encountered ?
>
>This solves nothing, and even introduces some new problems.
>I know at least an LP type mud has the potential to have dynamic
>descriptions for the look or examine commands. Furthermore, various
>aspects of the game may depend on knowing when a player performs
>something, or does something. Just as an example, the player
>examines the mysterious green bubble, breaking it in the process
>which in turn emits a toxic gas that kills them. You can either
>send the 'code' to do this to the client, or you can inform the
>client to call back the server with any look or examine command.
>If you start including things beyond just the description then
>you introduce even fishier scenarios. All told, the server is
>sending gobbles of data to the client for no noticeable gain in
>the server's performance or the client's performance.
This seems like a good point, but I was wondering if it is actually
not a good point. That is what I am going to try to find out.
My idea is to have object be represented by abstract Java interfaces.
For the vast majority of objects, I'm thinking that the client side
half of the object will hold things like the long description, and
a "look" will just return that description from the client side half.
For something like your green bubble, the client side half would just
proxy the "look" to the server, where something would happen.
You are definitely correct that this will greatly increase network
traffic. What I wish to find out is if there will be any benifits
to this in terms of a more interesting game. One benefit is that it
will be possible to represent the data in different ways, and it will
be easier to implement bots.
Ed