MUD Design - Some Thoughts
Christopher D. Granz
Here are some features that I have implemented in Sapphire which most
other MUDs seem to lack but in my opinion can help the atmosphere of
a MUD quite a bit. I'd be interested in everyone's comments on these
subjects.
Quest vs. Combat Oriented
-------------------------
In the development of Sapphire I've been putting much work into the
scripting langauge for NPCs/objects/rooms (not to be confused with
Emerald, my lower level langauge for creating spells/skills.) Being
a player myself once, I found that it would get very boring after
awhile of just killing monster after monster in the persuet of
making it to the hero level of the MUD. This is the reason I am
attemping to make Sapphire more quest oriented and less combat
oriented. Combat will still be possible (whenever I get around to
writting the combat system,) but the rewards for mindless killing
of monsters will be far less then those of completing quests.
Costom Exits
------------
The way exits are setup on many MUDs (north, south, east, etc.) I
have seen are very unrealistic and can not effectively represent
exits that would exist in the real world. To better get around
this problem I have removed fixed exits from Sapphire and made it
up to the builder what to call exits. Builders can name exits
anything they like (including `north', `south', `east', etc. if
they want.) To move around with this new exit system players use
`go <exit name>'. So for example a builder may build a room that
is outside of a house and create an exit called `in house' so to
enter the house players may type `go in house' (or use the `enter'
command which is an alias for `go in', thus typing `enter house'.)
These type of exits also discourage speed walking and require the
players to actaully read the room descriptions.
Player Introduction
-------------------
I never liked how on most MUDs players either automaticly know
everyone elses name when they meet them in a room or always see
the other players as things such as `A tall dark elf with green
eyes'. To deal with this on Sapphire I have designed a system
where players see other players as a generated description of
there race, hair color, and eye color until they are introduced
to each other via the `introduce' command. Once a player is
introduced to another player that other player always knows
their name and may refer to them using it (this is done by
writting a list of known players to the pfile.)
Correct Grammar
---------------
In my opinion it always seemed messy how on most MUDs words
like `a' and `the' were always part of the short description.
On Sapphire I have changed this so words such as `a' and `the'
are prefixed to short descriptions by the game depending on the
current conditions rather then by the builder when the area is
built. Sapphire currectly prefixes `the' to an NPCs short
description if you are fighting only one of them and `a' if you
are fighting more then one, for example. The same type of
grammar correction is done for objects as well. Of course there
is a flag that can be set on NPCs/objects that disables the
prepending of `a'/`the' for NPCs/objects that have names (you
don't want `a'/`the' being prepended to a sword with the short
description `Excaliber'.)
Tatt
--
"We will pay the price, but we will not count the cost" -- RUSH
Christopher D. Granz
PS - Please note that not all of these features are present in the
v0.3 release of Sapphire because I have added some of them recently.
They, and others, will be in the v0.4 release.
Nathan F. Yospe
In article <33306D...@newl.com>, qu...@newl.com wrote:
:Here are some features that I have implemented in Sapphire which most
:other MUDs seem to lack but in my opinion can help the atmosphere of
:a MUD quite a bit. I'd be interested in everyone's comments on these
:subjects.
OK, first off, I grabbed a copy of Sapphire 0.3 to look at, just out of
curiosity. Sorry that my own base is not available for inspection at the
time... I am facing a firewall hazard on one machine, and a bandwidth
restriction on the other, and would prefer, in any case, that my code
remain under wraps until Physmud++ v.5 1.0 is complete and functional.
(Yeah, I did say v.5. I'm a perfectionist, and have scrapped the last four
versions.) In any case, my responses to your points:
:Quest vs. Combat Oriented (Sapphire)
:-------------------------
:In the development of Sapphire I've been putting much work into the
:scripting langauge for NPCs/objects/rooms (not to be confused with
:Emerald, my lower level langauge for creating spells/skills.)
I found your scripting language (at least as of 0.3) extremely confusing.
Not sure what it is capable of, and there was not much in the way of
commentary on examples. I did like its applicability, though. Having an
internal language that can be applied to most objects is nice. Emerald
looked like nothing so much as a confused version of assembler, but for
the wierdest machine I've ever seen. Where did you dig up that language
you based it on? Again, however, the utility of having a language
applicable to new skills/spells is nice.
:Being
:a player myself once, I found that it would get very boring after
:awhile of just killing monster after monster in the persuit of
:making it to the hero level of the MUD.
*grin* Strongly agreed.
:This is the reason I am
:attemping to make Sapphire more quest oriented and less combat
:oriented. Combat will still be possible (whenever I get around to
:writting the combat system,) but the rewards for mindless killing
:of monsters will be far less then those of completing quests.
A nice way of doing things... I'll add my own comments to these things now:
Quest vs. Combat Oriented (Physmud++)
-------------------------
Physmud++ comes equipt with something a friend has dubbed PIPCODE. PIPCODE
is an internal partial compile language, and the acronym is something like
Physmud Internal Partial Compile Object Design Engine. (This same friend
has also given me Network Emulated Reality Driver(threaded,
multiplatform), Environmental Nuance And Balance/Localized Event State,
and a couple others)
In any case, pip is an internal language, object oriented, that does a
partial preinterpretation, creating functions as event pointers...
resulting in much faster, somewhat smaller executable code. Think of it as
a JIT. The language is simple enough to be used to program quests, etc,
and powerful enough to program skills, item types (which are far more
sophisticated than the long value[5] system employed by Mercs) and a
number of other things. There is also another language, which I call
reflexscript (I named it, not my friend, so no acronym) that is actually
also partial compile, and used for reactions to events for your Character.
It negates the advantages of client based scripts. Both of these together
provide the means for quest oriented areas... the death and reincarnation
system provides the motive for design of high quality, mentally
challenging areas with sequential design to make them once per Character
things. I'll explain briefly.
A typical player starts with 60 mortality points. Mortality points are a
sort of currency. The breakdown is as follows:
To Purchase: To Earn:
First Character - free Exam Passed - 10*(difficulty rating) mp
Second Character - 2 mp Area Building - size*(quality rating) mp
Third+ Character - 4 mp Quest Scripts - 10*(quality rating) mp
Revive Character - 5 mp
Creation, 1 room - 1 mp
10 rooms - 5 mp
Obviously, the best builders get the most extensions on life (that, and
the people who excel at multiple choice physics exams) Quality rating is
based partly on how well the area can be played first time by reflexscript
only Characters. The better the reflexscript that can crack the area, the
higher the rating. The area must pass the reality test as well, and the
literary test, and so forth...
:Custom Exits
:------------
:The way exits are setup on many MUDs (north, south, east, etc.) I
:have seen are very unrealistic and can not effectively represent
:exits that would exist in the real world. To better get around
:this problem I have removed fixed exits from Sapphire and made it
:up to the builder what to call exits. Builders can name exits
:anything they like (including `north', `south', `east', etc. if
:they want.)
I noticed that n s e w ne se nw sw u d were still present in 0.3... I take
it this has been changed?
:To move around with this new exit system players use
:`go <exit name>'. So for example a builder may build a room that
:is outside of a house and create an exit called `in house' so to
:enter the house players may type `go in house' (or use the `enter'
:command which is an alias for `go in', thus typing `enter house'.)
:These type of exits also discourage speed walking and require the
:players to actaully read the room descriptions.
Yeah, but can they type "run into the house and slam the door"? Or, for
those who have no time for style when being pursued by a pack of rabid
wolverines, "run house\r" "slam door\r"? *grin* I'll admit, though, its a
good start.
At the moment, I only have one set of recognized exit names. If an exit is
named while being constructed any number from 0 to 25, it will be
described relative to the player, in a cubical ref frame (There is a red
door in the barn in front of you and just off behind you to the left, a
path has been worn into the meadow grass. The meadow stretches off to the
left, and a cornfield rises to your right.) with a degree of literary
randomization to provide variety. I allow any other exit name you could
think of, but the other exits must have positions defined in the room's
coordinate frame, and will be accessable by moving in their direction,
more often than not. Of course, some Exits are defined as Etherial
(location -1) and others as at specific Coordinates (-2 followed by the
xyz location) Etherial Exits can only be entered by execution of a
Program, because the behavior of a Character entering an Etherial Exit is
undefined. Therefore, the trigger for an Etherial Exit might be "jack into
socket"... which might register for the nearby cybersocket... thereby
creating a new Character object in the cyberspace Area, leaving the
Player's regular Character in a Switched state. Of course, I am using an
extremely complex system...
:Player Introduction
:-------------------
:I never liked how on most MUDs players either automaticly know
:everyone elses name when they meet them in a room or always see
:the other players as things such as `A tall dark elf with green
:eyes'.
There are Muds that _never_ show a Character by name?
:To deal with this on Sapphire I have designed a system
:where players see other players as a generated description of
:there race, hair color, and eye color until they are introduced
:to each other via the `introduce' command. Once a player is
:introduced to another player that other player always knows
:their name and may refer to them using it (this is done by
:writting a list of known players to the pfile.)
Does this work for NPCs as well? That might be an interesting concept to
play around with (See J C Lawrance's posts about 8 months ago relating to
this) but it has never struck me as economical unless you were also prone
to _forgetting_ the names as you ran low on name storage. Associate a
value of your familiarity, and decriment all values over time,
incrementing them every time you are reexposed to a Player/Character...
maybe leave an interm state of "I know this guy", where the name might or
might not occur to you.
A russet feathered tre'laeca with banded wings is standing behind
Gragh*khan. Shhe looks strangely familiar. The tre'laeca says, "Hey, Fred!
Long time no see!". Shelae'cesh! Hir name is Shelae'cesh!. Shelae smiles
at you, hir stiff beak drawing into a strangely human expression. "C'mon,
man! We fought together at the Doomhold uprising!", shhe says.
> 'Yeah, I remember. I didn't recognize you for a second.
You say, "Yeah, I remember. I didn't recognize you for a second."
:Correct Grammar
:---------------
:In my opinion it always seemed messy how on most MUDs words
:like `a' and `the' were always part of the short description.
:On Sapphire I have changed this so words such as `a' and `the'
:are prefixed to short descriptions by the game depending on the
:current conditions rather then by the builder when the area is
:built. Sapphire currectly prefixes `the' to an NPCs short
:description if you are fighting only one of them and `a' if you
:are fighting more then one, for example. The same type of
:grammar correction is done for objects as well. Of course there
:is a flag that can be set on NPCs/objects that disables the
:prepending of `a'/`the' for NPCs/objects that have names (you
:don't want `a'/`the' being prepended to a sword with the short
:description `Excaliber'.)
Hmmmm. This I've never been bothered by... I do have an autoreplace key
for a/an/the, however. Adding *a to the short description produces an
effect similar, I'm sure, to what you have. I do have a lot of other
features to give the mud grammer a more booklike feel... I think I have
written the ultimate "choose your own adventure" story, in a sense.
--
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!!
Jon A. Lambert
Christopher D. Granz <qu...@newl.com> wrote in article <33306D...@newl.com>...
> Here are some features that I have implemented in Sapphire which most
> other MUDs seem to lack but in my opinion can help the atmosphere of
> a MUD quite a bit. I'd be interested in everyone's comments on these
> subjects.
>
>
> -------------------------
This is one of many solutions. It depends on the type of game you
prefer. I don't see questing as an end-all solution to my goals. I wish
to increase role-playing. Questing could be one aspect of that.
>
> Custom Exits
> ------------
A very good idea. This would increase builder flexibility and allow
more creativity. I've seen LPmuds that implement this as well as
a couple of modified Dikus. I think this is fairly standard on MOOs/Mushes.
>
> Player Introduction
> -------------------
An even better idea. I like this one a lot. It adds a good dose of
realism and would seem to encourage player interaction.
>
>
> Correct Grammar
> ---------------
This is also a very nice feature.
Emerald? Is this the same stack-based compiler that may be integrated
into the Mud++ project?
Christopher D. Granz
Jon A. Lambert wrote:
>
> > Quest vs. Combat Oriented
> > -------------------------
> I agree with you statement of the problem.
> This is one of many solutions. It depends on the type of game you
> prefer. I don't see questing as an end-all solution to my goals. I wish
> to increase role-playing. Questing could be one aspect of that.
I too wish to increase role-playing and realism in my MUD (Sapphire.)
Besides this, and the things i discribe below, what would you say are
also useful things in adding to role-playing?
> > Custom Exits
> > ------------
> A very good idea. This would increase builder flexibility and allow
> more creativity. I've seen LPmuds that implement this as well as
> a couple of modified Dikus. I think this is fairly standard on MOOs/Mushes.
Yeah, I knew this was rather standard on MOOs/MUSHs and I find it very
appealing :)
> > Player Introduction
> > -------------------
> An even better idea. I like this one a lot. It adds a good dose of
> realism and would seem to encourage player interaction.
The only reason I can think of that this *hasn't* been done before is
because
of disk space (pfiles grow in size a bit with this type of system) but I
do
not think disk space is as big of an issue as it once was.
> Emerald? Is this the same stack-based compiler that may be integrated
> into the Mud++ project?
Yes. I wrote the byte-code interpreter about six monthes ago as part of
Sapphire and then ported it to MUD++ (although I don't think it was ever
included in the public release because the compiler wasn't finished.)
Version 0.3 of Sapphire has the interpreter included with it and has the
yacc grammer for the Emerald langauge (very C like) but does not have a
compiler. I plan to work on the compiler after v0.4 and package it with
v0.5.
Thanks for the comments,
Alberto Barsella
Hi,
"Christopher D. Granz" <qu...@newl.com> writes:
[..........]
> I never liked how on most MUDs players either automaticly know
> everyone elses name when they meet them in a room or always see
> the other players as things such as `A tall dark elf with green
> eyes'. To deal with this on Sapphire I have designed a system
> where players see other players as a generated description of
> there race, hair color, and eye color until they are introduced
> to each other via the `introduce' command. Once a player is
> introduced to another player that other player always knows
> their name and may refer to them using it (this is done by
> writting a list of known players to the pfile.)
Is the player able to recognize someone who was introduced to him
always or not?
I mean: after the smiling high elf with long golden hair that you know
as "Elesfin" gets hit by a point-blank firestrike he will probably look
like a nervous tall bald guy with scorched skin. Do you recognize him
or not?
Is it possible to "appear" as another player through disguise (i.e. a
skill able to change some minor - but important for the identification
- characteristic)?
I ask because I've been thinking of a solution but it would be DAMN
CPU expensive.....
Alberto
Tatu P Saloranta
"Christopher D. Granz" <qu...@newl.com> writes:
>Here are some features that I have implemented in Sapphire which most
>other MUDs seem to lack but in my opinion can help the atmosphere of
>a MUD quite a bit. I'd be interested in everyone's comments on these
>subjects.
>Quest vs. Combat Oriented
>-------------------------
>Costom Exits
>------------
>Player Introduction
>-------------------
>Correct Grammar
>---------------
<description of a system to handle articles correctly removed>
This might be quite non-trivial to do, actually... But good luck
it. Is a nice addition, naturally.
It's interesting to note that:
(all LPmuds == all the LP-muds I've seen)
- All LP-muds allow use of "non-standard" exits.
- Probably all LP-muds have quests, and many are heavily quest-oriented.
- Player introduction is implemented in many LP-muds, I guess it was first
done in Genesis (and in CD-lib), but other muds have it too... And
it was one of the first things I added to the mudlib I wrote (from the
scratch). Not a very difficult thing to do; the problem (at least for
LP-muds) is probably how to make it efficient (both in use of
memory/disk space and overall speed).
So, just wanted to say that I agree in that the things you listed are
"nice to have", and that they are widely used as is, at least in
LP-world. Introduction is one thing some people don't like, however;
some socially oriented mudders probably don't like it. But it can add
to atmosphere, so I myself like the idea.
--
Tatu Saloranta, aka Doomdark.
doom...@cc.hut.fi
Christopher D. Granz
> > everyone elses name when they meet them in a room or always see
> > the other players as things such as `A tall dark elf with green
> > eyes'. To deal with this on Sapphire I have designed a system
> > where players see other players as a generated description of
> > there race, hair color, and eye color until they are introduced
> > to each other via the `introduce' command. Once a player is
> > introduced to another player that other player always knows
> > their name and may refer to them using it (this is done by
> > writting a list of known players to the pfile.)
>
> Is the player able to recognize someone who was introduced to him
> always or not?
> I mean: after the smiling high elf with long golden hair that you know
> as "Elesfin" gets hit by a point-blank firestrike he will probably look
> like a nervous tall bald guy with scorched skin. Do you recognize him
> or not?
In my opinion a person would need to be *very* disfigured to not be
recongized by someone who knew them before.
> Is it possible to "appear" as another player through disguise (i.e. a
> skill able to change some minor - but important for the identification
> - characteristic)?
I like this idea. I will probably implement a spell/skill to do this :)
Another thing I plan to do with the introduction system on Sapphire is
setup it up so if you don't interact with someone you know in someway
for more then about a month or two you will forget thier name and need
to be introduced if you meet again.
Thanks,
Christopher D. Granz
Nathan F. Yospe wrote:
>
> I found your scripting language (at least as of 0.3) extremely confusing.
> Not sure what it is capable of, and there was not much in the way of
> commentary on examples. I did like its applicability, though. Having an
> internal language that can be applied to most objects is nice.
I've been focusing more on code development then documents lately so I
understand why it would be hard to understand without documents. Here's
a basic break down of how the scripting langauge for NPCs/objects/rooms
from v0.4 works (at the moment):
program /* start of the program block for this NPC/object/room */
{
/* variable declarations are only allowed at top level
*
* variable types are:
* number - a number (signed long)
* string - a string (signed char *)
* character_pointer - a pointer to a character (struct) in
the game
* object_pointer - a pointer to an object (struct) in
the game
* room_pointer - a pointer to a room (struct) in the
game
*/
character_pointer newbie;
/*
* the keyword `uses' followed by the name of a "quest data struct"
(defined in a
* different file) can be used to enable the use of a group of
variables
* there is also only ever one version of each type of quest data so
it allows
* for different NPCs/objects/rooms to communicate with each other
by one setting
* a variable and then another script checking it etc, this is
useful when
* writting automated quests
*/
/*
* triggers are defined with the format:
*
* trigger <trigger name (NOT type)> <"enabled"|"disabled"; initial
state>
* <trigger type 1> ( <trigger args> )
* <trigger type 2> ( <trigger args> )
* <...etc...> ( <trigger args> )
* {
* <code block>
* }
*/
trigger start enabled
created ( )
{
disable( all );
wait( 2 );
game_cmd( ( "tell " + actor.name )
+ " Welcome, my friend. Would you like help getting started?"
);
enable( all );
newbie = actor;
}
trigger help_1 enabled
tell ( infix "yes" )
emote ( infix "nods at you" )
{
if ( actor != newbie )
end( );
disable( all );
if ( is_npc( actor ) > 0 )
{
wait( 2 );
game_cmd( ( "tell " + actor.name )
+ " NPCs should not need help." );
}
elsif ( is_guest( actor ) > 0 )
{
wait( 2 );
game_cmd( ( "tell " + actor.name )
+ " I have no time to waste on the likes of you." );
}
elsif ( actor.level > 2 )
{
wait( 2 );
game_cmd( ( "tell " + actor.name )
+ " I don't think you need my help." );
}
else
{
wait( 3 );
game_cmd( ( "tell " + actor.name ) + " Okay, first of all, "
+ "on Sapphire all system-type commands (save, quit, etc)
"
+ "start with a `$'. Use `$commands' to see a list of all
"
+ "available commands, both system and non-system." );
wait( 2 );
game_cmd( ( "tell " + actor.name ) + " Tell me when you are
"
+ "ready for your next lesson." );
}
enable( all );
}
trigger help_2 enabled
tell ( infix "next" )
emote ( infix "nods at you" )
{
if ( actor != newbie )
end( );
disable( all );
wait( 2 );
game_cmd( ( "tell " + newbie.name ) + " You're all done!" );
enable( all );
newbie = null_character;
}
};
> Emerald looked like nothing so much as a confused version of assembler,
> but for the wierdest machine I've ever seen. Where did you dig up that
> language you based it on? Again, however, the utility of having a language
> applicable to new skills/spells is nice.
Hrm, Emerald is not assembler in any way. What you were looking at in
v0.3 was the byte-code interpreter. The interpreter is merely what runs
the compiled code. The instruction set for emerald is actaully very
similiar to the Java intruction set in many ways. The compiler (emc)
will
be included in v0.5 of Sapphire and compiles Emerald code (very C like)
into the byte-codes which are then run by the interpreter in the server.
Emerald is much faster and more flexible then the scripting langauge
used
for NPCs/objects/rooms which is why it is used for lower level code. In
later versions of Sapphire I will likely take this a step further and
make it possible for the Emerald byte-codes to be compiled in to actaul
machine code.
> Physmud++ comes equipt with something a friend has dubbed PIPCODE. PIPCODE
> is an internal partial compile language, and the acronym is something like
> Physmud Internal Partial Compile Object Design Engine. (This same friend
> has also given me Network Emulated Reality Driver(threaded,
> multiplatform), Environmental Nuance And Balance/Localized Event State,
> and a couple others)
> In any case, pip is an internal language, object oriented, that does a
> partial preinterpretation, creating functions as event pointers...
> resulting in much faster, somewhat smaller executable code.
This is what emerald does except that it is completely compiled into
byte-codes before hand save for function/global variable names that are
left in by the compiler and then linked when the emerald object file is
loaded by the interpreter.
> Think of it as a JIT.
I believe JIT (Just In Time) compiling commonly means that a langauge is
compiled into byte-codes by the compiler and then compiled into actaul
machine code by the interpreter. Unless I read the above wrong, your
langauge does not compile down to the machine code level (thus it is not
really JIT) :)
> :Custom Exits
> :------------
>
> I noticed that n s e w ne se nw sw u d were still present in 0.3... I take
> it this has been changed?
Yes, this has been changed since 0.3 and should be in version 0.4.
> Yeah, but can they type "run into the house and slam the door"? Or, for
> those who have no time for style when being pursued by a pack of rabid
> wolverines, "run house\r" "slam door\r"? *grin* I'll admit, though, its a
> good start.
I see no real need to have the game parse strings such as
"run into the house and slam the door"; it only would use up more CPU
time
and most players would want to type it anyways. "Run house" and "slam
door"
type commands I may implement later after I get the "bigger" issues
worked
out ;)
> :Player Introduction
> :-------------------
>
> There are Muds that _never_ show a Character by name?
*nod* Well, I mean, they never show the character name when you
`look', for example. Usually they would show their real name
when you tell them something or they tell you something.
> Does this work for NPCs as well? That might be an interesting concept to
> play around with (See J C Lawrance's posts about 8 months ago relating to
> this) but it has never struck me as economical unless you were also prone
> to _forgetting_ the names as you ran low on name storage. Associate a
> value of your familiarity, and decriment all values over time,
> incrementing them every time you are reexposed to a Player/Character...
> maybe leave an interm state of "I know this guy", where the name might or
> might not occur to you.
>
> A russet feathered tre'laeca with banded wings is standing behind
> Gragh*khan. Shhe looks strangely familiar. The tre'laeca says, "Hey, Fred!
> Long time no see!". Shelae'cesh! Hir name is Shelae'cesh!. Shelae smiles
> at you, hir stiff beak drawing into a strangely human expression. "C'mon,
> man! We fought together at the Doomhold uprising!", shhe says.
> > 'Yeah, I remember. I didn't recognize you for a second.
> You say, "Yeah, I remember. I didn't recognize you for a second."
I may implement such a system as you explain but not until I finish
the more fundemental aspects of Sapphire :)
Christopher D. Granz
Tatu P Saloranta wrote:
>
> >Correct Grammar
> >---------------
>
> <description of a system to handle articles correctly removed>
>
> This might be quite non-trivial to do, actually... But good luck
> it. Is a nice addition, naturally.
I have already done this (it is in public version 0.3 of Sapphire)
and yes, it was not a trivial thing to code.
> It's interesting to note that:
>
> - Player introduction is implemented in many LP-muds, I guess it was first
> done in Genesis (and in CD-lib), but other muds have it too... And
> it was one of the first things I added to the mudlib I wrote (from the
> scratch). Not a very difficult thing to do; the problem (at least for
> LP-muds) is probably how to make it efficient (both in use of
> memory/disk space and overall speed).
A player introduction system is naturally going to be less efficient and
more memory/disk consuming when written in LPC becuase it's more work on
the machine overall to have to interpret byte-codes rather then running
regular machine code. LPC does give you much flexibility of course,
which
is the reason LP MUDS are so popular ;)
It is rather simple to write an introduction system such as the one I
wrote about ealier but it was something I hadn't seen done before. It
seems I was wrong.
Nathan F. Yospe
In article <3331B0...@newl.com>, qu...@newl.com wrote:
:Nathan F. Yospe wrote:
:> I found your scripting language (at least as of 0.3) extremely confusing.
:> Not sure what it is capable of, and there was not much in the way of
:> commentary on examples. I did like its applicability, though. Having an
:> internal language that can be applied to most objects is nice.
:
:I've been focusing more on code development then documents lately so I
:understand why it would be hard to understand without documents. Here's
:a basic break down of how the scripting langauge for NPCs/objects/rooms
:from v0.4 works (at the moment):
Snipity-Snip!
Hmm... only thing is.. there seems to be no support for new or complex
types of objects. On the other hand, considering the way you wrote the
codebase, that stands to reason... not particularly object oriented, but
hey! A far shot above Diku.
:> Emerald looked like nothing so much as a confused version of assembler,
:Hrm, Emerald is not assembler in any way. What you were looking at in
:v0.3 was the byte-code interpreter. The interpreter is merely what runs
Ah. Well, dur. Byte code quite frequently resembles assembler when written
out into a file. If it is higher level.
:Emerald is much faster and more flexible then the scripting langauge
:used for NPCs/objects/rooms which is why it is used for lower level
code. :In later versions of Sapphire I will likely take this a step
further and
:make it possible for the Emerald byte-codes to be compiled in to actaul
:machine code.
As I described before, all of my codables reduce as much as possible to
lower level code. I mentioned the association of my code with a JIT... I
know what a JIT is... PIPCODE is not precisely a JIT... but it uses
runtime tableing and pointer reduction, which achieves a similar result.
Certainly, by the definition of a certain M$ product under flamage on
another thread, that is JIT compilation... but I digress.
:> Physmud++ comes equipt with something a friend has dubbed PIPCODE. PIPCODE
:> is an internal partial compile language, and the acronym is something like
:This is what emerald does except that it is completely compiled into
:byte-codes before hand save for function/global variable names that are
:left in by the compiler and then linked when the emerald object file is
:loaded by the interpreter.
Ah. Just so... it would take far less time to load than my own, but show
no performance difference after bootup... I kind of prefer to leave mine
as it is, as there is often runtime editing, and the final product, once
OK'd, can be run through a final translater, resulting in its integration
as a C++ class with appropriate member functions and final compilation as
a component of the hardcoded system.
:> Think of it as a JIT.
:
:I believe JIT (Just In Time) compiling commonly means that a langauge is
:compiled into byte-codes by the compiler and then compiled into actaul
:machine code by the interpreter. Unless I read the above wrong, your
:langauge does not compile down to the machine code level (thus it is not
:really JIT) :)
Sorry... what I described above was the bootup process... once it has
completed bootup, the pointers will be linked dynamicly into the local
tables... unfortunately, this might not be true for all machine
architectures... particularly Win32, BSDs, and Linux. The Irix, Solaris,
and Rhapsody wrappers seem to work well enough, though. Of course, whether
I will include this rather shakey partial compile engine in any release
remains to be seen.
:I see no real need to have the game parse strings such as
:"run into the house and slam the door"; it only would use up more CPU
:time and most players would want to type it anyways. "Run house" and "slam
:door" type commands I may implement later after I get the "bigger" issues
:worked out ;)
I guess it was the "run" part of that that bothered me... I've always
hated the integral level of the generic "go" or direction commands... it
has always seemed to me that implementing such a system at an early date
tended to preclude any alternatives in the future. (Incidentally, I do
have a command "go <direction/destination>"... it parses for situational
motives to determine what method to use to "go"... run is popular when
there are rabid wolverines in hot pursuit, and typing "house" _would_
result in the same thing as "run house".... in that situation. Without the
wolverines, it might make you "stroll house", or even, with proper
influences (say, a strong dose of some drug) "skip house" or "dance
house".... of course, if there was another interpretation of "skip house"
possible, it would not occur, as the natural language interpreter would
have already specified skip as a movement oriented interpretation.
Nevertheless, you see where this is going. The point of this? Well, if you
are going to bother with elliminating direction names (a good step, BTW,
and I commend you... I did it like that on the ROM I hacked way back
when...) I had hopes you might go for the bait of an even more
sophisticated approach... that being a natural language parser.
:> There are Muds that _never_ show a Character by name?
:
:*nod* Well, I mean, they never show the character name when you
:`look', for example. Usually they would show their real name
:when you tell them something or they tell you something.
Ugh. OK, I know the type.
:> Does this work for NPCs as well? That might be an interesting concept to
:> play around with (See J C Lawrance's posts about 8 months ago relating to
:> this) but it has never struck me as economical unless you were also prone
:> to _forgetting_ the names as you ran low on name storage. Associate a
:> value of your familiarity, and decriment all values over time,
:> incrementing them every time you are reexposed to a Player/Character...
:> maybe leave an interm state of "I know this guy", where the name might or
:> might not occur to you.
:I may implement such a system as you explain but not until I finish
:the more fundemental aspects of Sapphire :)
*grin* Little problem I have... for me, this sort of thing had better be a
product of the fundamental aspects of Physmud++... otherwise, its by
definition a hack. I don't allow hacks in my code. None. Having a pointer
like Character *replyTo; gives me fits. Big time. (I have a Communication
class instead... It can link itself to any set of objects, Characters,
Players, Items, what have you... the closest thing to a tell is a
Communication class object that has attatched itself to two Characters. It
might then enable the command "reply" to either Character. It could, of
course, be programmed (using the internal programming language) to move
itself freely... say, from one Character as an anchor to whatever
Character the first has designated. Likewise with movement. Moving is not
an instant transfer from room A to room B... there has to be cause and
consequence. Now, for the above intro/naming system, it is my philosophy
that Player controlled Characters are no different from AIs and Comp
controlled Characters. Therefore, it stands to reason that any method
allowing familiarity with an NPC should be identical to a PC... but
storing every NPC with whom a Character has met on a first name basis
would become extremely cumbersome. Therefore, name recognition must decay.
Dead stop decays, by definition, suck. Likewise, lists of these things
suck. Hack, you see. So I create, similar to my channel, an Association
object. Associations are derived from Grouping containers, and implement
content matching decay. Another Character you have met has a certain set
of Association objects defined for you... (actually, you for them) and can
be recognized not only by name, but by other info. This allows a great
deal more depth in my spy game situations, for example. There is more to
this, but it comes down to being a memory object. A Character has a finite
memory (partly to save space for myself, admittedly) and memories tend to
decay. Like I said, this is at a fundamental level, not the level of the
name matching game, but inherent in how all transactions of this type are
made. My goal is a MUD that is integrated from the ground up, consistant,
and free of hacks. And changable on a fundamental level by the changing of
basic natures... IE, change the nature of matter, and the MUD still runs,
but quite differently. Using OO programming helps, of course. This also
explains why, as a few people have asked, I cannot afford _not_ to put
inactive areas' threads to sleep.
Timothy Philip Vernum
"Christopher D. Granz" <qu...@newl.com> writes:
>> > Player Introduction
>> > -------------------
>The only reason I can think of that this *hasn't* been done before is
>because
>of disk space (pfiles grow in size a bit with this type of system) but I
>do
>not think disk space is as big of an issue as it once was.
Actually It has been done before.
If I recall the genesis/CD LP setup has had it for a good while.
But it is pretty rare.
A secondary problem is also that if you really want to implment it realisticly
then it should be possible to introduce yourself with an alias.
So you then have to store not only the people whom we know but also who we
know them as. (and then if oyu have suicides you have the problem that
the new 'Wildcat' may not be the 'Wildcat' i know and the record that I have
been introduced to them is actually incorrect. In which case you need to
give players a unique identifier. Either through a player number, or a ban
on the re-use of names )
But the real problem comes when dealing with the aliases.
Consider if the character named 'Wildcat' has introduced himself to me as
'Blackwolf'
All messages to me that include a name. eg 'Wildcat says: Hi'
need to have 'Blackwolf' substituted in.
And when I want to look at him I type "look at blackwolf" but it needs to
give me wildcat's description.
All these are fairly easy to get around until you get someone that i know as
'Apple' and there are apples in the room.
(this is slightly dependant on your command parsing, but you'll get the drift )
if The real apples are the first three items in the room then
'look at apple' needs to give the description on the fruit
BUT
'look at fourth apple' needs to give the description on the player
It starts getting really tricky when the order of the objects is:
fruit, fruit, player, fruit
Then 'look at third apple' needs to give the player.
But the fact that i know the player as apple is not necessarily expected.
So you need to do something like (LP code but it should seem clear )
present("apple 3", room, this_player() )
needs to call something like:
object present(string name, object environ, object caller )
{
int count , i ;
object *inventory ;
if( sscanf(name, "%s %d", name, count ) != 2 )
count = 1;
inventory = all_inventory( environ ) ;
for( i = 0; i<sizeof( inventory ) ; i++ )
{
if( inventory[i]->id(name, caller) ) count --;
if( !count ) return inventory[i] ;
}
return 0;
}
where the ids that the object responds to are highly dependant upon the
person asking.
The problem can be solved fairly well, but it is more than just a disk-space
question.
All this substuting of aliases back and forth can be fairly slow.
Like the disk-space problem, this is becoming much less important, but for a
while it was a major barrier to get around.
- Tim
Abigail
On Thu, 20 Mar 1997 12:38:11 -0500, Christopher D. Granz wrote in rec.games.mud.admin:
++
++ A player introduction system is naturally going to be less efficient and
++ more memory/disk consuming when written in LPC becuase it's more work on
++ the machine overall to have to interpret byte-codes rather then running
++ regular machine code.
What an utterly meaningless argument. Combat is less efficient and more
memory/disk consuming when written in LPC too. Same for exits and
room description. *Everything* you add uses resources.
For everything you add to the mud you have to make a trade off:
'What does it add to the game' vs 'How much resources does it take'
(and resources are CPU, disk space, disk I/O, develop time,
maintainance).
Note that you have been able to get rid of the overhead of interpret
byte-codes for a couple of years now by using LPC -> C compilers.
Abigail
Abigail
On Thu, 20 Mar 1997 12:47:10 -0500, Christopher D. Granz wrote in rec.games.mud.admin:
++ Alberto Barsella wrote:
++ >
++ > "Christopher D. Granz" <qu...@newl.com> writes:
++ > >
++ > > I never liked how on most MUDs players either automaticly know
++ > > everyone elses name when they meet them in a room or always see
++ > > the other players as things such as `A tall dark elf with green
++ > > eyes'. To deal with this on Sapphire I have designed a system
++ > > where players see other players as a generated description of
++ > > there race, hair color, and eye color until they are introduced
++ > > to each other via the `introduce' command. Once a player is
++ > > introduced to another player that other player always knows
++ > > their name and may refer to them using it (this is done by
++ > > writting a list of known players to the pfile.)
++ >
++ > Is the player able to recognize someone who was introduced to him
++ > always or not?
++ > I mean: after the smiling high elf with long golden hair that you know
++ > as "Elesfin" gets hit by a point-blank firestrike he will probably look
++ > like a nervous tall bald guy with scorched skin. Do you recognize him
++ > or not?
++
++ In my opinion a person would need to be *very* disfigured to not be
++ recongized by someone who knew them before.
Only if you know him well. Not if you just briefly met in a store
2 weeks before. Heck, you might not even remember his name, or think
that any smiling high elf is named 'Elesfin'.
++
++ > Is it possible to "appear" as another player through disguise (i.e. a
++ > skill able to change some minor - but important for the identification
++ > - characteristic)?
++
++ I like this idea. I will probably implement a spell/skill to do this :)
++
++ Another thing I plan to do with the introduction system on Sapphire is
++ setup it up so if you don't interact with someone you know in someway
++ for more then about a month or two you will forget thier name and need
++ to be introduced if you meet again.
Is that realistic? You might not recognise someone you met an hour ago
on the market, while you would never mistake your grandmother for
someone else, even if you haven't seen her in 10 years.
And how do you determine 'interact'? Be in the same room together?
(then you have a nice piece of fastly changing data to keep track off)
Be re-introduced? (Not very realistic if you already know each other)
Abigail
Christopher D. Granz
Abigail wrote:
>
> On Thu, 20 Mar 1997 12:38:11 -0500, Christopher D. Granz wrote in rec.games.mud.admin:
> ++
> ++ A player introduction system is naturally going to be less efficient and
> ++ more memory/disk consuming when written in LPC becuase it's more work on
> ++ the machine overall to have to interpret byte-codes rather then running
> ++ regular machine code.
>
> What an utterly meaningless argument. Combat is less efficient and more
> memory/disk consuming when written in LPC too. Same for exits and
> room description. *Everything* you add uses resources.
>
> For everything you add to the mud you have to make a trade off:
> 'What does it add to the game' vs 'How much resources does it take'
> (and resources are CPU, disk space, disk I/O, develop time,
> maintainance).
>
> Note that you have been able to get rid of the overhead of interpret
> byte-codes for a couple of years now by using LPC -> C compilers.
Talk about meaningless, I fail to see any point you are making by the
above statements. I was not bashing LPC, but rather was merely stating
a fact.
Martin Keegan
Christopher D. Granz wrote:
> Quest vs. Combat Oriented
> attemping to make Sapphire more quest oriented and less combat
> oriented. Combat will still be possible (whenever I get around to
> writting the combat system,) but the rewards for mindless killing
> of monsters will be far less then those of completing quests.
Island was pretty quest-oriented. After you got to level 5 (there were
11 mortal levels), you were required to do a certain number of quests
to reach the next level (score became less and less important).
The effect of this (apart from forcing the implementation of very
good quests to keep people interested) was a sort of unintentional
social engineering - the playerbase had an unusually high percentage
of what Bartle calls "Explorers", as opposed to Killers, and Achievers.
(The hidden advantage of this was the paucity of losers who could
be bothered hanging around and doing the quests, though having the
upper echelons of the mud dominated by persistent, intelligent,
devious, resourceful fanatics was probably not the advantage it was
originally assumed to be)
> Costom Exits
> The way exits are setup on many MUDs (north, south, east, etc.) I
See everyone else's comments about MUSH/Teeny having this stuff.
> Player Introduction
> -------------------
>
> I never liked how on most MUDs players either automaticly know
Is this Chris Lawrence's idea from last year (not a criticism)?
The only problem is probably that players want to know each other's
names (see George Reese's comment about players wanting to do
"tells" across the mud).
> Correct Grammar
> ---------------
>
> In my opinion it always seemed messy how on most MUDs words
> like `a' and `the' were always part of the short description.
> On Sapphire I have changed this so words such as `a' and `the'
> are prefixed to short descriptions by the game depending on the
> current conditions rather then by the builder when the area is
> built. Sapphire currectly prefixes `the' to an NPCs short
> description if you are fighting only one of them and `a' if you
> are fighting more then one, for example. The same type of
> grammar correction is done for objects as well. Of course there
> is a flag that can be set on NPCs/objects that disables the
> prepending of `a'/`the' for NPCs/objects that have names (you
> don't want `a'/`the' being prepended to a sword with the short
> description `Excaliber'.)
At long bloody last! Finally people are admitting that this is a
problem. The first time I logged onto Medievia, I saw something like:
Dalmair's a bag failed to find a buyer at auction.
obviously caused by the article, 'a', being part of the object's name.
Does Sapphire handle mass-nouns like 'cheese' properly?
There is some cheese here.
> get cheese
You pick up the cheese.
(ie, it knows that some nouns are 'some', some 'a', some 'an', a few
'the', and a couple with no article at all (eg 'Excalibur'), and that
most of these words change to 'the' in some contexts).
Mk
--
#!/usr/local/bin/perl
@z=("vahquoY","nq",".liamqw");@s=reverse split'','012';
@l[shift@s]=scalar reverse$z[scalar@s-1]while(@s);
map{print $_."\040"}split"q",join'e',@l; print "\n";
Martin Keegan
Christopher D. Granz wrote:
>
> Tatu P Saloranta wrote:
> >
> > >Correct Grammar
> > >---------------
> >
> > <description of a system to handle articles correctly removed>
> >
> > This might be quite non-trivial to do, actually... But good luck
> > it. Is a nice addition, naturally.
>
> I have already done this (it is in public version 0.3 of Sapphire)
> and yes, it was not a trivial thing to code.
What wasn't trivial to code? Surely giving every object an extra
byte of data saying whether it is {'a','an','some','the',''} "grapes"
and singular or plural, and implementing routines for returning those
five little bits of text is completely trivial.
It is outrageous that I see muds forced to treat armour like swords:
You sell an armour to the shopkeeper for x gp.
just because they don't have any support for basic English grammar.
Or are you talking about distinguishing between 'the' and 'a' when
there are multiple copies of the same entity in the room?
Christopher D. Granz
Martin Keegan wrote:
>
> Christopher D. Granz wrote:
> >
> > Tatu P Saloranta wrote:
> > >
> > > >Correct Grammar
> > > >---------------
> > >
> > > <description of a system to handle articles correctly removed>
> > >
> > > This might be quite non-trivial to do, actually... But good luck
> > > it. Is a nice addition, naturally.
> >
> > I have already done this (it is in public version 0.3 of Sapphire)
> > and yes, it was not a trivial thing to code.
>
> What wasn't trivial to code? Surely giving every object an extra
> byte of data saying whether it is {'a','an','some','the',''} "grapes"
> and singular or plural, and implementing routines for returning those
> five little bits of text is completely trivial.
>
> It is outrageous that I see muds forced to treat armour like swords:
>
> You sell an armour to the shopkeeper for x gp.
>
> just because they don't have any support for basic English grammar.
>
> Or are you talking about distinguishing between 'the' and 'a' when
> there are multiple copies of the same entity in the room?
Yes, I was talking about having it use `the' when there is only one
instance of the object and `a' when there are multiple instances of
the object ;)
Thanks,
mor...@niuhep.physics.niu.edu
>++ > "Christopher D. Granz" <qu...@newl.com> writes:
>++ > > I never liked how on most MUDs players either automaticly know
>++ > > everyone elses name when they meet them in a room or always see
>++ Another thing I plan to do with the introduction system on Sapphire is
>++ setup it up so if you don't interact with someone you know in someway
>++ for more then about a month or two you will forget thier name and need
>++ to be introduced if you meet again.
>
>Is that realistic? You might not recognise someone you met an hour ago
>on the market, while you would never mistake your grandmother for
>someone else, even if you haven't seen her in 10 years.
I would suggest a semi-realistic model using short-term, ?medium term? and
long term memory...
>And how do you determine 'interact'? Be in the same room together?
>(then you have a nice piece of fastly changing data to keep track off)
When you are introduced a counter is setup for that character and
initialized with some positive value. Every time the computer tells
you 'John walks into the room' a tic is added to the counter, and the
"last time seen" clock gets reset.
Every game day a check is made of all the characters you know.
If they have not accumulated enough tics to make it out of short term
memory a certain # of tics is subtracted from the counter
If they have made it into medium term memory then the "last time seen"
is checked and if it were long enough ago (say a month) then either
they drop into short term memory or a certain number of tics is
subtracted from the counter. Here one must be carefull to take into
account the amount of time the character has been active (as opposed
to the amount of time that has gone by for the mud.)
If a character has made it into long term memory then you don't forget.
>Be re-introduced? (Not very realistic if you already know each other)
? The premise is that they don't remember each other. I have certainly
been reintroduced to people in RL.
>Abigail
>
specify the e-mail address below, my reply-to: has anti-spam added to it
Mor...@physics.niu.edu
Real Men change diapers
Christopher D. Granz
Martin Keegan wrote:
>
> Christopher D. Granz wrote:
>
>
> > attemping to make Sapphire more quest oriented and less combat
> > oriented. Combat will still be possible (whenever I get around to
> > writting the combat system,) but the rewards for mindless killing
> > of monsters will be far less then those of completing quests.
>
> Island was pretty quest-oriented. After you got to level 5 (there were
> 11 mortal levels), you were required to do a certain number of quests
> to reach the next level (score became less and less important).
What is Island, I don't think I've heard of that code base before unless
you are refering to the Isles (which was based off of the original DIKU
I believe) ?
> > Player Introduction
> > -------------------
> >
> > I never liked how on most MUDs players either automaticly know
>
> Is this Chris Lawrence's idea from last year (not a criticism)?
Nope, I haven't been keeping up on any of the rec.games.mud.*
newsgroups until recently (since about a month ago.)
> The only problem is probably that players want to know each other's
> names (see George Reese's comment about players wanting to do
> "tells" across the mud).
I realize this but I am aiming to make Sapphire as much Role-Playing
oriented as possible. Then again, I am also not planing to have
global chat or tell channels (I plan to allow communication across
MUD via special items and spells.)
> > Correct Grammar
> > ---------------
>
> At long bloody last! Finally people are admitting that this is a
> problem. The first time I logged onto Medievia, I saw something like:
>
> Dalmair's a bag failed to find a buyer at auction.
>
> obviously caused by the article, 'a', being part of the object's name.
> Does Sapphire handle mass-nouns like 'cheese' properly?
>
> There is some cheese here.
> > get cheese
> You pick up the cheese.
>
> (ie, it knows that some nouns are 'some', some 'a', some 'an', a few
> 'the', and a couple with no article at all (eg 'Excalibur'), and that
> most of these words change to 'the' in some contexts).
Yes, as of v0.4 of Sapphire there will be a flag you can set on objects
for mass-noun exceptions :)
Anthony C.
[introducing yourself deleted]
I had thought about implementing the introduction feature into the mud but
I decided not to because I wouldnt really want to play on a mud that had
it. A mud is a combination game and simulation, and so I am willing to give
up some realism. However, in my mud the structures exist to easily implement
this. Every object, including players, has a unique id. Players/objects
also have names. Currently names cannot be changed and everyone is referred
to by their text name. Also names cannot be used by more than one character.
However the data structure does allow for multiple characters with the same
name, name changing, and introduction. As far as referencing individuals
with the name apple, my game has a gui interface that lets ppl select which
apple they want from a list. The client essentially sends "interact with
object 1" or object 2, which is an index into the server side list. The
server side list has a list of the true ID's, thus removing any ambiguity
of which apple is which. The GUI also splits creatures into different lists
from items so that a player named apple would appear in a different list from
an apple.
--
Anthony Chen
Interactive Games Network
http://ign.cy-net.net
Daniel Koepke
On Fri, 21 Mar 1997, Christopher D. Granz wrote:
> What is Island, I don't think I've heard of that code base before unless
> you are refering to the Isles (which was based off of the original DIKU
> I believe) ?
Island isn't a code base, it's a mud. And TheIsles (NiMUD) was based
on MercMUD, which is, in turn, based on DIKU. Island is original.
--
Daniel Koepke
dko...@california.com
Forgive me father, for I am sin.
Tatu P Saloranta
Martin Keegan <mar...@cam.sri.com> writes:
>Christopher D. Granz wrote:
>>
>> Tatu P Saloranta wrote:
>> >
>> > >Correct Grammar
>> > >---------------
>> >
>> > <description of a system to handle articles correctly removed>
>> >
>> > This might be quite non-trivial to do, actually... But good luck
>> > it. Is a nice addition, naturally.
>>
>> I have already done this (it is in public version 0.3 of Sapphire)
>> and yes, it was not a trivial thing to code.
>What wasn't trivial to code? Surely giving every object an extra
>byte of data saying whether it is {'a','an','some','the',''} "grapes"
>and singular or plural, and implementing routines for returning those
>five little bits of text is completely trivial.
Surely just adding that info is easy enough in itself; but it's just
the first step towards a better system... How to use the correct
articles is a problem in itself, because:
>It is outrageous that I see muds forced to treat armour like swords:
>You sell an armour to the shopkeeper for x gp.
>just because they don't have any support for basic English grammar.
>Or are you talking about distinguishing between 'the' and 'a' when
>there are multiple copies of the same entity in the room?
Depending on who sees the message, choosing a correct argument might
well be somewhat less straightforward. If the player has already referenced
the item, it probably is "the sword" to him/her ("You see a sword here."
-> "examine sword" -> <description> -> "take sword" -> "You take the
sword"). And whether others see it as a sword or the sword... Probably
one has to check if there are other items that "look the same" in the room;
and this can vary between different players; one player might see
3 swords, one could see blessed +2 sword, sword of dragon-slaying and
a plain sword. Also; how about descriptions like "some coins" or "4 bottles".
Easy enough, you could have flags telling the object doesn't use any extra
articles ever; or even check the string. But it also has to be taken care
of somehow. "Some coins" is something you would probably use for
29 coins lying on the ground, before a player has counted them.
Of course, it all depends on how sophisticated (~= complex) system you
have; but I think it's not all that trivial thing to make it work well.
And if you can't make it work well, it's not much better than any other
way to use articles (perhaps always defaulting to "the").
All in all, I hope you can make it work well, just trying to explain
why I think it might be quite difficult. I'd love to see an elegant
way to solve it (efficiently), as it'd probably be one of the things I
would add to the mud I'm developing. =)
Alberto Barsella
abi...@ny.fnx.com (Abigail) writes:
>
> On Thu, 20 Mar 1997 12:47:10 -0500, Christopher D. Granz wrote in rec.games.mud.admin:
>
> ++ In my opinion a person would need to be *very* disfigured to not be
> ++ recongized by someone who knew them before.
>
> Only if you know him well. Not if you just briefly met in a store
> 2 weeks before. Heck, you might not even remember his name, or think
> that any smiling high elf is named 'Elesfin'.
This is another problem: to a troll all elves look the same....
This is why I said that my method would end up being very CPU
expensive, you don't have to make exact matches, but approximate ones
so you can't play with hashes.
Now I don't have the time but I'll post my idea on monday....
> ++ Another thing I plan to do with the introduction system on Sapphire is
> ++ setup it up so if you don't interact with someone you know in someway
> ++ for more then about a month or two you will forget thier name and need
> ++ to be introduced if you meet again.
>
> Is that realistic? You might not recognise someone you met an hour ago
> on the market, while you would never mistake your grandmother for
> someone else, even if you haven't seen her in 10 years.
Two factors should be counted: how many times you met (and
successfully recognized - or were reintroduced) and how long you've
not seen the player.
Note that this recognize trick could be extended to npc, objects,
rooms, etc. After all when you arrive in a foreign city you have no
idea that the square black building is the Majors' house....
(with shops you know - assuming you know the language - because
they usually have signs)
> And how do you determine 'interact'? Be in the same room together?
Player 2 sees a description of player 1. Note that the "memory" is
updated with a drift towards the new appearence, so mistakes can be
dangeous.
> (then you have a nice piece of fastly changing data to keep track off)
> Be re-introduced? (Not very realistic if you already know each other)
When you meet the same player lots of times you get better at
recognizing him....the "permitted fluctuation" becomes smaller and
smaller.
Alberto
Jacob Hallen
In article <3330CD...@newl.com>,
Christopher D. Granz <qu...@newl.com> wrote:
>Jon A. Lambert wrote:
>> > Player Introduction
>> > -------------------
>> An even better idea. I like this one a lot. It adds a good dose of
>> realism and would seem to encourage player interaction.
>
>because
>of disk space (pfiles grow in size a bit with this type of system) but I
>do
>not think disk space is as big of an issue as it once was.
What do you mean hasn't been done before? All this stuff has been a standard
feature of Genesis for the last 5 years.
Jacob Hallen
H. McDaniel
Jon A. Lambert wrote:
>
> Christopher D. Granz <qu...@newl.com> wrote in article <33306D...@newl.com>...
> >
> > Correct Grammar
> > ---------------
> This is also a very nice feature.
>
I do not see "correct grammar" as an essential plus. Consitency in
language usage is essential. Sometimes information is more valuable
than verbosity. Which is what will result from "correct grammar" under
certain MUD conditions. Bottom line: the communication methods should
allow objects to be described in a grammar free way. Later the
user interface could translate that free way into whatever the end
user considers "correct grammar" OR language *adequate* to whatever
they need (client software... shorthand.. whatever.)
-McDaniel
Martin Keegan
Tatu P Saloranta wrote:
>
> Martin Keegan <mar...@cam.sri.com> writes:
> Surely just adding that info is easy enough in itself; but it's just
> the first step towards a better system... How to use the correct
> articles is a problem in itself, because:
A so-called problem which you solve in your description thereof! :)
> >It is outrageous that I see muds forced to treat armour like swords:
> >You sell an armour to the shopkeeper for x gp.
> >just because they don't have any support for basic English grammar.
>
> >Or are you talking about distinguishing between 'the' and 'a' when
> >there are multiple copies of the same entity in the room?
>
> Depending on who sees the message, choosing a correct argument might
> well be somewhat less straightforward. If the player has already referenced
> the item, it probably is "the sword" to him/her ("You see a sword here."
> -> "examine sword" -> <description> -> "take sword" -> "You take the
> sword"). And whether others see it as a sword or the sword... Probably
It's pretty much acceptable for the others to see
Foo picks up a sword.
and for the player to see
You pick up the sword.
Yes, "the". Which sword to pick up has already been resolved by the
parser. If there's more than one sword, it has either asked the player
which one to take, or made some arbitrary decision about which sword
is "the" sword.
> one has to check if there are other items that "look the same" in the room;
> and this can vary between different players; one player might see
> 3 swords, one could see blessed +2 sword, sword of dragon-slaying and
> a plain sword. Also; how about descriptions like "some coins" or "4
Well, if you want to go that far it's even better.
> Of course, it all depends on how sophisticated (~= complex) system you
> have; but I think it's not all that trivial thing to make it work well.
I disagree. It is trivial to get a reasonable degree of sanity.
The only sense in which it would be non-trivial would be if you
started with some stock code which didn't know about English grammar,
and tried to ADD these things. Yet another reason not to use stock
code.
> All in all, I hope you can make it work well, just trying to explain
> why I think it might be quite difficult. I'd love to see an elegant
> way to solve it (efficiently), as it'd probably be one of the things I
> would add to the mud I'm developing. =)
Ok. All you need is two extra properties for each object and mobile;
they can be fit into one byte.
Firstly, an "adam" (named after some random bloke who lives in Oxford)
which tells the system what sort of article to use. There are five
possible values:
none, indefinite, vocalic indefinite, partitive, definite.
which translate to:
cheese, a cheese, an cheese, some cheese, the cheese
(cheese is probably partitive)
Secondly, you need to record whether the entity is singular or
plural.
Examples:
Excalibur: none, singular
grapes: partitive, plural
cheese: partitive, singular
sword: indefinite, singular
apple: vocalic indefinite, singular
Ring of Fire: definite, singular
Now depending on context, the articles are either:
N I V P D
s a an some the
p - - some the
or, in cases like "You pick up THE sword"
N I V P D
s the the the the
p - - the the
This stuff is NOT hard to implement, and some muds do do it.
Christopher D. Granz
H. McDaniel wrote:
>
> Jon A. Lambert wrote:
> >
> > Christopher D. Granz <qu...@newl.com> wrote in article <33306D...@newl.com>...
> > >
> > > Correct Grammar
> > > ---------------
> > This is also a very nice feature.
> >
>
> I do not see "correct grammar" as an essential plus. Consitency in
> language usage is essential. Sometimes information is more valuable
> than verbosity. Which is what will result from "correct grammar" under
> certain MUD conditions. Bottom line: the communication methods should
> allow objects to be described in a grammar free way. Later the
> user interface could translate that free way into whatever the end
> user considers "correct grammar" OR language *adequate* to whatever
> they need (client software... shorthand.. whatever.)
Unfortunately, we have to assume that users connect via telnet, in which
case this type of client side processing is not possible.
Martin Keegan
H. McDaniel wrote:
>
> Jon A. Lambert wrote:
> >
> > Christopher D. Granz <qu...@newl.com> wrote in article <33306D...@newl.com>...
> > >
> > > Correct Grammar
> > > ---------------
> > This is also a very nice feature.
> >
>
> I do not see "correct grammar" as an essential plus. Consitency in
> language usage is essential. Sometimes information is more valuable
Please define what you mean here. I hope you're not equating grammatical
correctness with verbosity.
> than verbosity.
It may interest you to know that I had to read your post twice to
make sense of it.
> Which is what will result from "correct grammar" under
> certain MUD conditions. Bottom line: the communication methods should
> allow objects to be described in a grammar free way. Later the
> user interface could translate that free way into whatever the end
> user considers "correct grammar" OR language *adequate* to whatever
In an ideal world, yes. However, it is the nature of English that it
is not possible to infer what type of 'thing' an object is solely
from its name. From the word 'water', a computer can't tell that
the phrases 'a water' and 'an water' are highly unlikely and never
to be used.
In other languages, such as German and French, it would be necessary
to store the grammatical gender of words as well as whether they are
singular or plural, take 'a', 'an', 'some', etc.
Were we both speakers of such languages, your comments would be
dismissed as utterly fatuous.
Text-based muds rely on the descriptive power of language for their
believability. Having to wade through paragraphs of bad spelling
and grammar can only detract from this. We have it in our power to
'get it right', so there is no excuse for not doing so.
Martin Keegan
Christopher D. Granz wrote:
> > Island was pretty quest-oriented. After you got to level 5 (there were
> > 11 mortal levels), you were required to do a certain number of quests
> > to reach the next level (score became less and less important).
>
> What is Island, I don't think I've heard of that code base before unless
> you are refering to the Isles (which was based off of the original DIKU
> I believe) ?
Not a codebase, but a single mud, written from scratch.
> > The only problem is probably that players want to know each other's
> > names (see George Reese's comment about players wanting to do
> > "tells" across the mud).
>
> I realize this but I am aiming to make Sapphire as much Role-Playing
> oriented as possible. Then again, I am also not planing to have
> global chat or tell channels (I plan to allow communication across
> MUD via special items and spells.)
Cool. Expect players to hate it though (Dan Shiovitz says "but we
don't WANT such players" etc :) )
Mk
> Yes, as of v0.4 of Sapphire there will be a flag you can set on objects
> for mass-noun exceptions :)
You don't need to treat mass-nouns as some sort of exception, nor
nouns requiring no article. Both cases fall into the five-case system
outlined in my post.
H. McDaniel
Christopher D. Granz wrote:
>
> H. McDaniel wrote:
> >
> > Jon A. Lambert wrote:
> > >
> > > Christopher D. Granz <qu...@newl.com> wrote in article <33306D...@newl.com>...
> > > >
> > > > Correct Grammar
> > > > ---------------
> > > This is also a very nice feature.
> > >
> >
> > I do not see "correct grammar" as an essential plus. Consitency in
> > language usage is essential. Sometimes information is more valuable
> > certain MUD conditions. Bottom line: the communication methods should
> > allow objects to be described in a grammar free way. Later the
> > user interface could translate that free way into whatever the end
> > user considers "correct grammar" OR language *adequate* to whatever
>
> Unfortunately, we have to assume that users connect via telnet, in which
> case this type of client side processing is not possible.
"We" do not have to assume any such thing. We merely must have a
pseudo-client processor available for the clientless.
** Now there was another poster who made mention of how silly
(to paraphrase) my statements would seem to a person who knows
of (or speaks) langauges with elements not present in English.
My response to that poster -- who's post I cannot directly reference
due to local news server problems -- follows:
1. I read, and write French fluently, besides speaking some. My last
native french speaking penpal judged my level of french at excellent.
In addition I have dabbled in 5 other langauges *besides* French and
English (3 such at once in the real world is an expeirence, BTW.)
2. I'm an english major, have won *numerous* 1st place essay awards,
aswell as publishing and journalism related awards and credits.
3. As to your having to read my post "twice" before it made sense:
I am 100% guilty of not hand holding and detailing in miroscopic
detail things which seem rather obvious to myself. Things which
(apprently in error) I assume should be obvious to others with
only minor suggestion. And I'm not saying you have to agree with
my take on the "best" course of doing something. But the mechanics
of the proposition should be fairly deductable to the average
programmer.
In short: I understand (perhaps better than you) the human language
portion of things.
-McDaniel
Jon A. Lambert
H. McDaniel <mcda...@nwlink.com> wrote in article <333B3E95...@nwlink.com>...
>
> 3. As to your having to read my post "twice" before it made sense:
> I am 100% guilty of not hand holding and detailing in miroscopic
> detail things which seem rather obvious to myself. Things which
> (apprently in error) I assume should be obvious to others with
> only minor suggestion. And I'm not saying you have to agree with
> my take on the "best" course of doing something. But the mechanics
> of the proposition should be fairly deductable to the average
> programmer.
>
> In short: I understand (perhaps better than you) the human language
> portion of things.
Actually, I also had trouble following your posts. I can make neither
head nor tail of what you are trying to say in item 3.
I am somewhat hindered by the fact that English is my native and only
language.
While I easily forgive spelling errors, duplication of words, and
obviouis grammatical errors, it is my opinion that your post is horribly
unclear and vague to the average English reader.
JL
Christopher D. Granz
H. McDaniel wrote:
>
> 1. I read, and write French fluently, besides speaking some. My last
> native french speaking penpal judged my level of french at excellent.
> In addition I have dabbled in 5 other langauges *besides* French and
> English (3 such at once in the real world is an expeirence, BTW.)
>
> 2. I'm an english major, have won *numerous* 1st place essay awards,
> aswell as publishing and journalism related awards and credits.
And so very modest even after winning all these great awards... :)
I really so no reason for this type of post, what does it prove
anyways?
H. McDaniel
In article <01bc3bab$910b1400$773b...@jlsysinc.ix.netcom.com>, "Jon A. Lambert" <jlsy...@ix.netcom.com> says:
>
>H. McDaniel <mcda...@nwlink.com> wrote in article <333B3E95...@nwlink.com>...
>>
>> 3. As to your having to read my post "twice" before it made sense:
Translation: "The following is an explanation of the ambiguity present in
my previous postings."
>> I am 100% guilty of not hand holding and detailing in miroscopic
>> detail things which seem rather obvious to myself.
Translation: "I am not in the business of providing coding solutions to those
outside my own working group."
>> Things which
>> (apprently in error) I assume should be obvious to others with
>> only minor suggestion.
Translation: "... However, I believe my sketch to be sufficently detailed as
to represent the idea without providing the actual working solution (ie: code or design
charts.)"
>> And I'm not saying you have to agree with
>> my take on the "best" course of doing something.
Translation: "There are of course many ways to reach one's goals [and the
reader may have better ways]..."
>> But the mechanics
>> of the proposition should be fairly deductable to the average
>> programmer.
Translation: "Regardless, you (the average programmer) should be able to
deduce the general structural form of my solution based on the previous notes."
[ ie: it is enough. ]
>> In short: I understand (perhaps better than you) the human language
>> portion of things.
Translation: "While I respect you (the individual the post was addressed to,)
don't believe yourself to be so much better informed than me."
>Actually, I also had trouble following your posts. I can make neither
>head nor tail of what you are trying to say in item 3.
;)
>I am somewhat hindered by the fact that English is my native and only
> language.
And also because I have made a delibrate effort in 90% of my posts to
this NG to be as brief as possible.
>While I easily forgive spelling errors, duplication of words, and
>obviouis grammatical errors, it is my opinion that your post is horribly
>unclear and vague to the average English reader.
Good point.
-McDaniel