What do you think of Introductions?
David W Serhienko
I have been considering how I would implement a system on a mud ala
Genesis (and others) wherein players do not see the name of other
player's until they have been 'introduce'd to each other.
I know how I would do it, and I think I have an elegant solution, if I
decide to do it, but I wondered what people who have played on these
muds think of such a system?
What does it add, in your opinion, to gameplay? What roleplaying
implications have you noticed? How about the social sphere? Does it
improve or suffer?
Thanks for any thoughts you might have to share,
Tigycho
Richard Woolcock
Well as someone who has implemented this code, I have noticed a definate
improvement in roleplaying on my mud (although admittedly I added a number
of other roleplaying encouragements at the same time). It does also add a
certain level of anonymity to the mud as well, which means you have to
actually go and meet people formally.
One of the more interesting aspects I noticed was players reactions to
appearance - before you know someones name, you see a very simple short
description comprising of age and appearance (an ugly teenage boy, a
handsome elderly gentleman, a beautiful young woman, etc). Thus people
would start getting addressed as 'Hey, ugly', or 'Who are you, old man?'
- and an 'beautiful young women' would immediately get a lot of attention
from the mainly-male playerbase. This was a side-affect I hadn't even
considered while writing the code.
As far as the implementation goes...there are many different ways to do
it. How will you store the data (one file per player per player? one
file per player? one huge file? part of some other file?), how will you
access the data (linked/double linked lists? a binary sorted tree? some
other way?), what about the introduction itself - do you 'intro <target>',
or - the more realistic way - intro to everyone in the room (mine makes it
look like a 'say'). Do you have to give your real name, or can you make
one up? Does it cater for people who want to only give their first name
or last name rather than both names (assuming you have multiple names)?
Is the recognition binary, or can you know some people better than others
(and thus see through their disguises better, or recognise them later in
life)? Is there a limit to the number of people you can know, and can
you forget people? Will you be using the recognition code for anything
else as well (ie information known about a particular person)? Will voice
recognition be seperate from appearance recognition? What about other
senses such as smell, touch, etc? ("Hey, I recognise that perfume...")...
What about the ability to change your appearance, thus fooling other people
(unless they know you really well), perhaps even disguising yourself as
another player? What about mistaken identities?
You see, player-recognition is a very simple feature to add, but it is one
with many, many possibilities, and can be as complicated as you are willing
to make it.
KaVir.
Scatter ///oo/\)
In <34D66A...@hotmail.com>, David W Serhienko <tig...@hotmail.com> writes:
>I have been considering how I would implement a system on a mud ala
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>I know how I would do it, and I think I have an elegant solution, if I
>decide to do it, but I wondered what people who have played on these
>muds think of such a system?
>
>What does it add, in your opinion, to gameplay? What roleplaying
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
I've only ever played one mud that did this. It was a very AD&D based
role-play mud but I can't remember the name of the place. I didn't stay
there very long because it seemed that the lack of names effectively
hid people from you. You walk into a room and see "an elven man is here" -
is he an npc or a player? Do you wander around saying hello to every single
thing you meet on the off chance that it is a player? I found you very
quickly assume that everyone is an npc unless they say something to
indicate otherwise. Once most people are making that assumption there is
very little interaction between new people and established players. New
players get the impression that there's an established group of friends
that they are excluded from etc.
I guess it depends on what goals you have in mind. If you are building a mud
where your primary concern is realism and role-play then this can help you
achieve it. But I think it is detrimental to the social side of the mud.
--
Scatter
///\oo/\\\
John Freese
David W Serhienko wrote:
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> I know how I would do it, and I think I have an elegant solution, if I
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
the idea of that sounds great, however, you also have to think of all
the data you would need to store as players introduce themselves to each
other. Provided that you have a small player base, it wouldn't be such a
bad idea, however, if you have a large player base such as a mud like
duris, toril, medivia, rights of passage, mume and others. then you would
have a problem on your hands. :) I haven't played on a mud like that yet,
but the idea does sound neat.
-------------------------------------- - --- -- -
John Freese (van...@mediaone.net)
Play Duris: Land of BloodLust (duris.org 6666)
---------------------------------------- - --- -- -
Lars Duning
Scatter ///oo/\) wrote:
>
> In <34D66A...@hotmail.com>, David W Serhienko <tig...@hotmail.com> writes:
> >Genesis (and others) wherein players do not see the name of other
> >player's until they have been 'introduce'd to each other.
> I've only ever played one mud that did this. It was a very AD&D based
> role-play mud but I can't remember the name of the place. I didn't stay
> there very long because it seemed that the lack of names effectively
> hid people from you. You walk into a room and see "an elven man is here" -
> is he an npc or a player? Do you wander around saying hello to every single
> thing you meet on the off chance that it is a player? I found you very
> quickly assume that everyone is an npc unless they say something to
> indicate otherwise. Once most people are making that assumption there is
> very little interaction between new people and established players. New
> players get the impression that there's an established group of friends
> that they are excluded from etc.
>
> I guess it depends on what goals you have in mind. If you are building a mud
> where your primary concern is realism and role-play then this can help you
> achieve it. But I think it is detrimental to the social side of the mud.
Personally I'd implement introduction only halfway, allowing players to see
all other players in the who, and also allow tells (and channels) to
non-introduced players.
But in any case you need a large playerbase, else lonely players will introduce
themselves to anything in sight, just in case, which is not the intention either.
--
Lars Duening; la...@cableinet.co.uk (Home)
BRILLIANC
>Subject: What do you think of Introductions?
>From: David W Serhienko <tig...@hotmail.com>
>Date: Mon, Feb 2, 1998 19:54 EST
>Message-id: <34D66A...@hotmail.com>
>
>I have been considering how I would implement a system on a mud ala
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>decide to do it, but I wondered what people who have played on these
>muds think of such a system?
>
>What does it add, in your opinion, to gameplay? What roleplaying
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
>
>Tigycho
>
>
>
>
>
>
>
I think it's in interesting idea as it is pretty realistic in some ways.
I just wonder if the muds using this system allow pkilling? If so,
it's pretty unrealistic to have to know your victims' names to kill
them. In the real world, people are always getting killed by
people who don't know their names. Also, in the real world, one
can actually speak to people without knowing their names. I do
it all the time. I recognize people and often can't remember their
names if I even knew it at all. How does this kind of thing work
when you don't know if you are in a room with a pc or an npc as
mentioned in the other posts on this subject? I think I would get
frustrated if I logged onto a mud and couldn't see the names of
people who are on and couldn't tell a player from a mob because
of the lack of names......unless there are names on the wholist?
Wysi
Khayman
> >Genesis (and others) wherein players do not see the name of other
> >player's until they have been 'introduce'd to each other.
> >
> >I know how I would do it, and I think I have an elegant solution, if I
> >decide to do it, but I wondered what people who have played on these
> >muds think of such a system?
> >
> >What does it add, in your opinion, to gameplay? What roleplaying
> >implications have you noticed? How about the social sphere? Does it
> >improve or suffer?
> >
> >Thanks for any thoughts you might have to share,
> >Tigycho
> >
>
> I think it's in interesting idea as it is pretty realistic in some ways.
> I just wonder if the muds using this system allow pkilling? If so,
> it's pretty unrealistic to have to know your victims' names to kill
> them. In the real world, people are always getting killed by
> people who don't know their names. Also, in the real world, one
> can actually speak to people without knowing their names. I do
> it all the time. I recognize people and often can't remember their
> names if I even knew it at all. How does this kind of thing work
> when you don't know if you are in a room with a pc or an npc as
> mentioned in the other posts on this subject? I think I would get
> frustrated if I logged onto a mud and couldn't see the names of
> people who are on and couldn't tell a player from a mob because
> of the lack of names......unless there are names on the wholist?
>
This subject hits pretty close to home for me, as I am Arch for the
LPc-based ENULAL.
We use the met/unmet flag to determine how a character sees npcs and
other pcs; if the player hasn't been introduced to the character in
question, he gets the characters adjective and race. An example would
be:
If you haven't met me (been introduced to me) you'll see my character as
"The brown-skinned slender vampire wizard;" otherwise, you see me by my
name "Khayman." If you wish to attack an unmet pc/npc (*see below), you
can use their race as the target (ie <kill wizard> or <kill vampire>).
Its up to the wizards coding their areas to generate NPC's with
interactive qualities; among these is the ability (trigger) for them to
introduce themselves to players when an introduction is made in the room
the NPC is in. The player can then decide if the NPC is worth
<remembering>; if not (and the same holds true for met-players) the
pc/npc will again show up as "adj adj race gender" the next time you log
in.
About 3 months ago, our Keeper made some changes to the game, and among
these he requested that our former <who> system, which listed all
players regardless of met-status, be changed to the current system,
which only shows those people you've met/remembered. As it stands now,
any met NPC's also show up on the list, in an attempt to blur the line
between game and reality.
Opinions on these "new" <who> settings are mixed. Of course, old players
wish things were back the way they were. A few of the newcomers also
wish that the old system was in place (of course they don't call it "old
system" ;-P), especially since we have alot of areas that are good for
team-based adventuring, and yet in remote locations. Either way, the
met/unmet presentation is accepted by all as a logical system, and by
itself, causes no detriment to the social atmosphere.
*We also have pk'ing, but you can only pk other pk'ers. All pk'ers get a
<KILLER> tag on the end of both their met and unmet presentation.
-Khayman-
Master of Death,
Seeker of Oblivion,
Arch of Enulal
telnet://enulal.u-aizu.ac.jp:2222/
http://enulal.u-aizu.ac.jp:2224/
========================================================
Reality is a crutch for those who can't handle wargames.
========================================================
When I reverted to my original email, the amount of spam I received went
up 300%. Remove the NOSPAM to reply or email me.
A. Eschenburg
David W Serhienko wrote:
>
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> I know how I would do it, and I think I have an elegant solution, if I
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
> Thanks for any thoughts you might have to share,
> Tigycho
Hello,
i have been playing on a mud with such a system for some time, and
now that i started playing another one, i miss it. Keeping track of
whom you remember or not is something which adds a lot of
opportunities if done right. There are a few things to watch out for,
though.
The main problem of the system actually is the question how to
determine who is remembered. Logic would suggest a limited size
for this. Which opens up a whole bag of things to consider.
But in the end, it is well worth the trouble, and does add a lot
to Roleplay and atmosphere of a mud, at least in my eyes.
Axel
Niilo Paasivirta
BRILLIANC <bril...@aol.com> wrote:
>I just wonder if the muds using this system allow pkilling? If so,
>it's pretty unrealistic to have to know your victims' names to kill
>them. In the real world, people are always getting killed by
>people who don't know their names. Also, in the real world, one
In the real world, there aren't utterly powerful people who walk
around in a super armour, wielding a sword, and killing everyone
they see, including the police...
Introduce-system, free - "realistic" - player killing, and skill based
autocombat mud is a dangeorous combination. Powerful killers may
drive all decent players away. And if the admins punish the killers,
then the mud is not "realistic" any more.
Most _Roleplaying_ MU*:s seem to be the exact opposite to the
introducion system! You will see everyone on who list and you do
know the names - and even races and such. Players need to find
reasons of meeting and knowing the other characters "In Character".
--
<a href="http://www.jyu.fi/%7Enp/index.html"> Niilo Paasivirta </a>
Niilo Paasivirta
Khayman <ejst...@evansville.netNOSPAM> wrote:
>*We also have pk'ing, but you can only pk other pk'ers. All pk'ers get a
><KILLER> tag on the end of both their met and unmet presentation.
With some experience, I'd say that that kind of system might not work
either. For example, the non-PK-ers _will_ include jerks who keep
insulting and harrassing the PKers. And the latter can not do anything
about it. If your MUD has decent players, then it might work...
In my opinion, the only PK systems that perhaps work in an autocombat
MUD are: "no PK at all" or "free PK everywhere by anyone at any time".
Alan Schwartz
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
One neat thing that an introductions system makes possible is
simulating "amnesia" (from drinking from that sacred spring, via
a spell, etc.) in a meaningful way -- you no longer recognize your
associates or remember their names!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Alan Schwartz
Paul@DuneMUSH | dune...@pennmush.org
Javelin@Belgariad, and elsewhere | PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
PennMUSH Source: ftp://ftp.pennmush.org/pub/PennMUSH/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Michael G. Willey
On 4 Feb 1998 11:01:08 +0200, n...@kanto.cc.jyu.fi (Niilo Paasivirta)
wrote:
I've got a somewhat-related beef with PK-able muds where PK-ing is
'illegal'. As an experienced LPC coder, I *know* that if a mud's
administration beleives in a 'No PKing at any time' stance, it's an
extremely simple matter to make it physically impossible; to make your
combat system simply not allow players to fight each other is a simple
matter of adding a check for it in your player object. The same thing
can be said for muds where robbing other players is possible, but
illegal.
Can anybody tell me why you might implement such a system?
-Mike Willey, formerly Mickelian@DreamShadow
A. Eschenburg
Niilo Paasivirta wrote:
>
> BRILLIANC <bril...@aol.com> wrote:
> >I just wonder if the muds using this system allow pkilling? If so,
> >it's pretty unrealistic to have to know your victims' names to kill
> >them. In the real world, people are always getting killed by
> >people who don't know their names. Also, in the real world, one
>
> In the real world, there aren't utterly powerful people who walk
> around in a super armour, wielding a sword, and killing everyone
> they see, including the police...
>
> Introduce-system, free - "realistic" - player killing, and skill based
> autocombat mud is a dangeorous combination. Powerful killers may
> drive all decent players away. And if the admins punish the killers,
> then the mud is not "realistic" any more.
Actually, after having played on exactly that combination, i have to
disagree.
Wether or not there is an introduce system or not does not change the
risk
you have of such "super pk'ers", who only log to kill everyone they meet
and
then log off, or worse, who log on and stick around to make the playing
miserable
for others.
The main point there is that people learn to recognize him by other
means than the
name. (There was a mild case of that at the mud i played, which led to
everyone to
be extra weary of centaurs, especially those that were armed.)
I dont want to go into the numerous ways this can be made less a risk,
that would not
contribute to the discussion here.
> Most _Roleplaying_ MU*:s seem to be the exact opposite to the
> introducion system! You will see everyone on who list and you do
> know the names - and even races and such. Players need to find
> reasons of meeting and knowing the other characters "In Character".
Hmm, that tends to be rather difficult in my eyes. Not knowing the names
and not knowing who is around one might meet makes it more interesting
to go out and try to meet people. So, in a way one is forced to roleplay
by such a system, because if he knows noone, he cannot ask anyone for
help if he needs some. On muds where everyone knows everyone, it seems
rather common to ask anyone for help, even if that person is not really
known to the char.
Axel :)
David W Serhienko
<snippage>
> I've got a somewhat-related beef with PK-able muds where PK-ing is
> 'illegal'. As an experienced LPC coder, I *know* that if a mud's
> administration beleives in a 'No PKing at any time' stance, it's an
> extremely simple matter to make it physically impossible; to make your
> combat system simply not allow players to fight each other is a simple
> matter of adding a check for it in your player object. The same thing
> can be said for muds where robbing other players is possible, but
> illegal.
>
> Can anybody tell me why you might implement such a system?
Why someone might implement a Mud where Pking is illegal but possible?
Realism, I would imagine.
If you mean, why would someone implement a mud where PKing is a
technical impossiblity, as in your last comment, I would imagine it
would be for social reasons.
Tiggy
>
> -Mike Willey, formerly Mickelian@DreamShadow
Joshua Kling
>I have been considering how I would implement a system on a mud ala
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>I know how I would do it, and I think I have an elegant solution, if I
>decide to do it, but I wondered what people who have played on these
>muds think of such a system?
>
>What does it add, in your opinion, to gameplay? What roleplaying
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
>
>Thanks for any thoughts you might have to share,
>Tigycho
Well... implementing it should be cake (speaking from an LPC point of
view). All you really need is an array of "introduced" people for each
player (this shouldn't get too big, even on large muds, players won't
know everyone). As for playability? I don't see why it shouldn't be
much of a problem in that respect. As long as players have alternate
means of referencing other players. For example "short, fat elf" ...
could reference them as "elf" "short elf" "fat elf" etc... as for
PKers slaying everyone in sight with annonimity... it's a tough issue,
you have to balance realism with playability and decide which is more
important for your MUD. There's no reason why an introduction system
shouldn't work, and I think it would be really cool for a role playing
game.
Hans-Christian Wittler
Joshua Kling <jsk...@fingers.nospam.shocking.com> schrieb im Beitrag
<34da9d30...@news.shocking.com>...
Well, yes, Thats the starter and thats where the problems start too...
I have played on a mud where they did exactly that. You could still adress
somebody
with her real name (look at slartibartfast worked even though you didn't
'know' it was
slartibartfast.
So when you met somebody you thought might be a known pp or pk'er you tried
lots
of 'look at' cmds with the names of known trouble makers. Usually you came
up with the
real name quite fast ...
Another problem exists with query_name()... Its very bad form if you do an
introduction
system and the npc's moving around know everybody by name :)
Next point is a court system. The mud I was playing on had a very well
working mortal run
judge system. When they changed to introduction system you could only
accuse somebody
who had registered himself at the court.... guess who didn't do that or
only registered at a single court...
With this change the whole judge-system was virtually disabled.
Another problem exists with people disguising as somebody else and causing
trouble.
Things like that are very hard to balance out.
I don't say that it is impossible to code one, but you have to be really
careful on how you implement it.
Space Girl
David W Serhienko wrote:
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> I know how I would do it, and I think I have an elegant solution, if I
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
> Thanks for any thoughts you might have to share,
> Tigycho
I've played on two muds so far that use longdesc systems.. Enjoy them
both quite a lot. On one, my char is very outgoing and vivacious, and
goes out of her way to make friends. On the other, my char is a lot
quieter, and doesn't know many people, consequently. But it's like RL, ya
know.. I know lots of people by face and talk to them on a daily basis
and haven't a clue what their names are. It doesn't bother me, to be
honest. It rattled me a lot at first but now it's quite natural to me.
I agree about the amnesia comment.. hilarious, I love that.
I don't see how it'd alienate newbies. I was a newbie to it too and it
didn't seem too hard to deal with. And on the other mud I play that uses
this system, I got snapped into the action fairly quickly.
Space Girl, mhm9x5
Herding Cats My Specialty
Holly Sommer
David W Serhienko wrote:
: I have been considering how I would implement a system on a mud ala
: Genesis (and others) wherein players do not see the name of other
: player's until they have been 'introduce'd to each other.
A possible way...
Include two fields in your playerfiles:
int pnumber;
char *introduced; /* or int introduced[MAX_PLAYERS] */
For each new player saved, that pfile gets the next available pnumber.
When someone decides to introduce themself, it flips a bit in
that players' pnumber position on the other players' indroduced[].
To illustrate:
Newman, a grey kender, has a pnumber of 341.
Shaendra, a willowy half-elf, has a pnumber of 200.
Newman introduces herself like this:
Introduce me halfelf.
Shaendra's introduced[199] is set to 1 (true).
Or, instead of a 1/0, you could put a number in there which could be
like a "memory" length. When first introduced,
shaendra->introduced[199] = 100;
This number decreases every MUD hour, unless she sees Newman again,
and then it goes up by 5... or perhaps grouping with Newman increases
it by 25 or something like that.
You'd just have to up the MAX_PLAYERS every so often, and change
pnumber to type long, as you get more saved pfiles
-Holly
Richard Woolcock
Holly Sommer wrote:
>
> David W Serhienko wrote:
>
> : I have been considering how I would implement a system on a mud ala
> : Genesis (and others) wherein players do not see the name of other
> : player's until they have been 'introduce'd to each other.
>
> A possible way...
>
> Include two fields in your playerfiles:
> int pnumber;
> char *introduced; /* or int introduced[MAX_PLAYERS] */
>
> For each new player saved, that pfile gets the next available pnumber.
> When someone decides to introduce themself, it flips a bit in
> that players' pnumber position on the other players' indroduced[].
>
> You'd just have to up the MAX_PLAYERS every so often, and change
> pnumber to type long, as you get more saved pfiles
Ack! Sorry, but that is really horrible - if you had even 1000 players then
that would require an array at least 1000 big PER pfile. Even if you only
stored people you knew, eg:
#MET 1 20 (Met player number 1, counter of 20).
#MET 5 30 (Met player number 5, counter of 30).
It would still get pretty silly - and in addition you would have to update
the MAX_PLAYERS (and recompile all the code) every time you wanted to change
the pfile limit.
The only reasonable way to do it is via a double linked list or a binary
sorted tree (the former is probably the best in this situation).
Note that this follows the merc ascii-style saving - I am unfamiliar
with the method that lp muds use, but I'm sure they would have a similar
problem.
KaVir.
George Reese
You could also do it as a mapping instead of as an array. Though I am
not recommending such an approach or disavowing it. I have not put
any thought into this issue :)
In rec.games.mud.lp Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
: KaVir.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
Michael G. Willey
Perhaps my use of the word 'illegal' was misunderstood. I'm not
complaining about a system wherein player murderers are tracked down
by other players and brought to justice.. I have such a system in
mind (if my home MUD ever comes back). My complaint is with a system
where the staff directly punishes player-killers and thieves, because
PKing/robbery is against the game's rules. That's not realism, that's
just a big hassle to staff who would otherwise be doing productive
work, as well as an annoyance to players who are affected (murdered
players who lose out by dying, robbed players who lose money/eq, and
the thieves themselves, who constantly complain that they've 'wasted'
points on buying skills that they aren't allowed to use)
I also don't mean to offend anyone who *does* use such a system. I
simply would like opposing points of view.
-Mike Willey, formerly Mickelian@DreamShadow
Steve Williams
Hans-Christian Wittler <wit...@media-saturn.com> wrote in article
<01bd32d5$731f5ce0$7f0110ac@ws_wittler.media-saturn.com>...
> Next point is a court system. The mud I was playing on had a very well
> working mortal run
> judge system. When they changed to introduction system you could only
> accuse somebody
> who had registered himself at the court.... guess who didn't do that or
> only registered at a single court...
> With this change the whole judge-system was virtually disabled.
> Another problem exists with people disguising as somebody else and
causing
> trouble.
> Things like that are very hard to balance out.
> I don't say that it is impossible to code one, but you have to be really
> careful on how you implement it.
Well...this was a matter of poor implementation then. Again, if proper
implemented, the Introduction System could have added to the realism rather
than take away from it. Check out this scenerio....
You're walking down a dark street. Suddenly a cut-throat sticks a knife in
your back. The only description you have is that it is a young elf dressed
in a black cloak. You narrowly escape with your life and run off seeking
help. You can't say, "Hey man! I was just attacked by that guy Durlock!",
you can only tell them that it was a young elf dressed in a black cloak.
Unless, of course, you recognize Durlock.
Futhermore, if Durlock is currently "Wanted" for other crimes, you may be
able to "know" him if you've reviewed the wanted posters.
See my point?
pa...@dict.mq.edu.au
In article <34D66A...@hotmail.com>,
tig...@hotmail.com wrote:
>
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
If I were implementing a system like this, I would try to do away with
names altogether. Why do you need names? If your player characters are
detailed, it shouldn't be a problem generating reasonably unique one-line
descriptions. It sounds cumbersome, but after a while you tend to
recognise the shape of the text anyway, just as you would recognise a
person's appearance. If you were unsure, you could just look at the
person - surely a page of descriptive text would be enough. If your NPCs
are so insignificant that players would not even bother to give them a
second look, then I think your mud needs some more improvements in other
areas. :) Regardless though, it is trivial to make your player's default
appearance distinct from those of NPCs (Even if its as contrived as
appending an asterisk). When I think about it, the most noticable
attributes of a person are their body shape, hair, facial features, and
clothing/adornments. These features could be prioritised when building a
person's description, such that unusual or prominent features were more
likely to be in your description than common ones. Its a pity that
today's goal-oriented muds are so poorly designed around
level-advancement. It makes everything so petty and contrived. Imagine
a mud where you *couldn't* organise every piece of clothing and weaponry
from least to most useful. You'd actually have a choice in that part of
your appearance. People would actually be interesting to look at! Ah
well, who has the time to do it right anyway? :)
Timekiller
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Hans-Christian Wittler
Steve Williams <st...@stevewilliams.com> schrieb im Beitrag
<01bd34f6$c4fdabc0$b03eaccf@christine>...
Of course I see your point and I am all in favor of an introduction system.
I just wanted
to point out some of the problems you get when you try to implement a
system like that.
Btw, I never saw a system yet that had wanted posters. It might be a nice
idea to implement
on the mud i am working on :)
Katrina McClelan
In <887013639....@dejanews.com> pa...@dict.mq.edu.au writes:
>names altogether. Why do you need names?
Simply put, because human memory is not that good. In terms of game play,
you're right, they aren't strictly neccesary, but it's somewhat likely
that in the long run you'd have anything but a long list of dwarves with
various adjectives, like a bashful dwarf, a sleepy dwarf, a dopey dwarf,
etc (ok, so that's not as funny as I first thought), which would after
several dozen would start getting fuzzy. This is somewhat reasonable for
players. But for administrative identification it's useful to have a
concise name that is easily logged and tracked. Granted I am of the
opinion that the way to beat hackers and trouble makers is preventitive
rather than disiplinary (ie don't nuke them for abusing a bug, fix the
bug), but you still need to track bad seeds to keep an eye on any holes
you may need to look at.
[snip comments about doing it right]
Personally I'd not let players save descriptions... I'd descibe them as
is:
a tall elf in chain main and a green cloak arrives from the south.
^ ^ ^ ^
| | | |
| | | +--taken from equipment list
| | |
| | +--taken from equipment list
| |
| +--player is elven
|
+--player is 6'5"
-Katrina (who is happy that they finally fixed inews)
Richard Woolcock
Katrina McClelan wrote:
>
> In <887013639....@dejanews.com> pa...@dict.mq.edu.au writes:
>
> >names altogether. Why do you need names?
>
Names play an important part in life, as well as on the mud. How many
times has someone phoned you up and said "Hi, this is that tallish guy
with long brown hair and a nose-ring who wears blue jeans and a white
t-shirt"? Names are vital as points of referance.
> Personally I'd not let players save descriptions... I'd descibe them as
> is:
>
> a tall elf in chain main and a green cloak arrives from the south.
> ^ ^ ^ ^
> | | | |
> | | | +--taken from equipment list
> | | |
> | | +--taken from equipment list
How would you decide which pieces of equipment to use?
> | |
> | +--player is elven
Does the viewer know what an elf is?
> |
> +--player is 6'5"
If I am playing a 20' giant, would the person still be 'tall'?
It isn't very hard to implement descriptions which vary from viewer
to viewer. Your 'tall elf in chain main and a green cloak' might
look like a 'little guy with pointed ears and a silver vest' to my
giant. The only problem with this is that the descriptions would
have to be determined every time you saw that person doing something
- I'm not sure what sort of effect this would have on cpu usuage, but
having to check their equipment to make the description every time
couldn't help.
KaVir.
Katrina McClelan
>> Personally I'd not let players save descriptions... I'd descibe them as
>> is:
>>
>> a tall elf in chain main and a green cloak arrives from the south.
>> ^ ^ ^ ^
>> | | | |
>> | | | +--taken from equipment list
>> | | |
>> | | +--taken from equipment list
>How would you decide which pieces of equipment to use?
Actually, I hadn't had time to consider that. I'd come up with a way.
The p[oint is the data is there to use.
>> | |
>> | +--player is elven
>Does the viewer know what an elf is?
Perhaps not. I could change the string for how to describe an elf, but
the thing is the PLAYER should know even if the character doesn't so it
should suffice.
>> |
>> +--player is 6'5"
>If I am playing a 20' giant, would the person still be 'tall'?
No, but if the player types his own description he is.
>It isn't very hard to implement descriptions which vary from viewer
>to viewer. Your 'tall elf in chain main and a green cloak' might
>look like a 'little guy with pointed ears and a silver vest' to my
>giant.
Very true. Not hard either:
per = target->height / viewer->height;
if(per < 1.1 || per > .9) {
/* roughly same height */
} else if(per >=1.1) {
/* taller */
} else ....
(etc etc).
>The only problem with this is that the descriptions would
>have to be determined every time you saw that person doing something
>- I'm not sure what sort of effect this would have on cpu usuage, but
>having to check their equipment to make the description every time
>couldn't help.
True, but compared to the network overhead to actually SEND the
description, not really that big of a deal, provided the server is coded
from top down to be optimised. If you needlessly use a ton of CPU like
*cough cough* some servers do, it may become more of a problem, but if
your code is clean, you should be able to get reasonable performance. If
I were to guess, I'd say probably 25-30 people (with 100 people on) seeing
a person described as above per 1/4 second game loop (on mine 1/3 sec),
and I probably sleep 80-90 percent of that time on a decent (pentium 100
or better) machine, so I don't think it's too much of a concern. Just a
matter of if I get the motivation to sit down and code it. The big
problem with intros is keeping track of the database. 10000+ registered
players and you have a slight memory hog to keep track of who knows whom.
Of course, I'd keep tallies and have somewhat of a limited memory (evil
grin). If you spend all day with Geofram, you'd knoww him pretty well,
but if you meet Cynthia in passing you may not remember her by name later.
(this could be a function of intellegence/wisdom/some mental attribute
that makes sense).
-Kat
Matt Chatterley
On Sun, 8 Feb 1998, George Reese wrote:
> You could also do it as a mapping instead of as an array. Though I am
> not recommending such an approach or disavowing it. I have not put
> any thought into this issue :)
As George, I'm speaking without really thinking about this, just a random
idea - perhaps this could be approached with hash table stored somewhere
central by the mud, so that data is cross-referenced (a cross-linked list
of some sort), letting it tell who knows who, and how well, rather than
storing the data from an individual perspective (which as Richard pointed
out, is a LOT of data).
--
Regards,
-Matt Chatterley
"Every breath you take, every bond you break.. I'll be watching you."
-The Police
pa...@dict.mq.edu.au
Katrina said:
> >names altogether. Why do you need names?
>
> Simply put, because human memory is not that good. In terms of game play,
> you're right, they aren't strictly neccesary, but it's somewhat likely
> that in the long run you'd have anything but a long list of dwarves with
> various adjectives, like a bashful dwarf, a sleepy dwarf, a dopey dwarf,
> etc (ok, so that's not as funny as I first thought), which would after
> several dozen would start getting fuzzy. This is somewhat reasonable for
> players. But for administrative identification it's useful to have a
> concise name that is easily logged and tracked. Granted I am of the
Obviously I was talking about the player interface. Yes, for admin
purposes, names are very useful, and I wouldn't suggest dropping them.
Your players need to identify themselves when they log in, and your
implementation would have some sort of identification key. But your
players don't need it. Does it matter if I cant remember the names of
the seven dwarfs, or a room full of people I just met?
KaVir said:
> Names play an important part in life, as well as on the mud. How many
> times has someone phoned you up and said "Hi, this is that tallish guy
> with long brown hair and a nose-ring who wears blue jeans and a white
> t-shirt"? Names are vital as points of referance.
Theres nothing stopping you from introducing yourself, exactly as you
would in real life. The whole point is that its the geek in front of
the computer that matches names to faces, rather than the mud itself.
Would you rather be at a tupperware party where everyone wears name tags
and nothing ever goes wrong, or be immersed in an intriguing virtual
reality with real-life scenarios?
Identification is a major problem in real-life. Thats why we have
photo-licenses, fingerprinting, dental records, etc. How did they do
it all those years ago? I imagine it would have been things like
birthmarks, verbal passwords, letterhead, wax seals / family stamps...
> > a tall elf in chain main and a green cloak arrives from the south.
....
> How would you decide which pieces of equipment to use?
Give or derive for each item, a value indicating it's prominence. Then
choose the N most prominent. You could also account for viewing distance,
such that the elf looks like a generic humanoid when viewed from afar.
> Does the viewer know what an elf is?
You'd have to grant the player some background knowledge. Does he know
what chain mail or a cloak is, or even which direction is south?
> If I am playing a 20' giant, would the person still be 'tall'?
She's tall for an elf, which is the point of reference. Yes you'd have
to assume the person knows what an elf is, and how tall they normally are.
> giant. The only problem with this is that the descriptions would
> have to be determined every time you saw that person doing something
I wouldn't bother - just update it (or most of it) when they change
their clothing.
John Viega
In article <34DE72...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
> Holly Sommer wrote:
> >
> > David W Serhienko wrote:
> >
> > : I have been considering how I would implement a system on a mud ala
> > : Genesis (and others) wherein players do not see the name of other
> > : player's until they have been 'introduce'd to each other.
> >
> > A possible way...
> >
> > Include two fields in your playerfiles:
> > int pnumber;
> > char *introduced; /* or int introduced[MAX_PLAYERS] */
> >
> > For each new player saved, that pfile gets the next available pnumber.
> > When someone decides to introduce themself, it flips a bit in
> > that players' pnumber position on the other players' indroduced[].
> > [snip]
> >
> > You'd just have to up the MAX_PLAYERS every so often, and change
> > pnumber to type long, as you get more saved pfiles
>
> Ack! Sorry, but that is really horrible - if you had even 1000 players then
> that would require an array at least 1000 big PER pfile. Even if you only
> stored people you knew, eg:
Welll, this isn't horrible at all under the assumtion that players
introduce themselves to a _lot_ of people. Looking up a bit in a bit
vector based on an index is very fast (O(1) w/ a low constant). Of
course, that probably isn't a _great assumption, but nonetheless, I
think "really horrible" is too harsh. In your example, you'd be
storing on disk 125 bytes per player, which over 1000 players would be
about 120K. As your mud gets larger, That's not bad if you've got a
fair bit of disk space devoted to the mud, since most of the info is
going to be on disk at any given time. You're not going to get too
much faster in terms of lookup time, that's for sure.
If the user is expected to meet only 1 in 100 players AND you have a
ton of players, then I'd probably switch to a mapping and store
player_number : do_i_know_you in each player. (In general, as your mud
gets to be of a significant size, this array is going to be full of a
*lot* of 0's, and so even though you're storing one bit per person,
you may be better off storing say 64 bits for each person you know
(mapping 2 32 bit ints together), and paying the of extra storage
overhead for keeping it in a mapping.
> The only reasonable way to do it is via a double linked list or a binary
> sorted tree (the former is probably the best in this situation).
Actually, I'd prefer the mapping, it's essentially O(1) to store and
look up. If you write your own dynamically resizing mapping code
specifically for this job in C, you could even compact the table, and
map 32 bits onto single bytes (or 1/2 bytes even). That would *more*
than offset the mapping overhead. The doubly linked list is going to
take O(n) time, where n is the number of players on your game. The
tree will be faster than the linked list (O(log n)), but both the tree
and the linked list will end up using more memory than the mapping as
your player base grows, since the doubly linked list you suggest would
require 96 bits per player on most machines, as would the tree. If
you drop to a singly linked list, you're still going to use 64 bits,
and have an unacceptable lookup time.
BTW, if you're _really_ into the bit per person method, you don't need
anything like a MAX_PLAYERS variable in LPC (or C if you're willing to
dynamically realloc), which I assume the original poster was refering
to, since this thread is crossposted in r.g.m.lp. Use the
set_bit()/test_bit()/clear_bit() functions.
John
----------------------------------------------------------------------------
|John Viega "The public at large tends to confuse the |
|vi...@list.org composing of a symphony with the writing of |
|http://list.org/~viega/ its score." |
|University of Virginia -- Edsger Dijkstra |
----------------------------------------------------------------------------
Hans-Christian Wittler
pa...@dict.mq.edu.au schrieb im Beitrag
<887090612....@dejanews.com>...
> Katrina said:
>
> > >names altogether. Why do you need names?
> >
> > Simply put, because human memory is not that good. In terms of game
play,
> > you're right, they aren't strictly neccesary, but it's somewhat likely
> > that in the long run you'd have anything but a long list of dwarves
with
> > various adjectives, like a bashful dwarf, a sleepy dwarf, a dopey
dwarf,
> > etc (ok, so that's not as funny as I first thought), which would after
> > several dozen would start getting fuzzy. This is somewhat reasonable
for
> > players. But for administrative identification it's useful to have a
> > concise name that is easily logged and tracked. Granted I am of the
>
> Obviously I was talking about the player interface. Yes, for admin
> purposes, names are very useful, and I wouldn't suggest dropping them.
> Your players need to identify themselves when they log in, and your
> implementation would have some sort of identification key. But your
> players don't need it. Does it matter if I cant remember the names of
> the seven dwarfs, or a room full of people I just met?
>
Well, on all the introduce-muds i know you have about 2 attributes, gender
and race
if you don't know somebody. So you might see a muscular potato-nosed male
dwarf or
a tall long-haired female elf or whatever.
If you are in a discussion with about 3 or 4 people whom you don't know it
gets REAL garbled.
Just finding out who said what is getting difficult at times. And if i meet
people rl i have a picture
of somebody and can remember them easily. (sometimes at least :) ).
On the mud I am working on at the moment you can 'remember' people with
about every name you want.
So its irelevant if they introduce to you with their true name (name of the
pfile) or not. If i want to remember
someone I can do so. Even If I remember them as 'that stupid dwarf' or
stuff like that.
> KaVir said:
>
> > Names play an important part in life, as well as on the mud. How many
> > times has someone phoned you up and said "Hi, this is that tallish guy
> > with long brown hair and a nose-ring who wears blue jeans and a white
> > t-shirt"? Names are vital as points of referance.
>
> Theres nothing stopping you from introducing yourself, exactly as you
> would in real life. The whole point is that its the geek in front of
> the computer that matches names to faces, rather than the mud itself.
> Would you rather be at a tupperware party where everyone wears name tags
> and nothing ever goes wrong, or be immersed in an intriguing virtual
> reality with real-life scenarios?
> Identification is a major problem in real-life. Thats why we have
> photo-licenses, fingerprinting, dental records, etc. How did they do
> it all those years ago? I imagine it would have been things like
> birthmarks, verbal passwords, letterhead, wax seals / family stamps...
I think i got into that above. Trying to sort out near identical
descriptions in a big
discussion can be real tedious.
About the licensing stuff you are quite right. But then on the mud I am
working if you do
a real good disguise you could pose as somebody else. Even with the npc's.
But thats
quite hard to do and requires a lot of disguise skill.
Threshold RPG
In article <887090612....@dejanews.com>, pa...@dict.mq.edu.au wrote:
>Obviously I was talking about the player interface. Yes, for admin
>purposes, names are very useful, and I wouldn't suggest dropping them.
>Your players need to identify themselves when they log in, and your
>implementation would have some sort of identification key. But your
>players don't need it. Does it matter if I cant remember the names of
>the seven dwarfs, or a room full of people I just met?
Personally, I would hate to play a game without names. In real life, how do
you organize things like your personal address books. Do you have a section on
short, bearded men? No. You sort people by their names.
Society CREATED names for the very purpose of being able to deal with each
other in a far more organized fashion. Can you imagine having conversations
with people if people didnt have names?
"Hey you there with the brown beard. Remember last week when we went to the
night club with the tall man with brown hair and green eyes and a dark blue
sport coat and medium sized man with brown hair and green eyes and blue
jeans, and a short woman with blonde hair and blue eyes with a flower
patterned dress? I was so surprised when tall man with brown hair and green
eyes and a dark blue sport coat got totally smashed and bumped into medium
sized man with brown hair and green eyes and blue jeans causing him to spill
his beer all over short woman with blonde hair and blue eyes with a flower
patterned dress. What was tall man with brown hair and green eyes and a dark
blue sport coat thinking? He knows he cant hold his liquor very well. And
medium sized man with brown hair and green eyes and blue jeans was totally
pissed off! I bet it will be a while before short woman with blonde hair and
blue eyes with a flower pattered dress or medium sized man with brown hair and
green eyes and blue jeans ever go anywhere with tall man with brown hair and
green eyes and a dark blue sport coat again!"
Compare that to:
"Hey Frank! Remember last week when we went to the night club with Bob, Dave,
and Jane? I was so surprised when Bob got totally smashed and bumped
into Dave causing him to spil his beer all over Jane. What was Bob thinking?
He knows he cant hold his liquor very well. And Dave was totally pissed off! I
bet it will be a while before Jane or Dave ever go anywhere with Bob"
I think the preferable scenario is obvious.
-Aristotle@Threshold
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, rich, detailed roleplaying environment.
http://www.threshold.counseltech.com
telnet://threshold.counseltech.com:23
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Richard Woolcock
John Viega wrote:
>
> In article <34DE72...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>
> > Holly Sommer wrote:
[snip]
> > > You'd just have to up the MAX_PLAYERS every so often, and change
> > > pnumber to type long, as you get more saved pfiles
> >
> > Ack! Sorry, but that is really horrible - if you had even 1000 players then
> > that would require an array at least 1000 big PER pfile. Even if you only
> > stored people you knew, eg:
>
> Welll, this isn't horrible at all under the assumtion that players
> introduce themselves to a _lot_ of people. Looking up a bit in a bit
> vector based on an index is very fast (O(1) w/ a low constant). Of
> course, that probably isn't a _great assumption, but nonetheless, I
> think "really horrible" is too harsh. In your example, you'd be
> storing on disk 125 bytes per player, which over 1000 players would be
> about 120K. As your mud gets larger, That's not bad if you've got a
> fair bit of disk space devoted to the mud, since most of the info is
If disk space became a problem I would use binary files. If you only
want to know if you know the person or not, then 4 bytes would easily
suffice per player per player (just store an id for the people you know).
If there were 1000 players, and everyone knew each other, that would
take up less than 4 meg of disk space.
Of course, you don't have to remember EVERY player...
> going to be on disk at any given time. You're not going to get too
> much faster in terms of lookup time, that's for sure.
The array would be faster for lookup - and if I only wanted one bit
per player I could always typedef a bit field. However the real problem
is that you are specifying how many players are allowed to exist (exist,
not just be online at once) and allocating space for each player^player!
> If the user is expected to meet only 1 in 100 players AND you have a
> ton of players, then I'd probably switch to a mapping and store
> player_number : do_i_know_you in each player. (In general, as your mud
> gets to be of a significant size, this array is going to be full of a
> *lot* of 0's, and so even though you're storing one bit per person,
> you may be better off storing say 64 bits for each person you know
> (mapping 2 32 bit ints together), and paying the of extra storage
> overhead for keeping it in a mapping.
Why not just use a single 32 bit integer? You could use the last bit to
represent if you knew them or not, and the rest of it to correspond to a
unique player id. Stored in a seperate binary file, this would take only
4 bytes of space per person you knew...
> > The only reasonable way to do it is via a double linked list or a binary
> > sorted tree (the former is probably the best in this situation).
>
> Actually, I'd prefer the mapping, it's essentially O(1) to store and
> look up. If you write your own dynamically resizing mapping code
Won't this cause memory fragmentation if people are being constantly added
and removed from memory?
> specifically for this job in C, you could even compact the table, and
> map 32 bits onto single bytes (or 1/2 bytes even). That would *more*
> than offset the mapping overhead. The doubly linked list is going to
> take O(n) time, where n is the number of players on your game. The
Nope - every time my code checks to see if you know someone, that person
is moved to the front of the list (thats why I use a double rather than a
single linked list). As you usually interact with a few players at a time,
the lookup time is pretty quick. This is why I used a list rather than a
tree.
> tree will be faster than the linked list (O(log n)), but both the tree
> and the linked list will end up using more memory than the mapping as
> your player base grows, since the doubly linked list you suggest would
You're assuming that I store in RAM everyone that everyone online knows.
I don't. I load them up as needed. You can't do this with a static
array (well you could, but there would be no advantage).
> require 96 bits per player on most machines, as would the tree. If
> you drop to a singly linked list, you're still going to use 64 bits,
> and have an unacceptable lookup time.
The lookup time is quite reasonable. I actually use 128 bits though,
because in addition to the 2 pointers and unique ID, I also use a long
int to store various things you know about that person.
> BTW, if you're _really_ into the bit per person method, you don't need
> anything like a MAX_PLAYERS variable in LPC (or C if you're willing to
> dynamically realloc), which I assume the original poster was refering
> to, since this thread is crossposted in r.g.m.lp. Use the
> set_bit()/test_bit()/clear_bit() functions.
The person I responded to was a diku owner, and I just followed the cross
post. I try to realloc as little as possible (my allocated recognition
blocks just get moved onto a 'free' list when people quit, ready to be
reused).
KaVir.
Holly Sommer
Richard Woolcock wrote:
: Ack! Sorry, but that is really horrible
Heh, well, it was just off the top of my head. I'm sure there are much
more efficient ways of doing it. I was just trying to illustrate that
there are quick-n-dirty means available. :)
-Holly
Katrina McClelan
In <34E11B...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>Why not just use a single 32 bit integer? You could use the last bit to
>represent if you knew them or not, and the rest of it to correspond to a
>unique player id. Stored in a seperate binary file, this would take only
>4 bytes of space per person you knew...
Actually, you wouldn't need the sign bit if you're only storing who you
know (you could tell by having a record or not). If you're storing
everyone you need the sign bit, and 4 bytes per person in existance.
>Won't this cause memory fragmentation if people are being constantly added
>and removed from memory?
Yes, and no.... if you have a free_blah() function that collects unused
memory in a stack and a malloc_blah() that checks to see if you have a
block availible on that stack you tend to fill in the gaps.
>The person I responded to was a diku owner, and I just followed the cross
>post. I try to realloc as little as possible (my allocated recognition
>blocks just get moved onto a 'free' list when people quit, ready to be
>reused).
Heh... didn't realize you already use the same scheme I just mentioned :)
-Kat
David Trott
Threshold RPG <thre...@counseltech.com> wrote in article
<6bpg6b$qqo$1...@usenet88.supernews.com>...
> Personally, I would hate to play a game without names. In real life, how
do
> you organize things like your personal address books. Do you have a
section on
> short, bearded men? No. You sort people by their names.
>
> Society CREATED names for the very purpose of being able to deal with
each
> other in a far more organized fashion. Can you imagine having
conversations
> with people if people didnt have names?
[Snip Example]
An Idea:
Abolish in character names as such and replace them with a unique character
id - CID (just an integer). When you meet some one you do not know, you get
a general description, this is generated according to the preferred method
on the mud. Instead of the person introducing themselves with a command
they can simply say 'Hello I am bill' with a normal say or similar command.
Then you can use a command to assign a short and long description, these
are saved as part of your player object. If I set Bill's short description
to "bill" and Bill's long to "LOUD BILL" next time I see him his
description it will say "LOUD BILL an orc" and I can use the short that I
have set to reference him, e.g. "give axe to bill".
The nice thing about this system is that I could go round giving out any
number of names to people and assuming that I respond to the names when
someone says "Hey john what have you been up to ?"
they will not know. However this could result in some funny meetings where
I meet two people that know me as two different names, I would suspect that
this would go much as it would IRL, so I would allow players to change the
short and long that they see, when they want. This would be good for a
thief, within the guild he could introduce himself as "The Pickpocket",
outside the guild he could introduce himself as "Honest Bill".
When you 'give axe to bill' it would not matter if Bill had forgot that he
had introduced himself as Bill because the command is an action that makes
sense to the person performing it (you know who you think Bill is and you
will try to hand the axe to him), this is the same as before you were
introduced you could mentally label him as orc 3 and use that to give him
an item. Its only things like say, which would cause a problem to the
system, however this is trivial as if John turns round and says "Who's John
?" you know some thing is wrong.
There is a issue about what to do with OOC commands such as channels and
tells, I can see two solutions to this (there are probably more).
First Solution:
Filter the tells on the send and the receive, if I tell some one some thing
I use my name for him and he sees his name for me as being the source of
the message. Channels would also filter people based on your own name for
them. This raises several questions:
How do I tell someone that I know IRL but have not met yet on the mud ?
Assuming they know me but I don't know them what name does it show me ?
If I know four people all called john how do I tell one of them ?
Does the who only show people I have meet in character ? (I believe who is
an OOC command)
My Preferred Solution:
Everyone logs in using there real name or a unique OOC name they can then
choose which character they wish to player (or start another) and enter
the game, all in game commands use the introduction system and all OOC
commands use the OOC name so the who would list all the OOC names, not any
information about who they were playing in character.
Notes:
The implementation would be fairly simple, (Switching to LPC for a moment)
create a mapping keyed on the CID for PC's and the filename for NPC's (I am
not 100% sure that the file name is unique but that a minor point someone
else can deal with) then store the long and short for each person you want
to remember. It would probably be necessary to restrict the number of
character's that someone could remember and then start to forget some
people when the limit was exceeded.
For admin purposes log both the CID and the OOC Name.
I believe it would be possible, though I am not certain on the exact
method, to implement some of the other idea's posted, such as wanted
posters and disguises and I am not sure on the best method for deciding who
gets forgotten.
pa...@dict.mq.edu.au
In article <01bd3601$79826da0$7f0110ac@ws_wittler.media-saturn.com>,
"Hans-Christian Wittler" <wit...@media-saturn.com> wrote:
> > players don't need it. Does it matter if I cant remember the names of
> > the seven dwarfs, or a room full of people I just met?
> >
> Well, on all the introduce-muds i know you have about 2 attributes, gender
> and race
> if you don't know somebody. So you might see a muscular potato-nosed male
> dwarf or
> a tall long-haired female elf or whatever.
> If you are in a discussion with about 3 or 4 people whom you don't know it
> gets REAL garbled.
Well you'd expect that if you can only see their gender and race. But
even with a whole bunch of things in the description, I agree that it
would get difficult to follow group conversations. Maybe each player in
your vicinity could be given a color, or character symbol (!@#$%^&*), or
a number, and recycled as people enter or leave your vicinity. Hmmm, I
am clutching at straws here aren't I? :) *thinking.....*
> About the licensing stuff you are quite right. But then on the mud I am
> working if you do
> a real good disguise you could pose as somebody else. Even with the npc's.
> But thats
> quite hard to do and requires a lot of disguise skill.
Wouldn't it be nice if people of similar appearance had a better chance
of imitating each other? And if they had to put some real, relevant
effort into it, like finding matching clothing. All of this would come
about naturally if you completely dropped names from descriptions. I
think its preferable to killing 297 monsters so that you have enough exp.
or cash to train a disguise skill.
pa...@dict.mq.edu.au
In article <6bpg6b$qqo$1...@usenet88.supernews.com>,
thre...@counseltech.com (Threshold RPG) wrote:
> Personally, I would hate to play a game without names. In real life, how do
> you organize things like your personal address books. Do you have a section
on
> short, bearded men? No. You sort people by their names.
>
> Society CREATED names for the very purpose of being able to deal with each
> other in a far more organized fashion. Can you imagine having conversations
> with people if people didnt have names?
What, you think I'm going to go around with a big stick and beat people
if they dont refer to each other as "the one-eyed red-bearded dwarf"?
Having names in descriptions on a mud is *exactly* equivalent to people
in real-life wearing name tags. How did you learn the names of your
friends at the night club? Someone went and told you, you didn't
magically know just by looking at them. So whats the difference between
what I am suggesting and real life? The phone on my desk is known as
"Paul's phone". It doesn't have my name on it, and people certainly dont
say, "The phone on the desk with the chair that Paul usually sits on".
Steve Williams
Richard Woolcock wrote in message <34DFD1...@dial.pipex.comNOSPAM>...
>>
>> Simply put, because human memory is not that good. In terms of game
>
>Names play an important part in life, as well as on the mud. How many
>times has someone phoned you up and said "Hi, this is that tallish guy
>with long brown hair and a nose-ring who wears blue jeans and a white
>t-shirt"? Names are vital as points of referance.
>
>> is:
>>
>> | | | |
>> | | | +--taken from equipment list
>> | | |
>> | | +--taken from equipment list
>
>How would you decide which pieces of equipment to use?
Hmmm...you could prioritse the slots and use the two most prominent pieces
of equipment.
>
>> | |
>> | +--player is elven
>
>Does the viewer know what an elf is?
>
I think it would be fair to assume that most people would be able to pick
out racial traits similar to the way we pick out racial traits in our own
society.
>> |
>> +--player is 6'5"
>
>If I am playing a 20' giant, would the person still be 'tall'?
>
Interesting point. A comparison of heights?
>It isn't very hard to implement descriptions which vary from viewer
>to viewer. Your 'tall elf in chain main and a green cloak' might
>look like a 'little guy with pointed ears and a silver vest' to my
>giant. The only problem with this is that the descriptions would
>have to be determined every time you saw that person doing something
>- I'm not sure what sort of effect this would have on cpu usuage, but
>having to check their equipment to make the description every time
>couldn't help.
>
>KaVir.
What if you only updated the equipment part when someone changed something
they were wearing. For instance, if I take my vest off my description gets
updated. That way it's only being updated when needed.
The biggest problem I see with allowing players to set their OWN
descriptions is that you don't have any way of stopping them from changing
them constantly so that they are not recognized. This would be fine if they
needed some sort of skill roll in order to change their description once it
had been set. But even then it's kinda stretching it. I mean, it'd be
pretty difficult for your giant to disguise himself as being short. :)
Steve Williams
>> My Preferred Solution:
>> Everyone logs in using there real name or a unique OOC name they can then
>> choose which character they wish to player (or start another) and enter
>> the game, all in game commands use the introduction system and all OOC
>> commands use the OOC name so the who would list all the OOC names, not
any
>> information about who they were playing in character.
>(which shows up on global chat, 'who' and tells) and an IC name which is
>randomly determined and used for everything else. The trouble is that if
>I allow players to 'tag' a name onto someone, most people will either tag
>insulting names or just use that persons OOC name, which totally defies my
>objective of seperating OOC and IC. If it wasn't for this reason, I might
>well implement what you suggest.
>
>KaVir.
KaVir,
I'm actually surprised you see the insulting names as a problem.
Especially with the dimension it adds to the MUD. If I don't like my
neighbor and wish to refer to him in my own mind as "The Jerk" then so be
it. As for people assigning the OOC names, that's fixable too. Make the
OOC name a number. :) People are much better at remembering the difference
between KaVir and Darloth than they are at remembering the difference
between 2341 and 2431. See my point? This would also reduce the number of
bytes needed to store the CID significantly. As far as how they logon, they
have a logon name which is nothing MORE than a logon name. It shows up in
logs and it's used to log them on. Perhaps immortals are also able to see
this name, but never mortals. :)
Katrina McClelan
>>How would you decide which pieces of equipment to use?
>Hmmm...you could prioritse the slots and use the two most prominent pieces
>of equipment.
This could be stored in the item data as well as a numerical quantity, and
anything prominent enough to be noticed gets described. Additionally a
perception skill can INCREASE the detail level noticed at a glance. (some
people might notice that consealed dagger, while others completely
overlook it).
(keep in mind I post with the assumption of fresh code. Starting from
stock generates stock features with hackage over them and is not
reccomended for a breakthrough in innovation. Thus I tend to suggest
stuff that I fully intend to use the data structures and organization to
accomplish. :)
>>> |
>>> +--player is 6'5"
>>
>>If I am playing a 20' giant, would the person still be 'tall'?
>>
>Interesting point. A comparison of heights?
This can be done with percentages (he's 50% my height and thus a runt;
he's 500% my size... outright gigantic).
>What if you only updated the equipment part when someone changed something
>they were wearing. For instance, if I take my vest off my description gets
>updated. That way it's only being updated when needed.
You COULD, but the overhead for checking equipment (a loop of N=24) is
trivial given a quarter second game loop, even if done 30-50 times in that
game loop. (note, I have observed that a third second game loop is still
responsive enough to work).
>The biggest problem I see with allowing players to set their OWN
>descriptions is that you don't have any way of stopping them from changing
>them constantly so that they are not recognized. This would be fine if they
>needed some sort of skill roll in order to change their description once it
>had been set. But even then it's kinda stretching it. I mean, it'd be
>pretty difficult for your giant to disguise himself as being short. :)
Disguise would be a valid skill in a dynamically described introduction
based system (skill in disguise could "unintroduce" you).
-Kat
Nathan Fenenga Yospe
Katrina McClelan, is it true that on 10 Feb 1998 15:29:53 -0600, you
posted to rec.games.mud.admin:
: In <34E11B...@dial.pipex.comNOSPAM> Richard Woolcock
<Ka...@dial.pipex.comNOSPAM> writes:
: >Why not just use a single 32 bit integer? You could use the last bit to
: >represent if you knew them or not, and the rest of it to correspond to a
: >unique player id. Stored in a seperate binary file, this would take only
: >4 bytes of space per person you knew...
: Actually, you wouldn't need the sign bit if you're only storing who you
: know (you could tell by having a record or not). If you're storing
: everyone you need the sign bit, and 4 bytes per person in existance.
Of course, this gets more interesting if you weight it by familiarity,
frequency, and freshness. By this, I mean the following: a time stamp,
specifying the last meeting, a frequency count, averaging how often an
occurance said meetings are (and weighted to the difference between t0
and t for said stamp, so as to account for a suddenly increased rate),
and a familiarity value, probably either specified by the player, with
an alternative (that I use) being the duration of meetings between the
two players, on average. This still fits in under 8 bytes apiece. That
is even better if the storage is client-side on a non-telnet mud. This
allows some other interesting possibilities:
Bubba is secretly dissatisfied with his gender. He has been dressing
as a woman and going by the name Buffy. Boffo hangs out in the Green
Marine, the same bar as Bubba, but doesn't really know him too well.
Boffo has a serious crush on Buffy, who he met at the poodle museum.
One night, Boffo ends up in a card game with Bubba. Suddenly, he has
a startling insight...
: >Won't this cause memory fragmentation if people are being constantly added
: >and removed from memory?
: Yes, and no.... if you have a free_blah() function that collects unused
: memory in a stack and a malloc_blah() that checks to see if you have a
: block availible on that stack you tend to fill in the gaps.
With a client side storage, this is more of a problem. How do you know
if someone has died? Would you want to delete them even if they had? I
expect you would still remark on similarities...
You stop, and your heart thuds hard. A woman with pale blue hair and
silver eyes peers up at you, her face exactly like that of your dead
wife Loena. She frowns and hands you a cup. "Fill this, please," she
instructs you. I second glance dispells her resemblance to Loena.
: >The person I responded to was a diku owner, and I just followed the cross
: >post. I try to realloc as little as possible (my allocated recognition
: >blocks just get moved onto a 'free' list when people quit, ready to be
: >reused).
: Heh... didn't realize you already use the same scheme I just mentioned :)
: -Kat
I do a lot of virtual allocation - use of space from a previously set,
page-sized block. I'm still playing around with other memory solutions
that don't result in so much unused allocated memory.
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe#hawaii.edu nyospe#premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/
Richard Woolcock
pa...@dict.mq.edu.au wrote:
>
> In article <6bpg6b$qqo$1...@usenet88.supernews.com>,
> thre...@counseltech.com (Threshold RPG) wrote:
> > Personally, I would hate to play a game without names. In real life, how
> > do you organize things like your personal address books. Do you have a
> > section on short, bearded men? No. You sort people by their names.
> >
> > Society CREATED names for the very purpose of being able to deal with each
> > other in a far more organized fashion. Can you imagine having conversations
> > with people if people didnt have names?
>
> What, you think I'm going to go around with a big stick and beat people
> if they dont refer to each other as "the one-eyed red-bearded dwarf"?
> Having names in descriptions on a mud is *exactly* equivalent to people
> in real-life wearing name tags. How did you learn the names of your
> friends at the night club? Someone went and told you, you didn't
> magically know just by looking at them. So whats the difference between
> what I am suggesting and real life? The phone on my desk is known as
Because in real life, once you know someone's name there is no confusion
over who they are. How many unique descriptions can you think of for an
elf? Sure, you should see a description until you know their name - that
is the whole point of this discussion. But once you know the persons name,
its extremely confusing to just see 'an elf' or whatever, and not know if
it's your friend Bubba the Elf, or the evil fiend Boffo the Elvan cannibal.
With no way to uniquely label other people, the social element of the mud
dies, and with it the main advantage of muds over other computer games.
> "Paul's phone". It doesn't have my name on it, and people certainly dont
> say, "The phone on the desk with the chair that Paul usually sits on".
Object recognition is another area altogether.
KaVir.
Richard Woolcock
David Trott wrote:
>
[snip]
> An Idea:
>
> Abolish in character names as such and replace them with a unique character
> id - CID (just an integer). When you meet some one you do not know, you get
> a general description, this is generated according to the preferred method
> on the mud. Instead of the person introducing themselves with a command
> they can simply say 'Hello I am bill' with a normal say or similar command.
> Then you can use a command to assign a short and long description, these
> are saved as part of your player object. If I set Bill's short description
> to "bill" and Bill's long to "LOUD BILL" next time I see him his
> description it will say "LOUD BILL an orc" and I can use the short that I
> have set to reference him, e.g. "give axe to bill".
[snip]
> My Preferred Solution:
> Everyone logs in using there real name or a unique OOC name they can then
> choose which character they wish to player (or start another) and enter
> the game, all in game commands use the introduction system and all OOC
> commands use the OOC name so the who would list all the OOC names, not any
> information about who they were playing in character.
[snip]
John Adelsberger
Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote regarding intro systems:
: If disk space became a problem I would use binary files. If you only
: want to know if you know the person or not, then 4 bytes would easily
: suffice per player per player (just store an id for the people you know).
: If there were 1000 players, and everyone knew each other, that would
: take up less than 4 meg of disk space.
Lets assume that I want to allow every player to have one of the set
<UNKNOWN, SEEN_BEFORE, FAMILIAR, FRIEND> each of which is represented
by an integer(a 4 byte quantity, herein) to represent his relation to
each and every other player. If there are 5000 players total, which
is more than any mud I'm familiar with, save commercial garbage, each
player then needs 4999 bytes of storage, plus one for the size of the
array or a null terminator, and you end up with 5000 x 5000 = 25 megs.
Frankly, 25 megs of disk is an hour's pay these days, or less. In
addition, this implementation was DELIBERATELY chosen to SUCK for
efficiency.
Writing in C seems to convince most people that EVERYTHING is an
efficiency concern. This is not true. Almost nothing in a mud
is an efficiency concern. Get over it.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
pa...@dict.mq.edu.au
In article <34E160...@dial.pipex.comNOSPAM>,
Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
....
> Because in real life, once you know someone's name there is no confusion
> over who they are. How many unique descriptions can you think of for an
> elf? Sure, you should see a description until you know their name - that
> is the whole point of this discussion. But once you know the persons name,
> its extremely confusing to just see 'an elf' or whatever, and not know if
> it's your friend Bubba the Elf, or the evil fiend Boffo the Elvan cannibal.
> With no way to uniquely label other people, the social element of the mud
> dies, and with it the main advantage of muds over other computer games.
I can think of about 12,000 straight up, using body shape, gender, hair
style, hair color, and facial features. That doesn't include races,
clothing, or adjectives of the player's own choosing. For more detail,
just look at the person. My post wasn't that clear. What I was trying
to get at is that in real-life you identify someone by their appearance.
You can also identify someone by a written description of their
appearance. Of course you still know them by name. Its hard to imagine,
since very few muds have such detailed one-line descriptions. Yeah, it
will get confusing at times, but I tend to think it will mostly add to
the game. I guess it depends on what you are aiming for in a mud.
> Object recognition is another area altogether.
People are objects.
Katrina McClelan
>People are objects.
If I ever get the motivation (and time) to do it, I have toyed with the
idea of treating EVERYTHING as objects, and defining how they react with
other objects in terms of colisions. Sword coliding with player would
damage player. Sword coliding with lava might melt the sword. Sword
coliding with granite could shatter it. player colides with player both
might take damage. player colides with ground (aka falls) and the ground
wins. etc etc. In this even spell effects, such as fireballs would be
objects that colide with everything until the energy is consumed (although
coliding with combustables could lengthen affect, but hitting a water
elemental could totally absorb the blast). You can have toxic gases,
smells, and explosive vapors (all objects). Smells would just disapate
gradually (and spread for that matter), toxic gases would be able to
damage living objects as they passed. explosive vapors could be nasty if
they collide with a torch. You could have spells that gave life to any
object (animate rock, animate steel etc) since all it'd be is setting a
behavior other than non-living. Overall it's a very flexible and elegant
system.
This hierchy also allows for
stuff like players (who are objects) to climb into other objects:
a fireball errupts down the hall heading towards you.
->enter coffin.
You climb inside the coffin.
->
The insides of the coffin get very warm, making you uncomfortable.
->exit of coffin.
(abbrieviated room desc in which all objects in room show results
of coliding with the blast and are described accordingly)
The ugly part would be the handler for object collisions. Once this is
donw however, it all is a matter of how object X collides with object Y.
The only other concern would be that you'd NEED dynamic descriptions that
described surrounding objects (keep in mind, the ground, the cave walls,
the lake, the trail, the forest cabin all objects... note that this DOES
imply that you can change your surroundings. blast a hole in the ground,
disintegrate the cave wall, leave tracks in the muddy trail, burn the
forest cabin. Why the heck not?)
Anyway, just some incesant ramblings since you mentioned the notion of
players being objects. I wonder if I'll ever get around to coding such a
server. It'd be neat, albiet it does strike a resemblence to Physmud, as
was described by Nathan (?) a while back int he coordinate thread, but
then I've never seen Physmud to verify this. I don't think (based on the
descriptions) that Physmud went to the extreme that EVERYTHING was an
object and no other game mechanics existed, but I do know that the
general object approach to world structure and dynamicly changing it
applied.
-Kat
Alberto BARSELLA
Katrina McClelan <kit...@directcheck.aries.net> writes:
> If I ever get the motivation (and time) to do it, I have toyed with the
> idea of treating EVERYTHING as objects, and defining how they react with
> other objects in terms of colisions. Sword coliding with player would
> damage player. Sword coliding with lava might melt the sword. Sword
> coliding with granite could shatter it. player colides with player both
> might take damage. player colides with ground (aka falls) and the ground
> wins. etc etc.
Well....it doesn't sound like a truly original idea. I mean, reality
already works like this ;)
If you go for this kind of approach you should use physics to model
the world, after all physicists spend most of their time creating
models which describe reality, so you can use those theories as a
starting point (I think Physmud does this, but was it released?).
>[.......] Overall it's a very flexible and elegant
> system.
I tried to design such a system (design and not code, note), but you
immediately hit another problem which is not that easy to solve:
composite objects.
In a "classical" mud you can have a halberd which is a single object,
but in this system you can't, since you have to model it as composed
of (at least) two main parts: the wood shaft and the iron head, which
have completely different physical properties. A method to deal with
"object parts" becomes fundamental, as well as the ability to separate
and recombine parts.
Even worse: a branch can be burning on one side and NOT burning on the
other, so even for homogeneous objetcs you need to either allow
non-uniform "properties" or to artificially split the object into
subparts to allow some effect.
Yet worse: any composite object can't be simply specified as part A +
part B, since many different variations can exist for the same
object. Size can change, and also some parts may play different roles
depending how they relate to other parts. You then need some kind of
"abstract object template" which says, for example, that an halberd is
the result of putting a metal head on a long wooden shaft. Or maybe
something which looks like a head on something which looks like a
shaft.
Then you need to have a command parser capable of dealing with
this.....
Returning for a moment to introductions and "players are objects"
approach I have tried to design an approach which completely removes
ANY description from ANY object, and arranges everything so that the
result is based on the interpretation of the observer. Let me explain:
you don't have an elf. You have a living being with a certain shape
and features and colors and etc.etc.etc.
Another player (mob?) looking at this "object" takes the "abstact"
description (which is just a list of values, describing the
appearence) and searches the "players' memory" trying to find the
object which matches more closely the abstract description.
The text is then generated according to this description.
This is an interesting apporach, which automatically permits
introductions, "unknown objects" (an elf seeing "a powerful laser
weapon is here"!?!?) and environment descriptions which are totally
dependent on the player. Problem: "exact" matches on the abstract
description aren't good enough to model memory loss or "stupidity" (do
you really think that a troll is able to tell an elf from another at
first sight? You then end up with a server which spends 99% of its
time performing "fuzzy" queries on the players' memory databases.
The "amount of fuzzyness" can also be dependent on the time devoted to
the description generation. If you enter a room and auto-look aroun
you just get the rough details and might miss object and or distiction
between people. If you examine someone you narrow the ranges and you
get more chances to really recognize him. If you examine someone
carefully you go even into deeper detail. The player can then
manipulate the database "remembering" things either by explicit
command "call dagger the sharp pointy metallic object" or by
inherining racial/guild/profession knowledge.
And what about applying it to rooms/areas? The first time you enter a
city how can you tell that this is the "merchant street" if you are
unable to read all the signs because they are written in a different
language? And will you be able to recognize it at night?
And what if you think you're on the opposite side of the world but you
got teleported? And what if the city gets levelled by a nuke?
The two approaches (i.e. "physical description" of the world together
with "all descriptions come from observer") theoretically allow the
construction of the world by the players. You can create arbitrary new
object with arbitrary uses (you'll need a GOOOOOOD object interaction
model for this), which every player may recognize with different
names. While the potential for such a thing is awesome, also the
coding difficulties tend to be awesome (let's face it, I dropped the
whole idea....).
If someone is insane enough to try and good enough to actually build
itlet me know.....I'll gladly play there :)
Alberto
--
Alberto BARSELLA
PGP fingerprint = 13 3F 22 D2 0B 0A D3 25 F1 89 FE B5 82 AD 75 2A
** Beliefs are dangerous. Beliefs allow the mind to stop functioning.
A non-functioning mind is clinically dead. Believe in nothing... **
David Trott
Steve Williams <dwo...@erols.com> wrote in article
<6bqrrd$9ud$1...@winter.news.erols.com>...
I Wrote:
> >> My Preferred Solution:
> >> Everyone logs in using there real name or a unique OOC name they can
then
> >> choose which character they wish to player (or start another) and
enter
> >> the game, all in game commands use the introduction system and all OOC
> >> commands use the OOC name so the who would list all the OOC names, not
> any
> >> information about who they were playing in character.
KaVir Wrote:
> >This is similar to the system I use, except that players get an OOC name
> >(which shows up on global chat, 'who' and tells) and an IC name which is
> >randomly determined and used for everything else. The trouble is that
if
> >I allow players to 'tag' a name onto someone, most people will either
tag
> >insulting names or just use that persons OOC name, which totally defies
my
> >objective of seperating OOC and IC. If it wasn't for this reason, I
might
> >well implement what you suggest.
> >
> >KaVir.
>
> KaVir,
> I'm actually surprised you see the insulting names as a problem.
> Especially with the dimension it adds to the MUD. If I don't like my
> neighbor and wish to refer to him in my own mind as "The Jerk" then so be
> it. As for people assigning the OOC names, that's fixable too. Make the
> OOC name a number. :) People are much better at remembering the
difference
> between KaVir and Darloth than they are at remembering the difference
> between 2341 and 2431. See my point? This would also reduce the number
of
> bytes needed to store the CID significantly. As far as how they logon,
they
> have a logon name which is nothing MORE than a logon name. It shows up
in
> logs and it's used to log them on. Perhaps immortals are also able to
see
> this name, but never mortals. :)
In my prefered solution it was my intent that any real person would only
have
one OOC name that they could log on to the mud with, once they had logged
in they would have a selection of characters each with there own CID (an
integer) to choose from. The would choose one and start to play, if they
choose not to disclose anything about there identity it would be impossible
for another player to work out that they were not an NPC (assuming there
actions also looked like NPC actions), hence not possible to work out which
OOC char they were. They could still carry on with any OOC conversations
since they would be refered to by there OOC name.
On the other hand if I was playing I could give out my IC name and assuming
that there were enough players on to disguise my identity (eg two players
on, would kind of give it away), there would still be no way for the person
I was introducing myself to to know which OOC person I am.
Finally if I log in as John and I want all my characters to be known as
John then I can go arround telling everyone that I am John anyway so I
don't see a problem letting people introduce themselves as there OOC name
if they want, its just that I personally would not want to.
With this in mind I think it is necessary to leave OOC names as names so
that OOC conversations are sensible.
Threshold RPG
In article <887178539...@dejanews.com>, pa...@dict.mq.edu.au wrote:
>I can think of about 12,000 straight up, using body shape, gender, hair
>style, hair color, and facial features.
What is easier to remember:
1) A 5 foot 9 inch tall male being with pointed ears, an upturned nose, brown
eyes that are oval shaped, slightly sandy colored hair that is wavy and
shoulder length, a mesomorph body type with a 40 inch chest, 20 inch biceps, a
waitline about 32 inches, very pronounced cheekbones, a square jaw, and
dimples.
Or:
2) Bob
In a text based environment, a goal is to simply things so people can actually
handle the miasma of text information they are bombarded with. You dont spam
them with a heap of pointless text when all they really want to know is: "Is
this Bob or someone else"
If they want all the details, they can look at the person.
Richard Woolcock
Steve Williams wrote:
>
[snip]
> I'm actually surprised you see the insulting names as a problem.
> Especially with the dimension it adds to the MUD. If I don't like my
> neighbor and wish to refer to him in my own mind as "The Jerk" then so be
> it. As for people assigning the OOC names, that's fixable too. Make the
> OOC name a number. :) People are much better at remembering the difference
> between KaVir and Darloth than they are at remembering the difference
> between 2341 and 2431. See my point? This would also reduce the number of
Yes, but each time my players die they come back with a new IC name - then
have to remeet everyone. With this system, people would just tag everyone
with the same name through all their various incarnations.
> bytes needed to store the CID significantly. As far as how they logon, they
> have a logon name which is nothing MORE than a logon name. It shows up in
> logs and it's used to log them on. Perhaps immortals are also able to see
> this name, but never mortals. :)
Perhaps, but people would still want to be called by their login name most
of the time. This would detract from the roleplaying aspect, as people
very rarely chose appropriate names (I have a modern day theme).
KaVir.
Richard Woolcock
pa...@dict.mq.edu.au wrote:
>
> In article <34E160...@dial.pipex.comNOSPAM>,
> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
[snip]
> > Object recognition is another area altogether.
>
> People are objects.
Don't be pedantic. A player/mobile is a representation of an animate
living thing, an object is something you can pick up and use, wear, etc.
People are unique, objects are not (usually). Suppose your character
walks into a room and see's a sword - what should you see? A long piece
of silver-coloured stuff? A sharp piece of metal with a handle on the
end? A steel sword? A well-balanced steel cutlass? Surely this depends
on your characters knowledge of weaponry rather than whether or not you've
seen that object before? Of course, I suppose someone could always tell
you what an object is...or maybe you could tag names onto objects too?
KaVir.
Richard Woolcock
John Adelsberger wrote:
>
> Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote regarding intro systems:
>
> : If disk space became a problem I would use binary files. If you only
> : want to know if you know the person or not, then 4 bytes would easily
> : suffice per player per player (just store an id for the people you know).
> : If there were 1000 players, and everyone knew each other, that would
> : take up less than 4 meg of disk space.
[snip]
> Frankly, 25 megs of disk is an hour's pay these days, or less. In
> addition, this implementation was DELIBERATELY chosen to SUCK for
> efficiency.
>
> Writing in C seems to convince most people that EVERYTHING is an
> efficiency concern. This is not true. Almost nothing in a mud
> is an efficiency concern. Get over it.
The disk space is not of major concern to me, although I do prefer to
avoid sloppy coding techniques - maybe thats just personal preferance?
Of course I don't work on commercial software, and - I can assure you -
when developing realtime embedded software in the aerospace industry,
efficiency is very important. But then I'm sure you knew that already.
I wrote the bit about optimising hd usage in responce to the following
from John Viega:
think "really horrible" is too harsh. In your example, you'd be
storing on disk 125 bytes per player, which over 1000 players would be
about 120K. As your mud gets larger, That's not bad if you've got a
fair bit of disk space devoted to the mud, since most of the info is
I just wanted to point out that should the space be a problem, it can
easily be avoided. For a lot of people, such space IS a problem - if
you don't own the machine, you can hardly stick a spare drive on it.
KaVir.
John Adelsberger
Katrina McClelan (kit...@directcheck.aries.net) wrote:
: >People are objects.
: If I ever get the motivation (and time) to do it, I have toyed with the
: idea of treating EVERYTHING as objects, and defining how they react with
In C?:-) (Yes, it can be done... no, there is no point in using C...)
: other objects in terms of colisions. Sword coliding with player would
: damage player. Sword coliding with lava might melt the sword. Sword
: coliding with granite could shatter it. player colides with player both
: might take damage. player colides with ground (aka falls) and the ground
: wins.
...
: The ugly part would be the handler for object collisions. Once this is
: donw however, it all is a matter of how object X collides with object Y.
Ugly isn't what bothers me. You'd essentially have to simulate the entire
world at the level of, at a minimum, blobs of like material. To put it
mildly, this would be one of the few mud systems that could really eat
a machine alive. I suspect N. Yospe may have some ideas, though.
Nathan Fenenga Yospe
Katrina McClelan, is it true that on 11 Feb 1998 01:20:55 -0600, you
posted to rec.games.mud.admin:
: >People are objects.
Yes. Note: modify this to "A person is objects."
: If I ever get the motivation (and time) to do it, I have toyed with the
: idea of treating EVERYTHING as objects, and defining how they react with
: other objects in terms of colisions. Sword coliding with player would
: damage player. Sword coliding with lava might melt the sword. Sword
: coliding with granite could shatter it. player colides with player both
: might take damage. player colides with ground (aka falls) and the ground
: wins. etc etc. In this even spell effects, such as fireballs would be
: objects that colide with everything until the energy is consumed (although
: coliding with combustables could lengthen affect, but hitting a water
: elemental could totally absorb the blast). You can have toxic gases,
: smells, and explosive vapors (all objects). Smells would just disapate
: gradually (and spread for that matter), toxic gases would be able to
: damage living objects as they passed. explosive vapors could be nasty if
: they collide with a torch. You could have spells that gave life to any
: object (animate rock, animate steel etc) since all it'd be is setting a
: behavior other than non-living. Overall it's a very flexible and elegant
: system.
Katrina seems to be nudging toward the slippery road I headed down a long
time ago. A warning... once you get even a partial implementation of this
running, you will never be satisfied with the normal approach. As for the
potentials... you've got a good start. A few more points: Synthesis. This
is one of the best parts... it allows the inclusion of smiths, of alchemy
and chemistry, of real crafts. Detail Generation. This is the true secret
of a purely object based system. Objects have some references used to set
details when a player looks closely. Skin generates scars, sands, grains.
Collisions are handled top down, and a spherical detection can become one
using detailed frames when a potential collision is detected. Assembly. A
more detailed extension of your animation spell - graft a golem arm where
you lost your own in a battle. Or cybernetics in a tech game.
: This hierchy also allows for
: stuff like players (who are objects) to climb into other objects:
Yes. This was actually the first thing that led to my eventually adopting
and developing a purely object based system. My heirarchy of containment,
encapsulation, and physical collision objects was getting way out of hand
for a while, and then it suddenly dawned on me that I was going the wrong
direction, adding complexity instead of consolidating uniformity.
: a fireball errupts down the hall heading towards you.
: ->enter coffin.
: You climb inside the coffin.
: ->
: The insides of the coffin get very warm, making you uncomfortable.
: ->exit of coffin.
: (abbrieviated room desc in which all objects in room show results
: of coliding with the blast and are described accordingly)
I have posted a few scenarios and clips from earlier versions of Physmud,
but one of my favorites (It should be in deja news somewhere.) involved a
guy getting placed in a sack and dumped at the top of a cliff. Wiggle off
and ... whee!
: The ugly part would be the handler for object collisions. Once this is
: donw however, it all is a matter of how object X collides with object Y.
Advice: use local coordinate systems, spherical collision detection, with
cluster tracking instead of individual object tracking (I have a library,
if you are interested, though it is in Fortran for one version, C++ for a
more advanced version... this is what I do professionally.) and a refined
check upon possible collision.
: The only other concern would be that you'd NEED dynamic descriptions that
: described surrounding objects (keep in mind, the ground, the cave walls,
: the lake, the trail, the forest cabin all objects... note that this DOES
: imply that you can change your surroundings. blast a hole in the ground,
: disintegrate the cave wall, leave tracks in the muddy trail, burn the
: forest cabin. Why the heck not?)
Well, the overhead, for one thing. I ended up moving all of that to a big
offline client, which is what's holding me up now... dynamic descriptions
can get very intense, especially if memory and emotional conotation are a
consideration. But, yes, it is worth it, and when this is all done, will,
in fact, be very, very, very worth the effort.
: Anyway, just some incesant ramblings since you mentioned the notion of
: players being objects. I wonder if I'll ever get around to coding such a
: server. It'd be neat, albiet it does strike a resemblence to Physmud, as
: was described by Nathan (?) a while back int he coordinate thread, but
: then I've never seen Physmud to verify this. I don't think (based on the
: descriptions) that Physmud went to the extreme that EVERYTHING was an
: object and no other game mechanics existed, but I do know that the
: general object approach to world structure and dynamicly changing it
: applied.
Oh, it has, and continues, to go to such extremes. As a matter of fact, a
good two years ago it was a standard mud, from scratch, with some new and
innovative design features, but nothing so grand. Like a couple of others
out there (MUD++, from what I've seen of early and recent versions) it is
no longer even remotely similar to its origins. I still have seven of the
early versions. (Eleven counting the incompletes and the Rom derivative.)
Each version is pretty much a rewrite from scratch. None of the versions,
Rom exclusive, satisfied me enough to write a running game on it, or find
all the bugs and iron them out. This is a long, possibly endless road, in
that I will perhaps occasionally let a couple of people play with the new
version in progress, and if they want it, fine, but my own version, well,
that will perhaps never meet my vision for it.
: -Kat
Nathan Fenenga Yospe
John Adelsberger, is it true that on 11 Feb 98 19:39:35 GMT, you posted
to rec.games.mud.admin:
: Katrina McClelan (kit...@directcheck.aries.net) wrote:
: : If I ever get the motivation (and time) to do it, I have toyed with the
: : idea of treating EVERYTHING as objects, and defining how they react with
: In C?:-) (Yes, it can be done... no, there is no point in using C...)
Let's not go there. I use C++, Java for the client; Kat uses C. You use
LPC (or is is ColdX now? If it is, I have some news for you...) but the
real point remains, we're dealing algorithms and strategies by this far
point. I'm almost tempted to resort to Fortran occasionally. No, I will
be honest, I _do_ resort to Fortran, then manually translate to C++.
: : other objects in terms of colisions. Sword coliding with player would
: : damage player. Sword coliding with lava might melt the sword. Sword
: : coliding with granite could shatter it. player colides with player both
: : might take damage. player colides with ground (aka falls) and the ground
: : wins.
: ...
: : The ugly part would be the handler for object collisions. Once this is
: : donw however, it all is a matter of how object X collides with object Y.
: Ugly isn't what bothers me. You'd essentially have to simulate the entire
: world at the level of, at a minimum, blobs of like material. To put it
: mildly, this would be one of the few mud systems that could really eat
: a machine alive. I suspect N. Yospe may have some ideas, though.
Yes and no. I wouldn't know how to optimize enough to handle this level
of detail. Frankly, I find the idea of reducing the game world to blobs
of like material rather insane. Now, having the potential to evaluate a
specific object down to said blobs... that's a good idea. I wrote a bit
more in my reply to Kat, but the sum of it is, simulate it as little as
you can. Leave most of the simulation as a macroscale process, and then
use a microscale generator with a common seed to resolve. Physics has a
long history of doing this, and it has always worked for us. It is more
a matter of finding a way to consider groups of particles as one fluid,
than one of handling every particle in a fluid. And it is possible. Not
easy, and I'm far from finished (But I only spend a couple of hours per
week on Physmud, and most of that is design...), but it is possible.
Nathan Fenenga Yospe
Richard Woolcock, is it true that on Wed, 11 Feb 1998 19:48:11 -0800, you
posted to rec.games.mud.admin:
: pa...@dict.mq.edu.au wrote:
: > In article <34E160...@dial.pipex.comNOSPAM>,
: > Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
: > > Object recognition is another area altogether.
: > People are objects.
: Don't be pedantic. A player/mobile is a representation of an animate
: living thing, an object is something you can pick up and use, wear, etc.
: People are unique, objects are not (usually). Suppose your character
: walks into a room and see's a sword - what should you see? A long piece
: of silver-coloured stuff? A sharp piece of metal with a handle on the
: end? A steel sword? A well-balanced steel cutlass? Surely this depends
: on your characters knowledge of weaponry rather than whether or not you've
: seen that object before? Of course, I suppose someone could always tell
: you what an object is...or maybe you could tag names onto objects too?
And what if you have a beetle race? How do people know that they are the
nefarious Krat'chtar, the first time they see them? Or class of objects?
Swords and elves are the same thing. Your own trusty Grimhaather and the
fair Helen, who you know well, are a similar situation. Why are these in
any way different? Their level of animation? Surely the enchanted wooden
golem is as much 'object' as 'person'? Why diferentiate? (Aside from the
fact that you have no offline client to hold all the vast information in
each character's experience... see why I chose a client?)
John Adelsberger
Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote:
: John Adelsberger wrote:
: > Frankly, 25 megs of disk is an hour's pay these days, or less. In
: > addition, this implementation was DELIBERATELY chosen to SUCK for
: > efficiency.
: >
: > Writing in C seems to convince most people that EVERYTHING is an
: > efficiency concern. This is not true. Almost nothing in a mud
: > is an efficiency concern. Get over it.
: The disk space is not of major concern to me, although I do prefer to
: avoid sloppy coding techniques - maybe thats just personal preferance?
There is nothing sloppy about the method I suggested - it sucks compared
to other methods in terms of efficiency, but it doesn't NEED to be
efficient, and this was the sole point.
: Of course I don't work on commercial software, and - I can assure you -
: when developing realtime embedded software in the aerospace industry,
: efficiency is very important. But then I'm sure you knew that already.
What does realtime embedded avionics work have to do with muds? If you'll
note, above, I said 'Almost nothing in a mud is an efficiency concern.'
I admit, if your mud runs an F-15's avionics package, you probably need
more concern for efficiency, but why do I doubt this?
Marian Griffith
In article <6bpg6b$qqo$1...@usenet88.supernews.com>, Threshold RPG
<URL:mailto:thre...@counseltech.com> wrote:
> In article <887090612....@dejanews.com>, pa...@dict.mq.edu.au wrote:
> >Obviously I was talking about the player interface. Yes, for admin
> >purposes, names are very useful, and I wouldn't suggest dropping them.
> >Your players need to identify themselves when they log in, and your
> >implementation would have some sort of identification key. But your
> >players don't need it. Does it matter if I cant remember the names of
> >the seven dwarfs, or a room full of people I just met?
> Personally, I would hate to play a game without names. In real life, how do
> you organize things like your personal address books. Do you have a section
> on short, bearded men? No. You sort people by their names.
> Society CREATED names for the very purpose of being able to deal with each
> other in a far more organized fashion. Can you imagine having conversations
> with people if people didnt have names?
Actually, you do use descriptions far more often than most people realise.
How many people do you know by name that the person you're talking to also
knows by name? In many cases you have to revert to providing some physical
clues to clarify which third person you're talking about.
I'm not recommending to do away entirely with names, but it makes sense to
provide a way to distinguish players and monsters by description as well
as by name. Names are for people you're introduced to. Descriptions can be
the default means for recognition.
Marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...
Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey
Marian Griffith
In article <6bo2sr$2...@cegt201.bradley.edu>, Katrina McClelan
<URL:mailto:kit...@directcheck.aries.net> wrote:
> >> Personally I'd not let players save descriptions... I'd descibe them as
> >> is:
> >> a tall elf in chain main and a green cloak arrives from the south.
> >> ^ ^ ^ ^
> >> | | | +--taken from equipment list
> >> | | |
> >> | | +--taken from equipment list
> >How would you decide which pieces of equipment to use?
> Actually, I hadn't had time to consider that. I'd come up with a way.
> The p[oint is the data is there to use.
A simple ranking system would work well. Anything that is out of the
ordinary, is out of character with the rest of the equipment or is
plainly visible would get higher rank. Then pick the two or perhaps
three with the highest rank and use those in the description along
with the things that actually help identify somebody. Like gender,
size, colour of hair and eyes and general shape of the face. By now
you have of course quite a story to write just to identify someone.
> >> | +--player is elven
> >Does the viewer know what an elf is?
> Perhaps not. I could change the string for how to describe an elf, but
> the thing is the PLAYER should know even if the character doesn't so it
> should suffice.
For simplicities sake alone would it be acceptable to assume players
know about other races and can recognise one on sight. In reality it
would not be too much to assume the same, because everybody in that
world would have picked up sufficient clues from stories and songs.
> >> +--player is 6'5"
> >If I am playing a 20' giant, would the person still be 'tall'?
> No, but if the player types his own description he is.
Actually, why not make the description relative to the size of the
average elf. To the giant -everybody- is going to be small or tiny
so using descriptions relative to the size of the onlooker is not
very usefull. You can always put in more extensive relative sizes
in things like examine commands (the giant would get something in
the line of: the elf is reaches to somewhat above your knee).
> >It isn't very hard to implement descriptions which vary from viewer
> >to viewer. Your 'tall elf in chain main and a green cloak' might
> >look like a 'little guy with pointed ears and a silver vest' to my
> >giant.
Not to mention the fact that a thief might find other things inter-
esting than the warrior. The first might immediately notice the fat
bulging purse and the swaying step, while the warrior might see the
expensive sword and armour.
Richard Woolcock
John Adelsberger wrote:
>
> Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote:
> : John Adelsberger wrote:
>
> : > Frankly, 25 megs of disk is an hour's pay these days, or less. In
> : > addition, this implementation was DELIBERATELY chosen to SUCK for
> : > efficiency.
> : >
> : > Writing in C seems to convince most people that EVERYTHING is an
> : > efficiency concern. This is not true. Almost nothing in a mud
> : > is an efficiency concern. Get over it.
>
> : The disk space is not of major concern to me, although I do prefer to
> : avoid sloppy coding techniques - maybe thats just personal preferance?
>
> There is nothing sloppy about the method I suggested - it sucks compared
> to other methods in terms of efficiency, but it doesn't NEED to be
> efficient, and this was the sole point.
You said that almost nothing is a mud is an efficiency concern, I simply
stated that just because it isn't doesn't give an excuse for sloppy coding.
I am used to restrictions of ram/cpu/hd space, and so I try to optimise as
much as possible.
KaVir.
John Adelsberger
Nathan Fenenga Yospe <yo...@Hawaii.Edu> wrote:
: Let's not go there. I use C++, Java for the client; Kat uses C. You use
: LPC (or is is ColdX now? If it is, I have some news for you...) but the
: real point remains, we're dealing algorithms and strategies by this far
: point. I'm almost tempted to resort to Fortran occasionally. No, I will
: be honest, I _do_ resort to Fortran, then manually translate to C++.
I use LPC generally for muds, but C++ or anything else OO is sensible, if
not in every case ideal. I use C for most other things. Procedural
language use in the development of an object system is just plain silly,
though:-) Whats the news for Cold, anyway?
: : Ugly isn't what bothers me. You'd essentially have to simulate the entire
: : world at the level of, at a minimum, blobs of like material. To put it
: : mildly, this would be one of the few mud systems that could really eat
: : a machine alive. I suspect N. Yospe may have some ideas, though.
: Yes and no. I wouldn't know how to optimize enough to handle this level
: of detail. Frankly, I find the idea of reducing the game world to blobs
: of like material rather insane. Now, having the potential to evaluate a
: specific object down to said blobs... that's a good idea. I wrote a bit
I knew you used a representation that was in itself an optimization, but
I didn't know how it worked.
Richard Woolcock
Okay you have a valid point, however I still believe that in the majority
of situations such recognition would not be required for physical inanimate
objects, or else the recognition would apply to a whole class of thing -
eg, if someone points out that your sword is actually a cutlass, you should
recognise every cutlass from that point on (assuming you didn't have enough
Sword Knowledge/whatever to recognise it in the first place). Hmmm on
second thoughts I suppose this does apply to objects as well as players...
perhaps then, recognition should be for either:
* Class of thing: While everyone knows that there is a tree in your back
garden, only those who are 'in the know' recognise it as an old oak tree.
That creature charging towards you might well be big green and ugly, but
you also recognise it as a fearsome orc. Such recognition should be
attainable either from skills, from someone pointing it out to you, or
from study.
* Individual thing: Most people realise that the sword you're carrying is
a very ancient greatsword, but only you and a few others recognise it as
the dreaded 'DeathKiss', supposedly crafted by Satan himself. Most of
the adventuring party realise that there is a fearsome orc running towards
you, but you are the only one who realises that its Gord, the Orcish
Warlord, who personally slew 5 mudschool monsters. Such recognition
should only be attainable from someone pointing it out to you or intensive
study.
I still maintain, however, that object recognition would *usually* be only
applied to classes of thing.
KaVir.
Nathan Fenenga Yospe
Richard Woolcock, is it true that on Thu, 12 Feb 1998 19:32:03 -0800, you posted to rec.games.mud.admin:
: Nathan Fenenga Yospe wrote:
<objects =?= characters>
: > And what if you have a beetle race? How do people know that they are the
And suddenly this goes into a new and very, very, very significant area.
Recognition of class is a multilayered problem, as if it weren't complex
enough. First you have the hierarchy of greater detail of classes - both
items and characters, to use the terms that I used to employ... and then
you have the overlap of cultural references. For example, we have Bubba:
Bubba the troll has three long metal objects. Bubba holds one up and
mouths the sound "skee pohl". Bubba holds up the second one and says
something that sounds like "skimeetawr". Bubba holds up the third, a
similar object to the skimeetawr, and says, "Behold, Breathbringer."
How would one learn the difference? Now assume the player does know what
a sword is... would the player nescicarily class a four foot long plasma
arc as a sword? Or not cast it as one? How about a Puihi? That's a flat,
wooden blade with shark and dog teeth on the edge. Heck, _I_ don't know,
and I'm intimately familiar with both the cultural references and swords
in general, and have held both weapons. It swings a bit like a sword, if
a little high on the drag, but it isn't made of metal. Is a kendo staff?
A wooden training katana? Neither of these is made of metal, but they do
handle like swords. Do we choose to interpret such an object as a wooden
sword? A wooden sword with teeth in the edge? Or do we leave it up to an
object's designer to create the last few elements of the hierarchy? With
an abstract base class or two, a Socratic perfection of form, we can, in
fact, allow builders to inherit everything about an object that would be
"recognizable", both in function and in form. This is the best solution,
in my opinion. The problem is, it then makes the interpretation of every
player with the same knowledge identical. It would be nice if there were
a way to introduce an interpretation fudge factor (and then blow it into
a massive value for the insane, philosophical, and poetic.) I dunno. You
have given me some things to think on now. I think I like it, thank you.
Ryan Haksi
> > Personally I'd not let players save descriptions... I'd descibe them as
> > is:
Hmm I think players like being able to type in their own description and
as such my own mud will remain the way it it :-), on the other hand I
thought this idea seemed kinda neat.
> >
> > a tall elf in chain main and a green cloak arrives from the south.
> > ^ ^ ^ ^
> > | | | |
> > | | | +--taken from equipment list
> > | | |
> > | | +--taken from equipment list
>
> How would you decide which pieces of equipment to use?
Well, this would be easy enough, you could simply show the 2 most
valuable items, or maybe have a "noticeability" field for objects so
that you could decide which info was most worth showing on the ldesc..
>
> Does the viewer know what an elf is?
Heh, well we have to assume SOME sort of common frame of reference,
> If I am playing a 20' giant, would the person still be 'tall'?
Well this is an interesting point, logically I guess you would have to
look at relative size, it might be kinda fun to see "a puny elf in chain
mail" when you are playing a giant. However, I dont see how it would
matter to gameplay whether it assumed a human frame of reference or not.
>
> It isn't very hard to implement descriptions which vary from viewer
> to viewer. Your 'tall elf in chain main and a green cloak' might
> look like a 'little guy with pointed ears and a silver vest' to my
> giant. The only problem with this is that the descriptions would
> have to be determined every time you saw that person doing something
> - I'm not sure what sort of effect this would have on cpu usuage, but
> having to check their equipment to make the description every time
> couldn't help.
My mud which heavily uses an internal scripting language hits about 5%
cpu usage, and its running on a fairly old and sluggish sparc20, CPU
usage should NOT be a factor.
l8r
Cryogen
--
---
Play Crimson/2799 -+> http://www.engr.uvic.ca/~clesiuk/Crimson2 <+-
Ryan Haksi "Ha ha, that makes six shots..."
cry...@infoserve.net -famous last words
telnet://daydream.uvic.ca:5000 "I re-loaded" - the rebuttal
mor...@niuhep.physics.niu.edu
Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>Katrina McClelan wrote:
>> Personally I'd not let players save descriptions... I'd descibe them as
>> is:
>>
>> a tall elf in chain main and a green cloak arrives from the south.
>> ^ ^ ^ ^
>> | | | |
>> | | | +--taken from equipment list
>> | | |
>> | | +--taken from equipment list
>
>How would you decide which pieces of equipment to use?
Two possibilities:
have equipment layered, outer equipment is more easily seen
have a list of what is important, set either by the mud, perhaps
determined by character class, or the individual.
Fighters would focus more on weapons and armour, thieves on riches (and
concealed weapons, the posibility of a disguise being used...), fops
on clothing...
Robert
Katrina McClelan
And actually, that is what I had in mind. Actually three types in the
hierachy. At the bottom materials. Then objects that could be composed
of materials (an axe with a metal blade and a wooden handle), and (for
lack of better name) super objects comprised of multiple objects (a wall
with a door as part of it... not strictly needed, but useful for
describing the fact that the door is in effect part of the wall, even
though the door can be manipulated as it's own object [ie open door]). In
effect the object and higher organizations would do nothing but make
description and game interface managable. It'd be the metal blade of the
axe that did damage. Not the axe. But the player would probably "swing
axe" to cause it (probably since a collision could occure without a
player's help in theory)
-Kat
PS: Nathan's first post got eaten by my newsfeed which is why I responded
to the reply.
Walter Goodwin
In article <6c7koc$1...@cegt201.bradley.edu>,
Katrina McClelan <kit...@directcheck.aries.net> wrote:
Personally, I'm in a purely design phase with no code actually written
to date (which means I haven't proven the system feasible as of yet,) but
my own method is to treat objects as containers for other objects. That
pile of junk for instance, is one large object, with a bunch of little
objects. those little objects could then theoretically be decomposed
further, but to be honest that much detail shouldn't be needed. I'm
also planning on treating the world itself as a collection of objects
(with the planet as one large object yet again and so on, so if I choose,
the mud might take place on a galactic scale.) Each object takes up it's
own 3-d space with a list of objects it contains indexed by its position
within the object. Thus, that potion in bob's backpack could be tracked
in relation to the pack, Bob, the hill he's on, the planet or even the
galaxy.
Hmmm, come to think of it, player's could then roleplay any feasible
object (I want to be a street :) since the code would treat pretty
much everything the same.
(Of course, each object knows its shape also, a giant's thimble may or
may not make a darn good helmet/water bucket/stool :)
This way, a small lead pellet entering a player's chest through thick
armor can use the same physics as say, a city size chunk of rock impacting
into the planet's outer crust.
>And actually, that is what I had in mind. Actually three types in the
>hierachy. At the bottom materials.
Not to be nitpicky, but are materials actually objects per se? We don't
look over there and say "Hey, look at that wood." for instance. Wouldn't
material type be a property of the object itself?
> Then objects that could be composed
>of materials (an axe with a metal blade and a wooden handle), and (for
>lack of better name) super objects comprised of multiple objects (a wall
>with a door as part of it... not strictly needed, but useful for
>describing the fact that the door is in effect part of the wall, even
>though the door can be manipulated as it's own object [ie open door]).
Well, it seems your axe falls under the same category as your super
object, each has individual parts that can be identified and manipulated,
yet each is part of a larger whole.
> In
>effect the object and higher organizations would do nothing but make
>description and game interface managable. It'd be the metal blade of the
>axe that did damage. Not the axe. But the player would probably "swing
>axe" to cause it (probably since a collision could occure without a
>player's help in theory)
Well, it'd be clunky to say the axe's metal blade sliced you IMHO,
slightly more elegant to simply say the axe, or even the person
wielding the axe did it. (though the handle can do damage to darn it,
especially if the person is unskilled with that axe and aims, er, high (?)
Ed Murphy
Richard Woolcock wrote:
>It isn't very hard to implement descriptions which vary from viewer
>to viewer. Your 'tall elf in chain main and a green cloak' might
>look like a 'little guy with pointed ears and a silver vest' to my
>giant. The only problem with this is that the descriptions would
>have to be determined every time you saw that person doing something
>- I'm not sure what sort of effect this would have on cpu usuage, but
>having to check their equipment to make the description every time
>couldn't help.
So cache the appropriate data whenever the set of worn equipment
changes. Ditto for wielded weapons, if you want to throw in "carrying
a shiny new broadsword". I used to work for a mud that cached
equipment/weapon stats to make combat calculation more efficient.
--
Ed Murphy <fo...@bayside.net>
http://www.bayside.net/users/ford/
"Don't tell me what I already know." -Richard Feng
Richard Woolcock
Ed Murphy wrote:
>
> Richard Woolcock wrote:
>
> >It isn't very hard to implement descriptions which vary from viewer
> >to viewer. Your 'tall elf in chain main and a green cloak' might
> >look like a 'little guy with pointed ears and a silver vest' to my
> >giant. The only problem with this is that the descriptions would
> >have to be determined every time you saw that person doing something
> >- I'm not sure what sort of effect this would have on cpu usuage, but
> >having to check their equipment to make the description every time
> >couldn't help.
>
> So cache the appropriate data whenever the set of worn equipment
> changes. Ditto for wielded weapons, if you want to throw in "carrying
> a shiny new broadsword". I used to work for a mud that cached
> equipment/weapon stats to make combat calculation more efficient.
The descriptions would still have to be recalculated; in the example
I gave above, the 'chain mail shirt' that most people would see appeared
as a 'silver vest' to my giant, who also completely ignored the cloak.
Sure you could cache the data - but you would have to cache a description
for each player FOR each player, updated every time equipment was adjusted.
This would be okay if the system was only used for players, but if you
wanted mobs to be treated the same, it could start using a LOT of memory.
KaVir.
Katrina McClelan
In <34F3A4...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>The descriptions would still have to be recalculated; in the example
>I gave above, the 'chain mail shirt' that most people would see appeared
>as a 'silver vest' to my giant, who also completely ignored the cloak.
>Sure you could cache the data - but you would have to cache a description
>for each player FOR each player, updated every time equipment was adjusted.
>This would be okay if the system was only used for players, but if you
>wanted mobs to be treated the same, it could start using a LOT of memory.
Besides which, for the amount of times it'd actually get called in a given
game loop, it's not really that big of a deal since monsters wouldn't care
about the descriptions. There is a ton of lead time on most (well coded)
muds during a quarter second loop. For the estimated 25-50 description
compilations on a given game loop (.25 seconds is slow for a computer, but
faster than players are likely to accumulate a ton of information needed
to be passed) it's not that big of a concern. If you MUST cache, then I'd
reccomend proximity caches. KaVir is right, it'd vary by player, but it
wouldn't matter as much in the case of the 10 or so personas in a given
player's proximity.
-Kat
Walter Goodwin
In article <34F3A4...@dial.pipex.comNOSPAM>,
Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
>
>The descriptions would still have to be recalculated; in the example
>I gave above, the 'chain mail shirt' that most people would see appeared
>as a 'silver vest' to my giant, who also completely ignored the cloak.
>Sure you could cache the data - but you would have to cache a description
>for each player FOR each player, updated every time equipment was adjusted.
>This would be okay if the system was only used for players, but if you
>wanted mobs to be treated the same, it could start using a LOT of memory.
>
Come to think of it, this is YAR for making a special client rather than
sticking by the old standby's, (which is another sore spot in some areas,
like some people complaining that player X has an unfair advantage because
their client has feature Y, compared to everyone using client Foo that you
provide :) Then, the equipment, disguise, or bar only needs to be cached
once, and defers the calculations to the client. Of course, I'm not sure
what this will do to your bandwith, (I haven't actually sat down to force
myself to learn sockets and protocols yet :) since essentially you'd have
transmit everything the person could possibly see, and maybe more (the
person could have Celestial Awareness which allows them to see every detail
down to that knife hidden in your boot and the exact amount of gold you
have in that bag :)
Perhaps Nathan will take this chance to promote clients again :)
(as well as giving the solution of maintaining lower server calculations
while still saving some bandwith)
Nathan Fenenga Yospe
Walter Goodwin, is it true that on 27 Feb 1998 20:16:55 GMT, you posted
to rec.games.mud.admin:
: In article <34F3A4...@dial.pipex.comNOSPAM>,
: Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
If that wasn't a cue, I don't know what would be. Right, here goes nothing.
There are four principals you will want to remember when designing a client
for a mud. These principals are not absolute, but they make a good outline.
1) Portability. Your client will effectively limit your user base no matter
how k3wl it is. Do you really only care about Win32? That would make client
design simpler. Do you really want to run off of a web page? That would put
you right in the middle of the biggest crop of users. I stress that word. A
web based client is, of course, constrained by what an applet can do, or by
what ActiveX can go if you are seriously massochistic. You might just write
very clean C++ with a good cross platform API. I've got a few to recommend,
if this is the case... just be intelligent and you can email me. Or you can
write an application in java. There are issues to that as well. Portability
concerns set the stage for the rest of what you will. Think about it first.
2) Flexibility. Is your mud prone to changing? Your client should have just
exactly the same flexibility as the server. Any change in the server should
be reflectable by a change in the client. There is a simple solution. Write
a protocol. As long as both client and server stick to protocol, there will
be no situations the client cannot handle. Unfortunately, this means that a
protocol, once defined, is not easilly modified. Plan it carefully. This is
especially significant because, more than anything else, your protocol will
determine the bandwidth you require. A good enough protocol can cut out all
but the most basic information. I like background updates and delta states,
which are not the most bandwidth efficient when averaged, but which are, in
times of extreme activity, far less of an overload on the I/O. More on that
later. The other aspect of flexibility is display methods. Three issues are
prevalent here: does control of local configuration belong to the client or
the server, or both? Should the server be able to make a window open? Or is
it the responsibility of the client to decide to create a window for a type
of data and display it? Don't underestimate the criticality of this. When a
client displays graphics and sound, a second issue arises. Would the server
generate the graphics itself and transmit them in some protocol (VRML, that
Pueblo protocol), or should it send some information to be used clientside,
and allow a fudge factor, or should the client store preprocessed graphics?
Transfering preprocessed graphics across the net is _not_ an option. First,
are you going to have new pictures showing up frequently? If so, the option
of storing graphics runs headlong into the flexibility principal. You have,
at the least, the problems of downloading and storing new graphics. Second,
are you going to allow art to be added by builders? This one is touchy, for
me. In general, I restrict graphics to ghostly impressions in my background
text window in Physmud, but that is a clientside decision, and I have built
for other graphics protocol extensions. Flexibility, you see. The third and
most subtle issue to be considered with regard to display methods is partly
a portability issue. Will you provide a means for text-only interface? What
if someone wants to run this client (written in Java) from their university
telnet account? Do you provide a secondary interface that outputs to a char
mode text window? (I do, for more reasons than this, but that comes later.)
3) Capability. How much do you move into the client? Does the client have a
persistant record of its own? (note: without clientside persistance, I feel
that a client is essentially just a gimmick.) Does the client generate text
itself, or graphics? Does the client store scripts or handle a language for
behavior, like JCL's mud? What do you really want a client to do? Just save
assembled descriptions for a little while? My client does more than half of
the processing associated with a given player, and uses a protocol that has
little additional overhead and saves over text... but that is not what made
me decide to work with clients. (Mind you, that's all I have so far, I have
not had time to progress beyond the client-server model and the server core
software. I'm still working on the parallel client-server protocol for data
transfer (as opposed to event and command transfer), and have not finalized
my client's interface. I have written the one thing I really wanted clients
for: the daemon and text generation engine. This is the capability that had
sufficient value for me to choose to limit my audience to those intelligent
enough to download a special client, set it up (it requires the user to set
some preferences), and run it without their browser doing it for them. This
may eliminate WebTV users. Tough. Capability is not just a 'what' question,
it ought to be the 'why' question. Saving bandwidth is sort of a lame 'why'
when you are talking about a standard text mud. Think first, what you want.
4) Possibility. Its all fine and good to talk about what you want to write,
but what _can_ you write? There is a physical limit on bandwidth, so either
the amount you send has to be low, or... well... the playerbase is going to
consist entirely of bored sysadmins. (Not that this is a bad thing, mind. I
happen to like that idea... but you had better be prepared for the penalty.
Your end has to send out that much data for every _one_ of them.) So, where
does one gain the savings needed to send all that data if one is dealing in
minute details? Ah, now there's the rub. I don't really send over that much
of what I send on the fly. Most of it goes pretty much constantly over that
parallel server I mentioned before. And I deal in delta states. This means,
the client tells the server, I have version X, plus version X.1 to block Y.
The server starts dumping the update data pretty much constantly. This data
isn't the world map... that's stored serverside... it is the basis and sets
and models and patterns and algorithms and extensions and associated blocks
of prototext and background pictures and potentially polygon models and, if
it ever becomes feasable, wireframes complete with flexpoints and textures,
that I use to describe my world. In short, I'm sending over legos, ready to
assemble when I need to. And the server has a model devoid of text and even
of any awareness of the nature of the world it represents. The client takes
the model data at a requested resolution... and this is critical, as it can
compensate greatly for bandwidth by allowing dynamic granular adjustment...
and assembles its own representation of it for the player. The client makes
complex text and possibly graphics, the server makes complex models of many
interacting bodies, determining collisions and resolution and scoping and a
slew of other such factors... the server has convection models and weather,
using thermodynamics and fluid mechanics, and the client could never handle
that... but the server only calculates the lowest resolution it has to, and
no more... and the client does all that nasty text parsing and so forth. It
comes down to this: server models physics, client models sensory interface.
Is this possible? Have I overstepped the fourth consideration? Maybe. But I
do this sort of thing professionally, and have done everything that forms a
part of either server or client for one job or another. And really, I don't
care so much about when I finish. It's WHAT I finish that matters. If I had
aimed a little lower, I would have released my earlier versions, and that's
that. I do this because I want to, I'll aim as damned high as I want. Where
I really have to think isn't whether the programming task is too great; I'm
far too confident in my abilities for that. The real question is, can I run
it in the real world when I'm done? That one, at least, I can say yes to. I
wrote the client in Java with native method versions for the OS's I like. A
Rhapsody version, a BeOS version, Solaris, Linux, and the rest of them have
to run it on a creaky old VM. (Mind, I plan to compile the three above into
both PPC and Intel native method classes.) I have portabilty, then. And the
bandwidth isn't going to kill me, I think. And it does what I want. And the
protocols are pretty flexible where I want them to be... a lot of defaults,
a system capable of ignoring new considerations when a server gets a little
ahead of the client... Flexibility is the biggest weakness. This isn't LPC.
I hope I gave you something to think about. I did slip in that bit you were
asking about, re: lower calculations and bandwidth, but you have to dig for
it. Hint: Think about the treatment of text. And consider: most of the time
an individual player's connection is idle. Now think about using that time.
That's all for now, I have a hot date tonight, and have to get home. Enjoy.
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii @ Manoa Dept of Physics
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/