Realistic MUDs: Mob behavior
Scott Anderson
Since the other threads on incorperating more realism into MUDs have
drawn out such interesting discussions, I thought I'd broach another
topic we've barely touched on just yet: mobs. Currently they are
one of four things: little boxes which hold nice eq, though are
difficult to open (hitpoints & damroll); shopkeepers; quest masters;
or useless.
I'd propose that in a realistic MUD, they would have to be much more
like real characters - they have their own wants, needs, etc...their
own agenda. They would rarely "wander" the way they do on most
muds, and they would deal with new situations in a realstic manner -
when you attack that child, he'll flee in mortal terror, but
attacking that guard will have him calling his buddies.
The easy (and I think, fairly obvious) part to this is just that you
have to give them realsitic stats. A human can only be so strong,
tough, fast, agile, etc. They would of course have to have skills
and equipment just like PC's, rather than "barehanded damage" and
huge "natural" ACs.
The second, more subtle part of this is making them act like they
are actually denziens in a fantasy (or whatever) world. How to
achieve this, especially given that you may potentially have
thousands of these critters, all trying to determine what they
should be doing every couple of seconds? In the ideal system, a mob
would have a routine by which to achieve security ("work"), then
take the remaining time for leisure. This might involve, for a
regular townsperson, going into the grocery, putting on their apron,
spending the day selling vegetables and such, then walking over to
the tavern at night, drinking a few beers and playing a few card
games, then retiring to their house for a night of sleep. If his
grocery isn't doing well, then he won't have any extra money - thus
he can't afford to gamble on cards or even buy his drinks, so he may
just go straight home - which in turn deprives the innkeeper and his
potential gambling buddies of that money. And so on. This gets
more abstract for things like the ancient lich in the black tower of
sorcery, or the wolf out on the fields. The wolf's cycle should be
pretty simple: hunt down some suitable game, eat it, head back to
the den for a few hours of sleep. The lich...well, who knows what a
lich does. Maybe hang around in its tower studying its spells,
summoning nasty critters and aquiring wealth for bold adventurers to
kill and loot, respectively.
Okay, now count in that this is probably running on some little
corner of a semi-descent machine somewhere, and things get trickier.
If you have the memory and processor time for all this, then great,
but I doubt most do. So we have to come up with some short-cuts,
such as having one mob stand around in the grocery at all times
("the grocer") and another who hangs around in the bar at all times
("the patron"). The one problem I have with this, of course, is
that they don't exactly look like a patron or a grocer when you
summon them to the middle of a desert somewhere.
[side note: I've always wondered a way to get around the "open
24hrs" shops that abound on MUDs - to make them close at night is
fucking annoying, since that's just half the game time players can't
buy food, since their characters don't "sleep" the night. Any ideas?]
One last thing to consider is the introduction of new elements into
these cycles - the commoner's life should change rather dramatically
if he finds a diamond worth a lot of money on the ground, or if some
rude player comes in and chops off one of his arms. Even barring
extremes like this, mobs have to deal with the people and objects
around them: they should greet people that they "like", make those
they don't "like" feel unwelcome (in extreme cases this means the
mob is agressive), pick up things they are interested in, discard
those they aren't.
Finally, how much of this is really important to the player? If
they see a guy walk into a tavern, order a beer, put his feet up for
a while, finish his beer, pay the tab and walk out - is this enough,
even if the guy just walks around the block and comes back to do the
same thing again a few minutes later? Or should they be able to
follow the guy around and see a realistic lifestyle? Or somewhere
in between?
The Munch Family
Scott Anderson <sban...@sdcc10.ucsd.edu> wrote:
>The second, more subtle part of this is making them act like they
>are actually denziens in a fantasy (or whatever) world. How to
>achieve this, especially given that you may potentially have
>thousands of these critters, all trying to determine what they
>should be doing every couple of seconds? In the ideal system, a mob
>would have a routine by which to achieve security ("work"), then
>take the remaining time for leisure. This might involve, for a
>regular townsperson, going into the grocery, putting on their apron,
>spending the day selling vegetables and such, then walking over to
>the tavern at night, drinking a few beers and playing a few card
>games, then retiring to their house for a night of sleep.
Why not go all the way, and have the townsperson go home, fire up
his computer and start playing a mud? Of course then you would have
to write the code to run the mud the mob is playing too.
--
* * * * * * * * *
mu...@fix.net Harry Browne for President
John and Paz Munch http://www.HarryBrowne96.org/
http://www.fix.net/~munch * * * * * * * * *
Bjoern Wesen
In article <4vaafi$a...@sdcc12.ucsd.edu>, sban...@sdcc10.ucsd.edu says...
>Since the other threads on incorperating more realism into MUDs have
>drawn out such interesting discussions, I thought I'd broach another
>topic we've barely touched on just yet: mobs. Currently they are
>one of four things: little boxes which hold nice eq, though are
>difficult to open (hitpoints & damroll); shopkeepers; quest masters;
>or useless.
Check out some more advanced muds. Most mobs on MUME for example are coded to
behave in manners like you describe - guards taking their part in the defense
of a city when its assaulted, mobiles patrolling around tracking baddies,
vampires porting around after players. A great deal of mob code is just
cosmetic - mobs walking around in cities telling stories, drinking beer etc.
And MUME is certainly not the only mud where mobs are at least semi
intelligent.
I've had some general AI outlined for a new system which involves goal-based
behaviours - you set abstract goals for mobs and they'll behave according to
that. You can make a mob 'greedy' and 'wimpy' and set his stats to those of an
old man and you'll have a scrooge walking around trying to beg money and hold
his treasure tight and flee cunningly when attacked etc. The code handles the
superposition of underlying AI behaviours.
The beauty of that is that you don't have to explicetely put code on a mob.
You define its behaviours and those behaviours will adapt according to the
stats on the mob (a low int will reduce the efficiency of a hunting behaviour
for example) and the mobs surroundings (a wimpy hunter might decide to bail
out if 10 orcs come hunting him).
Bjorn
Stig Hemmer
I'm generally against realism in muds, because I'm mudding to get away
from real life in the first place!
However, I'm all in favor of _atmosphere_ in a mud. Better mobs, or
"monsters" as LPmudders usually call them, could add enormously to the
atmosphere of a mud.
By this I mean that badly hurt monsters run away, guards call for
backup, parents get angry if they find you with the body of their
child etc. etc. I do _not_ mean closing shops at some hours or any
other "annoyance" realism that some admins like to add to their muds.
Unforunately this is very hard to program and the mud ends up using
more CPU too. In a diku-type mud this doesn't matter too much, but an
LP can easily suck every CPU cycle on quite powerful machines _before_
you start adding this.
So, I would like to see it, but I'm not holding my breath.
Stig Hemmer aka st...@pvv.ntnu.no
pvv - ProgramVareVerkstedet ("The Software Workshop", a student society)
.ntnu - Norges Teknisk-Naturvitenskaplige Universitet
.no - NOrway, a minor kingdom in northern Europe. Yes in 2016!
Scott Panzer
In article <ekvpw4m...@voldsboks.pvv.ntnu.no> Stig Hemmer,
st...@voldsboks.pvv.ntnu.no writes:
>By this I mean that badly hurt monsters run away, guards call for
>backup, parents get angry if they find you with the body of their
>
>Unforunately this is very hard to program and the mud ends up using
>
>So, I would like to see it, but I'm not holding my breath.
I always assumed these kind of things were at least somewhat
commonplace. Oh well. I can't help but plug my own mud though :-)
If you care to check out a diku-based mud that's full of this
kind of stuff (mobs that will remember you if you attack them,
mobs that shout for help, or spray you with pheromones, or whatever
other mechanism to induce their friends to attack you, mobs that
will hunt you down, but won't chase you into places they can't
survive, mobs that will pick up and use your best equipment after
they slay you, mobs that make relatively intelligent choices about
spells to cast depending on who they are fighting, or even [coming
soon...] mobs assigned to protect specific artifacts and who will
hunt or summon the knave who steals it), you might want to visit
ZeeMUD (pcnet3.pcnet.com 4000).
After two unexpected moves this past year, our population is
lower than we'd like it to be, and we'd love to have some new
faces drop by.
Cheers,
Scott
----------------------------------------------------------------
Scott Panzer | Department of Genetics, SHM I-310
ste...@pcnet.com | 333 Cedar Street
pan...@seviche.med.yale.edu | New Haven, CT 06510
----------------------------------------------------------------
Phone: 203-785-2675 Fax: 203-785-6333 Alt Fax: 203-785-7227
WWW URL: http://www.pcnet.com/~stenor/
----------------------------------------------------------------
Joshua J. Cantrell
Why not go all the way, and have the townsperson go home, fire up
his computer and start playing a mud? Of course then you would have
to write the code to run the mud the mob is playing too.
Actually, you wouldn't have to write the code to run the mud that the
NPC is using, just have the mob actually log into another MUD or maybe
the same MUD he is in!
Joshua Cantrell
j...@cory.berkeley.edu
Ryan Myers
According to sban...@sdcc10.ucsd.edu (Scott Anderson):
>Since the other threads on incorperating more realism into MUDs have
>drawn out such interesting discussions, I thought I'd broach another
>topic we've barely touched on just yet: mobs. Currently they are
>one of four things: little boxes which hold nice eq, though are
>difficult to open (hitpoints & damroll); shopkeepers; quest masters;
>or useless.
I have come across these types of mobs too... as a player and builder
I think that the mobs that don't do much but add texture to the scene
are just as important as the quest masters, shopkeepers, and eq stores. :)
But having too many can be a problem as well.
>I'd propose that in a realistic MUD, they would have to be much more
>like real characters - they have their own wants, needs, etc...their
>own agenda. They would rarely "wander" the way they do on most
>muds, and they would deal with new situations in a realstic manner -
>when you attack that child, he'll flee in mortal terror, but
>attacking that guard will have him calling his buddies.
>The easy (and I think, fairly obvious) part to this is just that you
>have to give them realsitic stats. A human can only be so strong,
>tough, fast, agile, etc. They would of course have to have skills
>and equipment just like PC's, rather than "barehanded damage" and
>huge "natural" ACs.
I build for the MERC / Envy / Diku engines... my areas tend to have
more natural ( as much as possible, dragons aren't exactly natural :) )
AC's that are boosted with items in their inventory or equipment. I also
enjoy using Mobprograms to have them eat booster potions / pills, see
below.
>The second, more subtle part of this is making them act like they
>are actually denziens in a fantasy (or whatever) world. How to
>achieve this, especially given that you may potentially have
>thousands of these critters, all trying to determine what they
>should be doing every couple of seconds? In the ideal system, a mob
>would have a routine by which to achieve security ("work"), then
>take the remaining time for leisure. This might involve, for a
>regular townsperson, going into the grocery, putting on their apron,
>spending the day selling vegetables and such, then walking over to
>the tavern at night, drinking a few beers and playing a few card
>games, then retiring to their house for a night of sleep. If his
>grocery isn't doing well, then he won't have any extra money - thus
>he can't afford to gamble on cards or even buy his drinks, so he may
>just go straight home - which in turn deprives the innkeeper and his
>potential gambling buddies of that money. And so on. This gets
>more abstract for things like the ancient lich in the black tower of
>sorcery, or the wolf out on the fields. The wolf's cycle should be
>pretty simple: hunt down some suitable game, eat it, head back to
>the den for a few hours of sleep. The lich...well, who knows what a
>lich does. Maybe hang around in its tower studying its spells,
>summoning nasty critters and aquiring wealth for bold adventurers to
>kill and loot, respectively.
One of the features that was added to Merc 2.2 but didn't make it into the
Envy engine were Mobprograms. These allow you to do just the things above...
even tracking items... my copy of the engine allows a subset of the immortals
commands for finding and checking on items, warping, and other things. I also
use it to do other ideas. I have a shopkeeper in one area. Instead of the
basic shop system, you give him coins with the standard "GIVE" command. By
this, I was able to use a ">bribe_prog" trigger (MP terminology ) to have him
give an extra item, tip, etc. if you pay him extra over the price of his one
item. This is especially nice with quest-related mobs.
One of the muds I would greatly suggest is Darkworld. The mob actions are
coded rather than using MP's ( although MP's are reportedly becoming available
in a few months ) and allow for some amazing things with NPC's. Examples are:
the mayor closing gates and shops, or sleeping, or doing things with the
secretary if you can find his office. In one of my own creations, I have a
healer that scans the room rapidly. If anyone attacks another in the room,
she goes berserk. There is also a bit involving a wand with a "change sex"
spell, but we won't go into that. :)
Hope this helps :),
Ryan Myers ( rmy...@teleport.com )
http://www.teleport.com/~rmyers/
"Canthus" on DARKWORLD
C> Warning: REALITY.SYS may be corrupt. Reboot universe(y/n)?
Scott Anderson
>I'm generally against realism in muds, because I'm mudding to get away
>from real life in the first place!
Agreed - the kind of realism we're referring to is an internally
consistant, well thought-out world which works in a way which is
realistic _within itself_. We're not saying we want a MUD where we
have to pay taxes and work a boring job.
>However, I'm all in favor of _atmosphere_ in a mud. Better mobs, or
>"monsters" as LPmudders usually call them, could add enormously to the
>atmosphere of a mud.
Nod. I like to call them NPCs, because "mob" sounds so sterile, and
"monster" doesn't really fit considering most of the NPCs are things
like townsfolks, elite guards, and so on.
>By this I mean that badly hurt monsters run away, guards call for
>backup, parents get angry if they find you with the body of their
>child etc. etc. I do _not_ mean closing shops at some hours or any
>other "annoyance" realism that some admins like to add to their muds.
What "annoyance" is varies. I agree - when regular MUDs try to toss
in things like this they usually end up being annoying as hell. But
if this stuff is integrated into the system to begin with, it
doesn't have to be annoying. It is all relative to itself.
>Unforunately this is very hard to program and the mud ends up using
>more CPU too. In a diku-type mud this doesn't matter too much, but an
>LP can easily suck every CPU cycle on quite powerful machines _before_
>you start adding this.
I don't know much about LP code, but I do know that stock
diku/Circle uses a laughably tiny amount of processor time and
memory. Which is what first got me thinking: "With more resources,
what more can we add to make the whole experience more enjoyable?"
>So, I would like to see it, but I'm not holding my breath.
Here's the thing: it's completely within reach, and obviously many
people are interested in it (given by the response on these ngs).
But everyone dismisses this stuff as "too hard", "too much work",
"not enough resources", etc. It _can_ be done, if only in a basic
form - and that's all that's needed to get the ball rolling. Once
we get some basic systems with a different thinking in place and
people playing them, it will only be a matter of time before more
people take it and make a thousand improvements to bring it closer
to what we're envisioning.
Raz
It was all I could do to contain my excitement when Scott Anderson wrote:
> topic we've barely touched on just yet: mobs.
Heh - made it at last =)
> I'd propose that in a realistic MUD, they would have to be much more
Can we change 'realistic' to read 'real'..? ;)
> The easy (and I think, fairly obvious) part to this is just that you
> have to give them realsitic stats. A human can only be so strong,
> tough, fast, agile, etc. They would of course have to have skills
> and equipment just like PC's, rather than "barehanded damage" and
> huge "natural" ACs.
Definately. First thing to go into my "Beings" (better term?) structure
were all the stats that players have - that is, 4 primaries; as the 6
secondaries are derived from the primes and other character attributes.
(Incidentally, wasn't placing stats in mob definitions something that the
original DIKU system supported as "Detailed monsters", but refused to tell
anyone about?)
Hot on the heels was provision for supplying any Being with values used by
the skills/spells system, allowing the Being a competence in any skill or
any spell from the various magic systems; just as players enjoy.
> would have a routine by which to achieve security ("work"), then
> take the remaining time for leisure. This might involve, for a
> regular townsperson, going into the grocery, putting on their apron,
> spending the day selling vegetables and such, then walking over to
> the tavern at night, drinking a few beers and playing a few card
> games, then retiring to their house for a night of sleep.
This is just right for a 'real' game, and I could think of ways to implement
it at a superficial level. The problem though is (a) keeping track of the
many details, and (b) handling exceptions.
Sticking with your example:
The grocer presumably owns the key to their store - but a thief breaks into
their home overnight and steals it. Solution?
The grocer leaves his apron in his shop, and someone has stolen it, or set
it alight. Solution?
The list could go on. There is goal-setting, of course. In the above two
problems, the solutions would be; set the grocer's intermediate goal to be a
visit to the locksmith to change the locks on his store; and, set the
intermediate goal to be a trip to the local shops to pick up a new apron.
Simple when written like that, but so much data to manage. Would you keep
goals defined for every possible eventuality? Obviously not, as it'd be
impossible =)
> [side note: I've always wondered a way to get around the "open
> 24hrs" shops that abound on MUDs - to make them close at night is
> fucking annoying, since that's just half the game time players can't
> buy food, since their characters don't "sleep" the night. Any ideas?]
Yep: Any businessman caters for the market he finds around him. If a
trader lives in a town or city, he may naturally provide services for the
regular townspeople. However, if the trader realises he lives in a town
heavily frequented by bold and daring adventurers, always on the road and
posessors of rare and exotic items, he may choose to cater for *them* - and
if that means working through the night, so be it.
So in short, you have daytime traders, you have night time traders. You may
even find a place with two or three employees who work shifts. Also, night
brings out the black market traders, etc...
> One last thing to consider is the introduction of new elements into
> these cycles - the commoner's life should change rather dramatically
> if he finds a diamond worth a lot of money on the ground, or if some
> rude player comes in and chops off one of his arms.
Yep, exception handling, as mentioned above... this, to me, is the one
(only?) thing holding such systems back at the moment.
> , mobs have to deal with the people and objects
> around them: they should greet people that they "like", make those
> they don't "like" feel unwelcome
Should be reasonably easy. I already store lists of player-player and
player-sentient_being encounters to facilitate recognition without using
much memory at all. (Can't recall the figures my coder gave me, but it's
something like <10k for 200 Beings) This could in theory be extended to
account for attitutes, though required storage would likely increase quickly
in doing so.
> pick up things they are interested in, discard those they aren't.
Object typing should allow this to a large degree, plus skills that endow
knowledge in particular areas. "Is this cosh lying handily in the street
here a better weapon than my trusty broom-handle-with-t'nail-through-it?"
> Finally, how much of this is really important to the player? If
> they see a guy walk into a tavern, order a beer, put his feet up for
> a while, finish his beer, pay the tab and walk out - is this enough,
> even if the guy just walks around the block and comes back to do the
> same thing again a few minutes later? Or should they be able to
> follow the guy around and see a realistic lifestyle? Or somewhere
> in between?
For me, I think your first scene is enough. I don't think there's much
practical purpose for providing Beings with real lives that players could
spy upon. There are also two consistent issues that stop players being able
to do that anyway: the first is that if they did nothing but watch someone
walking around for days on end, they'd find themselves losing their edge at
those important lifeskills, and the second is that the Being being 'stalked'
would likely confront the player before long anyway.
HOwever, even the 'basic' scene you provide has its complexities.
Presumably you'd want *some* variations to prevent repeating patterns being
seen all over the game. Therefore, Beings would have, perhaps, their
regular tipple stored; whether they pay each night or have a tab; whether
they try and flirt with the bar staff; do they drink in moderation or go
home wrecked, etc. It starts to build up =)
I've long dreamt of designing some kind of abstract 'world handler'... It'd
certainly be handy here!
Raz
Raz
It was all I could do to contain my excitement when Scott Panzer wrote:
> I always assumed these kind of things were at least somewhat
> commonplace. Oh well. I can't help but plug my own mud though :-)
With respect, I think its easy to confuse 'true' AI (whatever that may be)
with the ACT_ and AFF_ bitvectors of DIKU/derivative codebases - they aren't
the same.
> If you care to check out a diku-based mud that's full of this
> kind of stuff (mobs that will remember you if you attack them,
> mobs that shout for help, or spray you with pheromones, or whatever
> other mechanism to induce their friends to attack you, mobs that
> will hunt you down, but won't chase you into places they can't
> survive, mobs that will pick up and use your best equipment after
> they slay you, mobs that make relatively intelligent choices about
> spells to cast depending on who they are fighting,
(I want to choose my words carefully here; even so, the following would be
easy to take personally, but, honestly, it isn't meant to be)
That isn't the same kind of stuff as Scott (Anderson) was talking about,
though. Again, all of the above is achieved with Boolean bits that have
existed in the Diku mob structure since time immemorial =) It's psuedo-AI
at best - it works at a superficial level, but is situation dependant.
Take city guards 'calling for help'. In a city, the existing code is great
- you attack a grunt, he screams for his mates to help him, whereupon some
may drift over and join him in giving you a kicking.
Now think about this and other situations. If he can't take you on by
himself in the first place, surely a good bet is for him to run as fast as
he can back to his guardhouse, whereupon he can alert the rest of his unit
to your cheeky shenanigans? Setting ACT_WIMPY does not provide this
functionality, nor does ACT_CALLS_FOR_HELP.
How about a guard posted outside the city gates with his partner? The pair
are alerted to furtive movement in the nearby woodland and poor Gully Bul
draws the short straw to investigate. As he passes the first tree, you and
your cronies set upon him - now, Gul *can't* call for his partner, Safen
Sound, to join the fight, as it would mean leaving the city gate unguarded,
but he *can* shout for Safen to alert the garrison to dispatch help. Thing
is, Gully never did fare well in the brains department. Will it even occur
to him to get Safen to relay the cry?
These are all things that can be done with AI, but not with ACT_ flags.
> or even [coming
> soon...] mobs assigned to protect specific artifacts and who will
> hunt or summon the knave who steals it), you might want to visit
> ZeeMUD (pcnet3.pcnet.com 4000).
Of course, I haven't seen your Mud, or the code you've used/modified/added.
I could well be talking out of my arse, and if so I apologise; this post is
only meant to highlight differences between the two methods.
Raz
Scott Anderson
>>Since the other threads on incorperating more realism into MUDs have
>>drawn out such interesting discussions, I thought I'd broach another
>>topic we've barely touched on just yet: mobs. Currently they are
>>one of four things: little boxes which hold nice eq, though are
>>difficult to open (hitpoints & damroll); shopkeepers; quest masters;
>>or useless.
>
>behave in manners like you describe - guards taking their part in the defense
>of a city when its assaulted, mobiles patrolling around tracking baddies,
>vampires porting around after players. A great deal of mob code is just
>cosmetic - mobs walking around in cities telling stories, drinking beer etc.
>And MUME is certainly not the only mud where mobs are at least semi
>intelligent.
Yes, I've seen plenty of this stuff, and IMO it falls flat. It's
pretty obvious they are just going through the motions - it never
really seems to me like they're just actually doing this stuff.
>I've had some general AI outlined for a new system which involves goal-based
>behaviours - you set abstract goals for mobs and they'll behave according to
>that. You can make a mob 'greedy' and 'wimpy' and set his stats to those of an
>old man and you'll have a scrooge walking around trying to beg money and hold
>his treasure tight and flee cunningly when attacked etc. The code handles the
>superposition of underlying AI behaviours.
That's definitely more what I had in mind.
>The beauty of that is that you don't have to explicetely put code on a mob.
>You define its behaviours and those behaviours will adapt according to the
>stats on the mob (a low int will reduce the efficiency of a hunting behaviour
>for example) and the mobs surroundings (a wimpy hunter might decide to bail
>out if 10 orcs come hunting him).
Yes, exactly. I guess the topic I was broaching was how to do this,
exactly. Should the zone writer describe specifically what each mob
does with its "spare time", where it goes to work, where it buys its
food, etc etc? Or should things just be assumed from the race, age,
and other vital stats on a mob? Should there be some sort of
scripting language, or should you just define the basic "type" of
mob - guard, grocer, undead lich - and it will assign work, leisure,
susentance, and rest "goals" automatically? This seems to make more
sense, but it takes a lot away from the zone writer - it's hard to
make specific mobs if the engine is just assuming things about them.
mr. dert,,,,
In article <4vd2ks$6...@news.ycc.yale.edu>, Scott Panzer wrote:
>I always assumed these kind of things were at least somewhat
>commonplace. Oh well. I can't help but plug my own mud though :-)
they are, or should be.
>If you care to check out a diku-based mud that's full of this
>kind of stuff (mobs that will remember you if you attack them,
>mobs that shout for help, or spray you with pheromones, or whatever
>other mechanism to induce their friends to attack you, mobs that
>will hunt you down, but won't chase you into places they can't
>survive, mobs that will pick up and use your best equipment after
>they slay you, mobs that make relatively intelligent choices about
>spells to cast depending on who they are fighting, or even [coming
>soon...] mobs assigned to protect specific artifacts and who will
>hunt or summon the knave who steals it), you might want to visit
>ZeeMUD (pcnet3.pcnet.com 4000).
oh please. this shit was trivial when i was pimp'in it back in '93. there
were muds then which had these things, and there are muds now which have
these things. this does not qualify as a "diku dilemma". a capable coder
can implement these things easily. sure, not many muds have; i'll let you
draw your own conclusions...
-dert
Chris Lawrence (Contra)
Raz (r...@mushroom.demon.co.uk) wrote:
: For me, I think your first scene is enough. I don't think there's much
: practical purpose for providing Beings with real lives that players could
: spy upon. There are also two consistent issues that stop players being able
: to do that anyway: the first is that if they did nothing but watch someone
: walking around for days on end, they'd find themselves losing their edge at
: those important lifeskills, and the second is that the Being being 'stalked'
: would likely confront the player before long anyway.
I can see a lot of use for it in simulations. A lot of MUD's are used
to simulate social environments, and to then see if the simulations
behave "correctly".
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
mal...@gate.nate
sban...@sdcc10.ucsd.edu (Scott Anderson) wrote:
>Since the other threads on incorperating more realism into MUDs ....
I think most of the discussion is missing the point. Who cares if the
baker is intellegent enough to go to the nearest tailor shop to
replace his burnt up old apron.
We should not focus in the SMALL as far as MOB AI is concerned but in
the LARGE. What kinds of independent behavoir dramatically effect
the playability and enjoyment of the mud? Adding operating hours to
shops make them more realistic but are also an unbelievable annoyance
as well.
Let point out a couple of examples. The Evil Black Dragon atop the
volcanic peak above the main city raids the city once a year on a
certain day (that way we know is coming). He attacks anything that
moves, looting all the shops, stores etc.. And why doenst everyone
just abandon the city on the day of the raid?? Because if he is not
killed he will burn the city to the ground. No shops!! NO INN!!!
Solution: Chars band together to take him out. Again not often just
once a (Mud) year.
Second and last example:
I started on Muds on ol' reliable Ancient Anguish. Good intro LP mud.
Shock! Orcs raid the city every now and then. They just dont do it
very well.
Next I graduated to Artic, a much more detailed Mud. If you have
played it you know Mid/Low chars live to clean out the nearby goblin
camp. What if the goblin camp were to march on the main city for a
change in a horde of 50 strong complete with supporting mages, pets
and more?? If they succeed they burn the city to the ground, or kill
all the shop keepers. Maybe they place the south gate of the city
under siege?? Groups would form to lift the siege, and destroy gob
army.
Just thoughts.
Ray
Scott Anderson
>> The easy (and I think, fairly obvious) part to this is just that you
>> have to give them realsitic stats. A human can only be so strong,
>> tough, fast, agile, etc. They would of course have to have skills
>> and equipment just like PC's, rather than "barehanded damage" and
>> huge "natural" ACs.
>
>Definately. First thing to go into my "Beings" (better term?) structure
>were all the stats that players have - that is, 4 primaries; as the 6
>secondaries are derived from the primes and other character attributes.
>(Incidentally, wasn't placing stats in mob definitions something that the
>original DIKU system supported as "Detailed monsters", but refused to tell
>anyone about?)
No, it was there, it was just useless. Why give a critter a 25
strength when you can just give him 6d8+20+20 on his bare hands?
>> would have a routine by which to achieve security ("work"), then
>> take the remaining time for leisure. This might involve, for a
>> regular townsperson, going into the grocery, putting on their apron,
>> spending the day selling vegetables and such, then walking over to
>> the tavern at night, drinking a few beers and playing a few card
>> games, then retiring to their house for a night of sleep.
>
>This is just right for a 'real' game, and I could think of ways to implement
>it at a superficial level. The problem though is (a) keeping track of the
>many details, and (b) handling exceptions.
>Sticking with your example:
>The grocer presumably owns the key to their store - but a thief breaks into
>their home overnight and steals it. Solution?
>The grocer leaves his apron in his shop, and someone has stolen it, or set
>it alight. Solution?
>The list could go on. There is goal-setting, of course. In the above two
>problems, the solutions would be; set the grocer's intermediate goal to be a
>visit to the locksmith to change the locks on his store; and, set the
>intermediate goal to be a trip to the local shops to pick up a new apron.
Yeah...unless you were to write really involved intelligence,
though, all of this would be rather silly. Who wants to write
10,000 exceptions? For now it would be easy enough to fake it by,
"Hmmm...key was stolen...*scratch*...[create_obj(key),
obj_to_char(key, grocer)]...say, here's one that will fit!"
Eventually it would be cool to have the AI do something like: need
apron, do I have it? No...check my possesions and immediate
surroundings. Not there? Go to the nearest apron I can aquire
(read: tailor's shop). But for now I hardly think this is vital,
especially since simply the act of looking for his apron makes him
about 10 times smarter than most mobs on MUDs right now.
>> One last thing to consider is the introduction of new elements into
>> these cycles - the commoner's life should change rather dramatically
>> if he finds a diamond worth a lot of money on the ground, or if some
>> rude player comes in and chops off one of his arms.
>
>Yep, exception handling, as mentioned above... this, to me, is the one
>(only?) thing holding such systems back at the moment.
Largely I think it's a matter of just getting a system in place,
then seeing how players abuse these holes in it, and plug those up.
Once that is working relatively smoothly, it would be easier to step
back and then say, "Okay, now how can we bump up the mob's relative
intelligence another notch?"
>> , mobs have to deal with the people and objects
>> around them: they should greet people that they "like", make those
>> they don't "like" feel unwelcome
>
>Should be reasonably easy. I already store lists of player-player and
>player-sentient_being encounters to facilitate recognition without using
>much memory at all. (Can't recall the figures my coder gave me, but it's
>something like <10k for 200 Beings) This could in theory be extended to
>account for attitutes, though required storage would likely increase quickly
>in doing so.
There was a thread about player "memory" of names and such about six
months back. At the time I seemed to be about the only supporter of
a system where every player has a list of all the people they know,
by what name, how well etc...and the reason shown above is one of the
many that I think such a system is necessary for any MUD trying to
achieve the next level of realism.
>> pick up things they are interested in, discard those they aren't.
>
>Object typing should allow this to a large degree, plus skills that endow
>knowledge in particular areas. "Is this cosh lying handily in the street
>here a better weapon than my trusty broom-handle-with-t'nail-through-it?"
More importantly: "I'm Ghandi, should I pick up this heavy
two-handed sword lying in the street? It would probably make a
better weapon than this wet piece of toast I'm currently
holding..."
>> Finally, how much of this is really important to the player? If
>> they see a guy walk into a tavern, order a beer, put his feet up for
>> a while, finish his beer, pay the tab and walk out - is this enough,
>> even if the guy just walks around the block and comes back to do the
>> same thing again a few minutes later? Or should they be able to
>> follow the guy around and see a realistic lifestyle? Or somewhere
>> in between?
>
>For me, I think your first scene is enough. I don't think there's much
>practical purpose for providing Beings with real lives that players could
>spy upon. There are also two consistent issues that stop players being able
>to do that anyway: the first is that if they did nothing but watch someone
>walking around for days on end, they'd find themselves losing their edge at
>those important lifeskills, and the second is that the Being being 'stalked'
>would likely confront the player before long anyway.
>HOwever, even the 'basic' scene you provide has its complexities.
>Presumably you'd want *some* variations to prevent repeating patterns being
>seen all over the game. Therefore, Beings would have, perhaps, their
>regular tipple stored; whether they pay each night or have a tab; whether
>they try and flirt with the bar staff; do they drink in moderation or go
Yes: I still tend to think that something a bit more involved is in
order. I mean, Ultima had basic mob scripts for them to get up, go
to work, go to the tavern, eat dinner, go home, go to sleep...call
the guards if you attacked/stole from them, etc etc. All this at 8
mHz with 512k of RAM - and you're telling me we can't duplicate this
on a Sun10 with 64 megs of RAM?
Kris Van Hees
In rec.games.mud.lp Scott Anderson <sban...@sdcc10.ucsd.edu> wrote:
: There was a thread about player "memory" of names and such about six
: months back. At the time I seemed to be about the only supporter of
: a system where every player has a list of all the people they know,
: by what name, how well etc...and the reason shown above is one of the
: many that I think such a system is necessary for any MUD trying to
: achieve the next level of realism.
Not to fire up the thread again, but from my experiences with players the
loss of full overview of who is on the mud, and their names breaks down the
original intent of e.g. LPmuds where healing through drinking and eating,
and the restriction to only be able to drink in the inn itself (and not
carry them - a long lost restriction) was actually meant to get social
contact and cooperation going. Making the knowledge about people more
realistic and restricted breaks down one of the cornerstones of many muds
these days I think. A side effect of most atempts for more realism. The
more elaborate and realistic behaviour of mobiles is actually one of the few
things that won't affect players that much.
: Yes: I still tend to think that something a bit more involved is in
: order. I mean, Ultima had basic mob scripts for them to get up, go
: to work, go to the tavern, eat dinner, go home, go to sleep...call
: the guards if you attacked/stole from them, etc etc. All this at 8
: mHz with 512k of RAM - and you're telling me we can't duplicate this
: on a Sun10 with 64 megs of RAM?
Ultima however was not a multi-user game, where a multitude of mobiles
were going on. The core of a system like Ultima (and making it possible
on relatively slow computers with not too much memory) usually lies in
decent management of event lists, ensuring that mobiles which are out of
view do not cause computational overhead except for expected encounters
by wandering into the field of view. This could be done on muds also, but
it is more difficult because you deal with multiple users.
I once wrote a mobile coordinator for an area where inactive rooms were
cleaned up, and the mobile was stored in a special floating location. Each
room in the area made a call to the coordinator (either upon being loaded
or when being entered by the first player or mobile). The coordinator would
then bascially compute the 'history' of the mobiles to cover the time spent
in limbo, calculating their current position, and any who end up in the
room are placed there. It actually saved a good deal of room loading, and
still didn't end up in the "everything stops when people leave the area".
The system was rather crude back then, and was never finished due to other
tasks, but it was a start.
Aedil
gry...@iaehv.nl
>(read: tailor's shop). But for now I hardly think this is vital,
>especially since simply the act of looking for his apron makes him
>about 10 times smarter than most mobs on MUDs right now.
Not to mention that it makes our grocer smarter than the players also
and we can't have that can we?
Marian
Scott Anderson
>>Since the other threads on incorperating more realism into MUDs ....
>
>I think most of the discussion is missing the point. Who cares if the
>baker is intellegent enough to go to the nearest tailor shop to
>replace his burnt up old apron.
Heh...well, I do, but I'm a detail guy. If I was playing a mud
where I cast a fire spell that burnt the baker's apron and he was
smart enough to go buy a new one I think I'd just about shit my
pants.
Anyways, the whole apron thing is just a small example. With a well
designed system it should matter if it's the baker going to buy some
groceries, a troll going hunting for human flesh, or an undead lich
planning domination of the world. I realize on most MUDs this sort
of thing is achieved with ACT_HUNT or ACT_PLAN_WORLD_DOMINATION, but
I'm looking for a more generalized and powerful system.
>We should not focus in the SMALL as far as MOB AI is concerned but in
>the LARGE. What kinds of independent behavoir dramatically effect
>the playability and enjoyment of the mud? Adding operating hours to
>shops make them more realistic but are also an unbelievable annoyance
>as well.
It depends on the layout of the mud, but in general yes I agree with
you - there is a point at which we say, "What sorts of things are
truly going to make the game more interesting and exciting?" For
me, one of the things really lacking is a sense of being in a real
environment - I don't feel any remorse at killing the good-aligned
hobbit grocer with my paladin, because he's just a little spec proc
that sells me fruit. If he actually seemed like a real person a
little more, I might think twice.
>Let point out a couple of examples. The Evil Black Dragon atop the
>volcanic peak above the main city raids the city once a year on a
>certain day (that way we know is coming). He attacks anything that
>moves, looting all the shops, stores etc.. And why doenst everyone
>just abandon the city on the day of the raid?? Because if he is not
>killed he will burn the city to the ground. No shops!! NO INN!!!
>Solution: Chars band together to take him out. Again not often just
>once a (Mud) year.
Well, this would be bad coding. Assuming that the black dragon has
some intelligence, he'd choose his target cities and his times to be
when they expect him the least and when his gain stands to be the
greatest. Thus attacking on the same day every year might be rather
silly, unless he specifically enjoyed the anxiety it caused the
townspeople anticipating that day.
>I started on Muds on ol' reliable Ancient Anguish. Good intro LP mud.
>Shock! Orcs raid the city every now and then. They just dont do it
>very well.
They're orcs for crying out loud. They don't do ANYTHING very
well.
>Next I graduated to Artic, a much more detailed Mud. If you have
>played it you know Mid/Low chars live to clean out the nearby goblin
>camp.
Well, I don't, mostly because it's always clear. But yes I do know
what you mean. :)
>What if the goblin camp were to march on the main city for a
>change in a horde of 50 strong complete with supporting mages, pets
>and more??
Aparently they did, one day, with Fewmaster marching at the lead. I
wasn't there, but supposedly it caused mass death before the
mid-levels got their act together and rocked them. Of course this
tends to be highly dependant upon who's standing in the town at a
given moment - last time the ogre chief came cruising into Balifor
my friends and I happened to be standing at the south gate and we
killed him before he had a chance to molest anyone.
>If they succeed they burn the city to the ground, or kill
>all the shop keepers. Maybe they place the south gate of the city
>under siege?? Groups would form to lift the siege, and destroy gob
>army.
Absolutely. But this takes a lot of careful design and coding, so
with that in mind I thought to approach the situation from a simpler
perspective before tackling those sorts of things.
Scott Anderson
>>(read: tailor's shop). But for now I hardly think this is vital,
>>especially since simply the act of looking for his apron makes him
>>about 10 times smarter than most mobs on MUDs right now.
>
>and we can't have that can we?
Heh...well, true. However I consider this a benefit. As it stands,
pretty much anyone can achieve max-power-level (whatever that may
entail) given enough time and patience; the smart/cunning players
just do it far more quickly. In a system with smart mobs it would
probably make it possible for only the smartest, most devious
characters to be butting their heads against the "cap" on "power".
Or maybe not, but I'm willing to give it a shot. :)
Thomas Charron
Scott Anderson wrote:
> Yes, exactly. I guess the topic I was broaching was how to do this,
> exactly. Should the zone writer describe specifically what each mob
> does with its "spare time", where it goes to work, where it buys its
> food, etc etc? Or should things just be assumed from the race, age,
> and other vital stats on a mob? Should there be some sort of
> scripting language, or should you just define the basic "type" of
> mob - guard, grocer, undead lich - and it will assign work, leisure,
> susentance, and rest "goals" automatically? This seems to make more
> sense, but it takes a lot away from the zone writer - it's hard to
> make specific mobs if the engine is just assuming things about them.
<ponders> You know, it sounds like what your looking for is 'Object
Oriented Mob Coding'.. <g> I.E., a type of MOB, let's say an elf, has
certain set traits. Anything that is said to be of an 'elf' class will
inherit these trait's, UNLESS it specifically redifines it.. Yep, most
deifinatly OOP (Object Oriented Programming). That would give you the
ability to let's say, have an 'Orcish Hunter' and an 'Elven Hunter' and
NEVER write a line of code for them, as theid just 'inherit' the trait's
of a hunter AND either Elf or Orc.. Sounds like a job for Java or
Smalltalk to me..
TwOlf -- Rackain -- Thomas Charron
Ray Racine
claw...@cup.hp.com (Chris Lawrence (Contra)) wrote:
>Thomas Charron (ti...@freeppp.com) wrote:
>: <ponders> You know, it sounds like what your looking for is 'Object
>: Oriented Mob Coding'.. <g> I.E., a type of MOB, let's say an elf, has
>: certain set traits. Anything that is said to be of an 'elf' class will
>: inherit these trait's, UNLESS it specifically redifines it.. Yep, most
>: deifinatly OOP (Object Oriented Programming). That would give you the
>: ability to let's say, have an 'Orcish Hunter' and an 'Elven Hunter' and
>: NEVER write a line of code for them, as theid just 'inherit' the trait's
>: of a hunter AND either Elf or Orc.. Sounds like a job for Java or
>: Smalltalk to me..
One prob is (I have been toying with this) is that Java does not allow
multiple inheretance like C++. You could try an Elf that inherits
from Being that implements the Ranger interface but then you have to
cross all races with all possible classes (char classes not Java
classes!) I am currently toying with the envelope idiom where a
Being uses one or more classes.
public class PlayerChar extends Being {
MudClass mudclass = null;
void setClass(Mudclass mc) {
mudclass = mc;
}
}
public class Elf extends PlayerChar {
}
Elf elf = new Elf();
elf.setClass(new Ranger());
.
.
Ray Racine (not fully mud enabled)
WILLIAM CARSON
[novel snipped]
The problem is, muds as they are now push systems to their fullest
potential. Every mob prog, or soecial procedure done in C requires
more memory and more cpu time. Take a large mud, with hundreds of
mobiles and you have lag city. (ever wonder why Sojourn lags so
much besides the 300 player base? they have a prog attached to
nearly every mob in the game.)
The key is to assign special procedures and progs only on mobs
which would reflect their true behavior. (Attaching a procedure
to a snake for a poison bite, or a text based procedure on a
bartender in a bar to give out rumors).
As for the shops, you kind of contradict yourself, you want the
mobs to be more realistic but the shops to be open 24 hrs? I don't
know the theme of the muds you play but in most AD&D scenarios, cities
and towns lock up tight when it gets dark, boarded windows and the whole
nine. A shop open 24hrs would be a thieve's guild wet dream.
I know what you mean though, mobs need to be more interactive, but it
really tasks the system. We run our mud on a dual pent pro 200, 128
meg ram on a direct t-3 and we have reached the lag point. (we have
combed out every piece of sloppy code and it helps a little but the
more checks you add (ie: mob progs and procedures) the more the cpu
works and the more ram is used.
Paul McInnes
mal...@gate.nate wrote:
>
> I think most of the discussion is missing the point. Who cares if the
> baker is intellegent enough to go to the nearest tailor shop to
> replace his burnt up old apron.
>
> the LARGE. What kinds of independent behavoir dramatically effect
> the playability and enjoyment of the mud? Adding operating hours to
> shops make them more realistic but are also an unbelievable annoyance
> as well.
I agree. I think what people are talking about here is a world that
contains a variety of dynamic systems the provide challenges and rewards
of action and, ideall, pure RP as well. The simple example would be MOBs
doing vaguely intelligent things, but more complex examples would involve
the activity of organisations, economic systems etc etc. This is
wonderful goal.
It also demands an enormous investment in coding and campaign design.
Dynamic systems, particularly systems that can interect, can have weird
emergent properties that cannot be predicted until they are in operation.
The seductive ideal of simulating everything is simply not practical at
the moment. This means that it is best to invest the design energy and
time in those areas that will provide the maximum return in terms of
player enjoyment and add richness to the world. What this is depends on
the theme of the MUD and the kind of activity the designers want to
encourage. It might be gratuitous combat but it might be something more
sophisticated.
In other words, it seems to me that simulation MUDs will work best with
tightly constrained worlds because the systems should be built into the
design phase. You cannot just add "areas" as you go along and expect a
simulation MUD to work well. You have to design the MUD as a simulation
MUD from the begining, from the ground up, and be willing to spend a lot
of time doing tests without PCs, and a long and painful time in Beta. Of
course, the rewards are probably worth it because the world would be
enormously rich and could avoid placating players with lots of different
monsters, huge numbers of rooms, even more powerful magic stuff and
exotic areas, keeping the whole thing much more coherent and less
hack'n'slay. In effect, the systems you simulate become characters in the
"story" of the MUD, and like any writer, you would need to chose these
characters very carefully.
Paul
Thomas Charron
<RoTfL> But what happens when he attack's himself with antoehr char,
doesn;t that lead to a time-space vortex and cause everything we know to
come to an end? <g>
TwOlf -- Rackain -- Neverland
Chris Lawrence (Contra)
Thomas Charron (ti...@freeppp.com) wrote:
: <ponders> You know, it sounds like what your looking for is 'Object
: Oriented Mob Coding'.. <g> I.E., a type of MOB, let's say an elf, has
: certain set traits. Anything that is said to be of an 'elf' class will
: inherit these trait's, UNLESS it specifically redifines it.. Yep, most
: deifinatly OOP (Object Oriented Programming). That would give you the
: ability to let's say, have an 'Orcish Hunter' and an 'Elven Hunter' and
: NEVER write a line of code for them, as theid just 'inherit' the trait's
: of a hunter AND either Elf or Orc.. Sounds like a job for Java or
: Smalltalk to me..
Or any of the OO-style MUD servers, like MOO, LP, Cool, ColdX etc.
Orion Henry
>[novel snipped]
Thank you. *bows*
>The problem is, muds as they are now push systems to their fullest
>potential.
Bullshit. Maybe poorly coded ones do, but standard diku/Circle muds
run great on a 486 or even a Sun3, as long as you have enough memory
to hold however large the world is. (Like 8 megs for the stock
zones, I think, so probably 16-20 megs for a good sized mud.)
>Every mob prog, or soecial procedure done in C requires
>more memory and more cpu time.
Maybe you should try reading the "novel" I wrote above. I don't
_want_ to do it as 10,000 special procedures, nor should I have to.
I was asking, how can I do this with fast, simple, generalized code
that will allow for a variety of mob behaviors?
>Take a large mud, with hundreds of
>mobiles and you have lag city.
Try thousands. Stock Circle comes with like 1.5k mobs (it's been a
while, sorry if that number isn't right) and it doesn't lag at all
on any machine I've ever used. Maybe once you get up into the range
of 10,000 mobs, but even then I doubt it would really be a problem
on any modern processor with sufficient RAM.
>(ever wonder why Sojourn lags so
>much besides the 300 player base? they have a prog attached to
>nearly every mob in the game.)
Well, I don't believe every mob needs a "program" attached to it.
It needs certain behavioral patterns which it can follow.
Incedentally, I never noticed Sojurn lagging, although I'll admit I
played there very little. Try a better link, maybe?
>The key is to assign special procedures and progs only on mobs
>which would reflect their true behavior. (Attaching a procedure
>to a snake for a poison bite, or a text based procedure on a
>bartender in a bar to give out rumors).
Wow. Those have never been done before. Man, if I logged onto a
mud where a snake poisoned me when he bit me, wow...that would kick
ass. (Okay, I'll stop before I get _really_ sarcastic.)
>As for the shops, you kind of contradict yourself, you want the
>mobs to be more realistic but the shops to be open 24 hrs?
Very good point, and in fact I did opt for shops that are only open
at certain times - but this varies by the shop, so they don't all
just magically open and close at once.
>I don't
>know the theme of the muds you play but in most AD&D scenarios, cities
>and towns lock up tight when it gets dark, boarded windows and the whole
>nine. A shop open 24hrs would be a thieve's guild wet dream.
Yes, the "hours" thing gives a lot of potential for broader
night/day distinctions, and adds to the atmosphere a lot, which is
why I went with it. I was just trying to justify shops closing for
a reason other than to annoy players.
>I know what you mean though, mobs need to be more interactive, but it
>really tasks the system.
Yeah, they need to be more interactive the same way mist needs to be
a little more solid. That is, they aren't right now - at best they
are little vending machines for items or quests.
Secondly, I don't think it has to task the system, with the right
coding. Actually let me rephrase that - it doesn't, because I've
done it.
>We run our mud on a dual pent pro 200, 128
>meg ram on a direct t-3 and we have reached the lag point.
Ack! What the hell kind of monster are you running?
>(we have
>combed out every piece of sloppy code and it helps a little but the
>more checks you add (ie: mob progs and procedures) the more the cpu
>works and the more ram is used.
This is the root of the problem, I think, both conceptually and
code-wise: mobs aren't little containers with programs attached to
them to make them seem semi-alive. They should be real beings
within the world you are creating, with needs and wants the same as
anyone else. The only difference, of course, is that they are
highly _optimzed_ needs and wants. :)
Andrew Pierce
One big problem with realistic Mob behaviour is that players don't like
it. :) I have a small area with what I would characterize as a moderate
complexity AI defensive scheme. If players invade, children are sent to
safety, guards are activated, the complex assumes a defensive stance. The
problem is that this (relatively for most muds) sophisticated behaviour
means that these mobs are harder to kill than they would be given their
level. Since the reward players get is related to the level of the
mob, these mobs are relatively undervalued with respect to mobs of
equivalent level elsewhere on the mud who lack such a defensive scheme.
-Andy
David Rudy
In article p...@news.gate.net, mal...@gate.net (Ray Racine) writes:
>One prob is (I have been toying with this) is that Java does not allow
>multiple inheretance like C++. You could try an Elf that inherits
>from Being that implements the Ranger interface but then you have to
>cross all races with all possible classes (char classes not Java
>classes!) I am currently toying with the envelope idiom where a
>Being uses one or more classes.
>
>public class PlayerChar extends Being {
> MudClass mudclass = null;
>
> void setClass(Mudclass mc) {
> mudclass = mc;
> }
>}
>
>public class Elf extends PlayerChar {
>}
>
>
>Elf elf = new Elf();
>elf.setClass(new Ranger());
> .
> .
>
>Ray Racine (not fully mud enabled)
>
>
Java would be good code for a mud.
It's platform independant, allows dynamic object loading/linking, takes care of
memory allocation and freeing on its own, and is EXTREMELY slow.
Oh wait, that's LPC now isn't it? And LPC runs faster than Java and has been
around serving muds for years.
Until we see something that Java can do better than (or heck even as well as) LPC,
there is no real need to put that kind of effort into coding a system that
would be prone to the types of bugs and problems that LPC's many years of mud
experience has weeded out.
As for your Ranger example: You might not want an interface for each class. Some
muds just set a variable "profession" or "class" in the Player object, and then
the command parser does the hard work of providing different functionality for
members of different classes. In the same thinking, you need little more than
a variable "race" and code in the command parsing to handle different behavior
for the different races. Change your mode of thinking around.
There are schools of thought for each method of implementing this system.
Some will argue that you need different inherits for each class to reduce lag
by not having to command parse different functions per race. However, you use
more memory by having a large amount of duplicated code per race.
Others will argue the reverse, that the memory gained is worth sacrificing some overhead for a few racial comparisons in the commands.
In reality it is just a matter of preference.
David Rudy, lpmud coding since 1992. (has it really been THAT long? *Gasp*)
Joel Wideman
three solutions are readily apparent -
1) make ALL the areas like this, unfortunately, only the stubborn and
masochistic will play on your mud :P
2) make the mobs in that area easier to kill, or raise the levels
3) put a higher level item in the area... it becomes not an xp area, but
an eq area... only those who get high enough to breeze through it and take
the time to explore it will go there, and they will be rewarded by the eq
that they are ready to use
i like the third solution, and perfect examples of this is the stock rom
High Tower of Sorcery. Nobody goes there for xp on the mud i play on, and
certain items have been altered to make them desirable to higher level
characters... and yet, few people explore it because its thru a maze and
the tower itself is a bit large
but those who have taken the time to explore it at later levels, have been
rewarded :)
Raz
It was all I could do to contain my excitement when Kris Van Hees wrote:
> In rec.games.mud.lp Scott Anderson <sban...@sdcc10.ucsd.edu> wrote:
> : There was a thread about player "memory" of names and such about six
> : months back. At the time I seemed to be about the only supporter of
> : a system where every player has a list of all the people they know,
> Not to fire up the thread again,
Why the hell not? =)
> but from my experiences with players the
> loss of full overview of who is on the mud, and their names breaks down the
> original intent of [Muds, which were] actually meant to get social
> contact and cooperation going. Making the knowledge about people more
> realistic and restricted breaks down one of the cornerstones of many muds
> these days I think.
Don't think I can agree with you there. I can't see that, having given a
group of people a task to perform individually (kill things), forcing a
subset of them together every now and again (in an Inn setting or not) long
enough for them to type "#10 buy pie, #10 eat pie" is going to get them
swapping stories and buying each other drinks. =)
My system describes players by appearance by default, not by name. Players
at their own discretion can introduce themselves to each other with a
simple, non-intrusive one-command-each procedure. The player initiating the
introduction gives their name first, and the 'target' can choose to respond
to or ignore the player.
I think this opens up a lot more possibilities for roleplaying, if nothing
else. Assassins and thieves are unlikely to want a 'high profile', wheras
'good' characters will want to be friendly with a wide range of people.
You're not restricting player interaction, because the chances are that if a
player ignores your introduction then they don't want to speak with you
anyway.
As for other game aspects, things can be left as they are in most
circumstances. 'Who' lists don't cause me a problem, even in a proposed
Real Mud - everyone's name can still be listed. Erm, can't think of
anything else off-hand.
> The more elaborate and realistic behaviour of mobiles is actually one
> of the few things that won't affect players that much.
I reckon that when it's acheived, it will *start* affecting players...
> I once wrote a mobile coordinator for an area where [...]
Sounds interesting. I've thought about different methods for keeping my
'Beings' overheads down, and also to tackle the problem of keeping a
population balance. Speaking of Ultima, I considered a system similar to
theirs where certain Spaces will contain invisible 'eggs' that (under the
right circumstances) will spawn one or more Beings when a player enters the
Space. Anyone have any thoughts on employing that system?
This is all part of my ambition to lose the notion of the #RESETS section
common in DIKU based engines. What I'm after is to have something almost
like an actual #REBOOT section, which will initialize everything *once* when
the games comes up and is never looked at again.
Raz
Raz
It was all I could do to contain my excitement when Andrew Pierce wrote:
> One big problem with realistic Mob behaviour is that players don't like
> it. :) I have a small area with what I would characterize as a moderate
> complexity AI defensive scheme. [...]
That sounds like an excellent system -
> Since the reward players get is related to the level of the
> mob, these mobs are relatively undervalued with respect to mobs of
> equivalent level elsewhere on the mud who lack such a defensive scheme.
The answer then is to extend your AI to your other mobs, so they're all of
reletive intelligence, then re-evaluate either the mob strengths or your
level-based rewards.
Then tell me your IP address ;)
Raz
Orion Henry
>: There was a thread about player "memory" of names and such about six
>: months back. At the time I seemed to be about the only supporter of
>: a system where every player has a list of all the people they know,
>: by what name, how well etc...and the reason shown above is one of the
>: many that I think such a system is necessary for any MUD trying to
>: achieve the next level of realism.
>
>loss of full overview of who is on the mud, and their names breaks down the
Er....hmmm, haven't encountered those...?
>and the restriction to only be able to drink in the inn itself (and not
>carry them - a long lost restriction) was actually meant to get social
>contact and cooperation going.
That's interesting - like that law about not being able to take open
alcohol containers out of bars? *shrug* this all seems extremely
artifical to me, though not having seen it/used a system like this,
I guess it might be bad for me to make a judgement.
>Making the knowledge about people more
>realistic and restricted breaks down one of the cornerstones of many muds
>these days I think. A side effect of most atempts for more realism. The
>more elaborate and realistic behaviour of mobiles is actually one of the few
>things that won't affect players that much.
Won't affect players that much? Heh, heh...if you had any idea what
an incredibly different mud it makes, you wouldn't say that. I'm
with you on your other points, but my whole _intention_ in creating
a new kind of mud was, as you stated, to break down most of the
cornerstones of MUDs and start fresh. Not because there is
necessarily anything wrong with the ones out there now, but because
I am pretty bored with them, and I'm sure there are others like me.
>: Yes: I still tend to think that something a bit more involved is in
>: order. I mean, Ultima had basic mob scripts for them to get up, go
>: to work, go to the tavern, eat dinner, go home, go to sleep...call
>: the guards if you attacked/stole from them, etc etc. All this at 8
>: mHz with 512k of RAM - and you're telling me we can't duplicate this
>: on a Sun10 with 64 megs of RAM?
>
>Ultima however was not a multi-user game, where a multitude of mobiles
>were going on. The core of a system like Ultima (and making it possible
>on relatively slow computers with not too much memory) usually lies in
>decent management of event lists, ensuring that mobiles which are out of
>view do not cause computational overhead except for expected encounters
>by wandering into the field of view. This could be done on muds also, but
>it is more difficult because you deal with multiple users.
Most certainly, but altogether possible. It seems a bit silly to me
when people just dismiss the whole idea out of hand because of "not
enough processor power/memory/whatever".
>I once wrote a mobile coordinator for an area where inactive rooms were
>cleaned up, and the mobile was stored in a special floating location. Each
>room in the area made a call to the coordinator (either upon being loaded
>or when being entered by the first player or mobile). The coordinator would
>then bascially compute the 'history' of the mobiles to cover the time spent
>in limbo, calculating their current position, and any who end up in the
>room are placed there. It actually saved a good deal of room loading, and
>still didn't end up in the "everything stops when people leave the area".
>The system was rather crude back then, and was never finished due to other
>tasks, but it was a start.
Hmmm...interesting, and I like it, but it becomes less necessary to
do this sort of thing every day, as technology presses onwards. A
few fairly simple optimizations are really sufficient; namely, not
bothering with giving critters like rabbits and butterflies complex
AI, and putting mobs/objects in non-occupied areas into a temporary
statis (shifting them to a list where they get a slower update).
Orion Henry
>> : There was a thread about player "memory" of names and such about six
>> : months back. At the time I seemed to be about the only supporter of
>> : a system where every player has a list of all the people they know,
>
>
>> loss of full overview of who is on the mud, and their names breaks down the
>> contact and cooperation going. Making the knowledge about people more
>> realistic and restricted breaks down one of the cornerstones of many muds
>> these days I think.
>
>group of people a task to perform individually (kill things), forcing a
>subset of them together every now and again (in an Inn setting or not) long
>enough for them to type "#10 buy pie, #10 eat pie" is going to get them
>swapping stories and buying each other drinks. =)
Exactly. Of course, there are a couple problems here - first of
all, that you can buy ten pies and eat them in the space of two
seconds, secondly, that you would consider 10 pies a diverse and
tasty meal, and finally, that buying pies is all there is that's
interesting to do in the inn. One MUD I played (3M, I believe) had
a really nice gambling room - I met TONS of people in there, since
it was a fun place to go. If drinking beer, tossing darts, listening
to bards spin yarns and so on took place in a tavern, I'd be more
inclined to hang out there.
>My system describes players by appearance by default, not by name. Players
>at their own discretion can introduce themselves to each other with a
>simple, non-intrusive one-command-each procedure. The player initiating the
>introduction gives their name first, and the 'target' can choose to respond
>to or ignore the player.
Nice! Here I thought I was the only one that had implemented that.
It's easy, fun, and adds a whole new dimension to social
interaction, which is what muds are all about to begin with.
>I think this opens up a lot more possibilities for roleplaying, if nothing
>else. Assassins and thieves are unlikely to want a 'high profile', wheras
>'good' characters will want to be friendly with a wide range of people.
>You're not restricting player interaction, because the chances are that if a
>player ignores your introduction then they don't want to speak with you
>anyway.
Yeah, plus all kinds of fun stuff that can happen - someone has
introduced himself as a bunch of different names and suddenly runs
into people that all known him by different personalities (remember
"Silke" on those cheesy Eddings books?).
>As for other game aspects, things can be left as they are in most
>circumstances. 'Who' lists don't cause me a problem, even in a proposed
>Real Mud - everyone's name can still be listed. Erm, can't think of
>anything else off-hand.
I'm pretty torn on the whole who-list thing. Basically I figure I'm
going to have to cut it out completely in the long run, but I am
hesitant to do so.
>> I once wrote a mobile coordinator for an area where [...]
>
>Sounds interesting. I've thought about different methods for keeping my
>'Beings' overheads down, and also to tackle the problem of keeping a
>population balance. Speaking of Ultima, I considered a system similar to
>theirs where certain Spaces will contain invisible 'eggs' that (under the
>right circumstances) will spawn one or more Beings when a player enters the
>Space. Anyone have any thoughts on employing that system?
The problem is that this, along with systems which "shut down" areas
that aren't in use, is that on a busy MUD this ceases to be useful,
and thus isn't something you can really rely on, especially if you
plan on having a stable MUD which won't crash all the time to make
all the excess egg-babies disappear. But certainly this could work
just fine. (For some reason I find myself thinking of those little
piles of bones which spawned ghosts in "Gauntlet.")
>This is all part of my ambition to lose the notion of the #RESETS section
>common in DIKU based engines. What I'm after is to have something almost
>like an actual #REBOOT section, which will initialize everything *once* when
>the games comes up and is never looked at again.
I've stuck with repops, but it's quite a bit more subtle. That is,
the system looks at an EMPTY area and considers what needs to be
fixed - doors that should be locked, walls that should be repaired,
mobs that should be "born" to fill holes in the population. If
someone came in and disarmed a guard and ran off with his weapon, it
should load him a new weapon and give it to him. If a citizen of
the town is bleeding in the roadway, I just patch him up a fair bit
- so the wound doesn't just magicaly disappear, but he doesn't just
bleed to death on the road. Eventually I'd like to see this be more
realstic - you wouldn't need repops, it would just send out mobs
that would "take care" of this stuff (medics to help the bleeding
guy, carpenters and stone masons to repair the wall, a guy with a
key to lock the door, the guard going to armory to grab a new
weapon), but at the moment that's rather out of reach unless you're
either willing to put a LOT of work into the system, and limit the
number of mobs in your world to a fairly small number (like say, 500
or less) in order to keep from bogging down the sytem.
Abigail
[Followups set]
In rec.games.mud.lp Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
++ That's interesting - like that law about not being able to take open
++ alcohol containers out of bars? *shrug* this all seems extremely
++ artifical to me, though not having seen it/used a system like this,
++ I guess it might be bad for me to make a judgement.
You mean, healing during combat because you are getting drunk isn't
extremely artifical?
Abigail
Matthew R. Sheahan
Andrew Pierce (ajpi...@med.unc.edu) wrote:
> problem is that this (relatively for most muds) sophisticated behaviour
> means that these mobs are harder to kill than they would be given their
> mob, these mobs are relatively undervalued with respect to mobs of
> equivalent level elsewhere on the mud who lack such a defensive scheme.
i think this is fine because of the effect it brings about: causing
weaker people to pick on isolated individuals and small groups rather
than waltzing through settlements in a berserk fashion. realism begets
realism by force of natural selection. beauty.
chiaroscuro
H. Aurag
Hello there,
Yes I think a lot of us are bord of actually existing muds.
Except for Genesis on which I play, I find all others at best dum versions
(+text-versions) of doom.
However, one has to understand that there are different players:
-Roleplayers. People are there to play a role, and they usually don't mind realism.
-Text-based doomers who are there to kill mobs and solve quests(sometimes knowing its solution from a 'friend').
SO, you must must understand that once you started getting realist you decide
to lose the second category of players and this is majority on muds today.
I suggested realism on Genesis even though, I have to say it is best
at that level.
But most resistance came from players.
Maybe we should rely only on category 1 players.
Good luck. And tell me of your mud when you do it. I'd love to roleplay it.
Chris Lawrence (Contra)
Raz (r...@mushroom.demon.co.uk) wrote:
: My system describes players by appearance by default, not by name. Players
: at their own discretion can introduce themselves to each other with a
: simple, non-intrusive one-command-each procedure. The player initiating the
: introduction gives their name first, and the 'target' can choose to respond
: to or ignore the player.
I have slated to do something like this.
By default you don't see other player's names when you see them,
merely a player-defined description (which could be their name
admittedly). I then allow players to name each other.
> l
Small hut.
Its small, dirty, and smells.
A anorexically thin elf leans nearby.
> elf "Hi!"
You say "Hi!" to the elf.
> name elf bubba
You name the elf "bubba".
> l
Small hut.
...
Bubba is here.
> bubba "Are you new here?"
You say, "Are you new here?" to Bubba.
Bubba says, "No, been here a while. My name's Gandalf -- what's yours?"
At this point you could add another name for the elf, as "Gandalf", or
you could just refer to him as Bubba without him ever knowing it. In
this way everybody can have different names for everybody else -- just
so long as those names are unique within the range of names THAT
player has.
This (hopefully) will make for very interesting times for when two
players get together to talk about a third:
1: Hey, you know old Bubba?
2: Bubba?
1: Yeah, the old elf who hangs around the manor house.
2: Oh, you mean Fogey!
1: Could be. The chap who calls himself Gandalf I think.
Now imagine that "Gandalf" called himself something else to #2:
2: Don't know Gandalf. You sure you don't mean Windy?
1: Dunno. Big tall skinny elf -- likes to talk about XXXX.
2: Yeah, that must be Windy. He said he was gandlaf to you.
1: Yup.
2: Well, the real Gandalf who hangs out over by the woods ain't
gonna like that.
1: Oh, you mean Wiselm?
etc.
: I think this opens up a lot more possibilities for roleplaying, if nothing
: else. Assassins and thieves are unlikely to want a 'high profile', wheras
: 'good' characters will want to be friendly with a wide range of people.
: You're not restricting player interaction, because the chances are that if a
: player ignores your introduction then they don't want to speak with you
: anyway.
True. Or in my instance they may justnot be logged in, and their
character is running on an automation script.
<<I *really* don't like the idea that player characters dissappear
when they log out>>
: As for other game aspects, things can be left as they are in most
: circumstances. 'Who' lists don't cause me a problem, even in a proposed
: Real Mud - everyone's name can still be listed. Erm, can't think of
: anything else off-hand.
Ah. My intention was to provide a two level system: a human player
has an account, and then a number of characters which he can play
under that account (however many characters he creates). My idea was
that WHO would only report what _accounts_ were logged in, leaving the
determination of what (or how many) of that account's characters were
being actively played as indeterminate. Then, as you can't tell what
characters an account owns...
Chris Lawrence (Contra)
Orion Henry (ohe...@sdcc10.ucsd.edu) wrote:
: It seems a bit silly to me
: when people just dismiss the whole idea out of hand because of "not
: enough processor power/memory/whatever".
I won't argue this one in the slightest.
: Hmmm...interesting, and I like it, but it becomes less necessary to
: do this sort of thing every day, as technology presses onwards. A
: few fairly simple optimizations are really sufficient; namely, not
: bothering with giving critters like rabbits and butterflies complex
: AI, and putting mobs/objects in non-occupied areas into a temporary
: statis (shifting them to a list where they get a slower update).
Problem: This ignores the possibility of sympathetic systems.
You are the only character in the MUD, and are spending all your time
following around a lowly shopkeeper, a clothier. All the other
mobiles in the game are on the slow list. If they were not on the
slow list, all the rabbits would be eaten by the sudden population
boom in foxes (caused by a player killing the hutsmen), which in turn
causes the butterfly population to explode as all the caterpillars
have masses of more food available from all the forage the rabbits
don't eat. The following year there are so many caterpillars that
they denude vast areas of the land, and your clothier goes bankrupt as
there's no cotton for new clothes, and all the sheep died of
starvation (no grass).
Okay -- its woefully contrived, but you get the idea. I do think that
swapping out or inactivating "unoccupied" areas and objects is a very
Bad Idea in the long run.
Abigail
In rec.games.mud.lp Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
++ Raz (r...@mushroom.demon.co.uk) wrote:
++ : My system describes players by appearance by default, not by name. Players
++ : at their own discretion can introduce themselves to each other with a
++ : simple, non-intrusive one-command-each procedure. The player initiating the
++ : introduction gives their name first, and the 'target' can choose to respond
++ : to or ignore the player.
++ I have slated to do something like this.
++ By default you don't see other player's names when you see them,
++ merely a player-defined description (which could be their name
++ admittedly). I then allow players to name each other.
It is more realistic. That also means it is hard to talk about
others, and tells don't really work well. If my weapon is broken,
and someone says `Wingbat knows how to fix it' then I would
1) like to know if his wingbat is the same as mine, and 2) I
rather don't have to reemember he's the troll with white hair and red
eyes, and not the troll with white hair and green eyes.
I rather not have this realism. (Not to mention the horrors
of the law department receiving complaints about herassment
from `Tinkerbell'. Who's tinkerbell?)
++ True. Or in my instance they may justnot be logged in, and their
++ character is running on an automation script.
++ <<I *really* don't like the idea that player characters dissappear
++ when they log out>>
Yes and no. Automation scripts aren't realistic at all. And I wouldn't
like someone to block the passage for 3 days until they log on
again either.
++ : As for other game aspects, things can be left as they are in most
++ : circumstances. 'Who' lists don't cause me a problem, even in a proposed
++ : Real Mud - everyone's name can still be listed. Erm, can't think of
++ : anything else off-hand.
++ Ah. My intention was to provide a two level system: a human player
++ has an account, and then a number of characters which he can play
++ under that account (however many characters he creates). My idea was
++ that WHO would only report what _accounts_ were logged in, leaving the
++ determination of what (or how many) of that account's characters were
++ being actively played as indeterminate. Then, as you can't tell what
++ characters an account owns...
I've no clue what you mean by this.
Abigail
Chris Lawrence (Contra)
Abigail (abi...@melgor.ny.fnx.com) wrote:
: In rec.games.mud.lp Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: ++ By default you don't see other player's names when you see them,
: ++ merely a player-defined description (which could be their name
: ++ admittedly). I then allow players to name each other.
: It is more realistic. That also means it is hard to talk about
: others, and tells don't really work well.
True, discussion of a third party, as I gave in my example, can become
messy. However tells (or @pages depending on your server heritage)
continue to work file -- they just run thru your alias list.
: If my weapon is broken,
: and someone says `Wingbat knows how to fix it' then I would
: 1) like to know if his wingbat is the same as mine,
The only semi-guaranteed way of doing that would be to insitute some
for of character-ID in the game. MUD player social security #'s?
Passports? Character licenses? It could be folded in pretty slickly.
Actually, it also raises the possibility for ID forgers...not bad at
all.
: and 2) I
: rather don't have to reemember he's the troll with white hair and red
: eyes, and not the troll with white hair and green eyes.
Accepted.
: I rather not have this realism. (Not to mention the horrors
: of the law department receiving complaints about herassment
: from `Tinkerbell'. Who's tinkerbell?)
Well, if you're going to have law enforcement, you might as well have
IDs then. Then again, the Heinleinian quote regarding the fact that
the instant any society start requiring its citizenry to carry some
form of ID is also the time to get out of that society may well apply.
: ++ True. Or in my instance they may justnot be logged in, and their
: ++ character is running on an automation script.
: ++ <<I *really* don't like the idea that player characters dissappear
: ++ when they log out>>
: Yes and no. Automation scripts aren't realistic at all. And I wouldn't
: like someone to block the passage for 3 days until they log on
: again either.
There is a passage only wide enough for one to get thru, and a logged
out player is there? Magically summon them, attack them, kill them,
drive them away, there are *lot* of possible solutions.
: ++ : As for other game aspects, things can be left as they are in most
: ++ : circumstances. 'Who' lists don't cause me a problem, even in a proposed
: ++ : Real Mud - everyone's name can still be listed. Erm, can't think of
: ++ : anything else off-hand.
: ++ Ah. My intention was to provide a two level system: a human player
: ++ has an account, and then a number of characters which he can play
: ++ under that account (however many characters he creates). My idea was
: ++ that WHO would only report what _accounts_ were logged in, leaving the
: ++ determination of what (or how many) of that account's characters were
: ++ being actively played as indeterminate. Then, as you can't tell what
: ++ characters an account owns...
: I've no clue what you mean by this.
The human would first log on with an account, and password. He would
then be presented with the set of characters he has created under that
account, and could select which and how many of those characters to
play at any instant.
eg
Welcome to ShadowHouse!
Account: futzerball
Password: ********
Account verified.
Please select the character(s) you wish to play in this session:
1) Bumbleface
2) Sir Aguehurt
3) Rhubarb
4) Bubba
5) Pandalume
6) Hewkard
Choice: 5
Password: ********
Pandalume is now active.
[Pandalume] The Open Praire
...description of room...
> look at me
An almost anorexically thin elf...<description of Pandalume>
> who
Accounts currently logged in:
Brigadoon
Maisonman
McRoverbots
Futzerball
Gomerez
Luxi
Note: The human can't see what characters the other humans behind
accounts Brigadoon, Maisonman, etc are playing.
Note: I explicitly allow a human to play multiple characters at the
same time, both in the sense of seperate and distinct characters, and
in the manner of an over-soul animating and controlling multiple
bodies. This latter of course allows the game of stealing bodies from
mobiles and other players...
Mark Searle
>Let point out a couple of examples. The Evil Black Dragon atop the
>>volcanic peak above the main city raids the city once a year on a
>>certain day (that way we know is coming). He attacks anything that
>>moves, looting all the shops, stores etc.. And why doenst everyone
>>just abandon the city on the day of the raid?? Because if he is not
>>killed he will burn the city to the ground. No shops!! NO INN!!!
>>Solution: Chars band together to take him out. Again not often just
>>once a (Mud) year.
>
>Well, this would be bad coding. Assuming that the black dragon has
>some intelligence, he'd choose his target cities and his times to be
>when they expect him the least and when his gain stands to be the
>greatest. Thus attacking on the same day every year might be rather
>silly, unless he specifically enjoyed the anxiety it caused the
>townspeople anticipating that day.
date on the surface but you've got a couple of problems to deal with.
1) There may be few players on the mud at that time and the whole thing
would be a waste as the imms on would simply save the day; as they
technically should because they are the city's leaders.
2) What kind of self-respecting dragon is going to attack only once a
year? Surely he'd attack every couple of weeks as he only takes a few
minutes to repop on the times he is killed ;)
--
Mark Searle - "All reactionaries are paper tigers." - Chairman Mao.
Orion Henry
>: ++ By default you don't see other player's names when you see them,
>: ++ merely a player-defined description (which could be their name
>: ++ admittedly). I then allow players to name each other.
>
>: It is more realistic. That also means it is hard to talk about
>: others, and tells don't really work well.
>
>True, discussion of a third party, as I gave in my example, can become
>messy. However tells (or @pages depending on your server heritage)
>continue to work file -- they just run thru your alias list.
*gack*
*coke*
*cough*
Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
BWAHAHAHAHAHAHAHAH*snort*choke*cough*
Erm sorry. That was funny. You crack me up man.
>: and 2) I
>: rather don't have to reemember he's the troll with white hair and red
>: eyes, and not the troll with white hair and green eyes.
>
>Accepted.
Definitely there should be a better description than this - scars,
what you're wearing, what you're holding/wielding, hair, eyes, skin
hue, height, weight, build, bearing, etc etc. Although it does
bring up the thing of "all you damn trolls look alike", which is
cool. Most MUDs I play I don't even know what race my best friends
are, because in most cases, who cares? (There are a few exceptions,
like Ebon Mists, where the races actually have different innate
skills.)
Orion Henry
>++ : My system describes players by appearance by default, not by name. Playe
>++ : simple, non-intrusive one-command-each procedure. The player initiating
>
>and someone says `Wingbat knows how to fix it' then I would
>rather don't have to reemember he's the troll with white hair and red
>eyes, and not the troll with white hair and green eyes.
>of the law department receiving complaints about herassment
>from `Tinkerbell'. Who's tinkerbell?)
You're looking at it all wrong. This simple feature adds a depth of
play you seem to be overlooking. Let me try to address your
concerns in order. First, yes it's true you may not know who
Wingbat is. It's called exploring and making friends. Yes, soemone
else can introduce themselves as Wingbat - but you don't have to
believe them, and the "real" Wingbat will probably be a bit unhappy
when he finds out someone else is using his/her name (wacky fun
ensues). The bit about the troll with white hair is one of the best
parts of this system - what a great way to procreate racism! Racism
is pretty dull and moronic in real life, but on a MUD it can be a
lot of fun. If you only know one troll, and you know he's a real
asshole, you're likely to mistake others for him. "We don't like
your kind in here..." It also makes it easy for a thief to "blend
in" with the crowd, which changes thieves from being weak warriors
that get one BIG hit at the begining of combat into ...er, well,
thieves. Gasp. Finally, the bit about Tinkerbell - if you report
that one of those nasty humans has been harassing you to the local
officials, they're likely to drag in a human that fits your rough
description. Wacky fun...well, you know.
This stuff is referred to as "role-playing", and won't interest all
players, but I think it will interest some (myself included).
>++ True. Or in my instance they may justnot be logged in, and their
>++ character is running on an automation script.
>
>++ <<I *really* don't like the idea that player characters dissappear
>++ when they log out>>
>
>Yes and no. Automation scripts aren't realistic at all. And I wouldn't
>like someone to block the passage for 3 days until they log on
>again either.
This is something I've yet to see a good solution for. Basically I
figure if you just put a small time delay on quitting/renting once
you've comitted a thievery or a PK or whatever, you've kind of just
got to put up with them being "magically" yanked out of the world.
>++ : As for other game aspects, things can be left as they are in most
>++ : circumstances. 'Who' lists don't cause me a problem, even in a proposed
>++ : Real Mud - everyone's name can still be listed. Erm, can't think of
>++ : anything else off-hand.
>
>++ Ah. My intention was to provide a two level system: a human player
>++ has an account, and then a number of characters which he can play
>++ under that account (however many characters he creates). My idea was
>++ that WHO would only report what _accounts_ were logged in, leaving the
>++ determination of what (or how many) of that account's characters were
>++ being actively played as indeterminate. Then, as you can't tell what
>++ characters an account owns...
>
>I've no clue what you mean by this.
Heh, I have something like this, and I like it A LOT. Message
boards and chat rooms are all accesable from "account mode", and you
can only have one character logged in from your account at a given
time. And having two accounts is kind of silly, because many
options (like races for your characters) are only availible once
characters from your account have achieved certain things. I think
Lost Souls (LPmud) has something similar to this, you might want to
check that out.
Abigail
++ >: ++ merely a player-defined description (which could be their name
++ >: ++ admittedly). I then allow players to name each other.
++ >
++ >: It is more realistic. That also means it is hard to talk about
++ >: others, and tells don't really work well.
++ >
++ >True, discussion of a third party, as I gave in my example, can become
++ >messy. However tells (or @pages depending on your server heritage)
++ >continue to work file -- they just run thru your alias list.
++ *gack*
++ *coke*
++ *cough*
++ Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
++ BWAHAHAHAHAHAHAHAH*snort*choke*cough*
++ Erm sorry. That was funny. You crack me up man.
What's so unrealistic about tells? It's just like picking
up the phone and call your friend, isn't? Oh well, maybe
you live in a part of the world where there aren't phones
yet. ;)
Abigail -- Realism should yield to fun.
Abigail
++ >: months back. At the time I seemed to be about the only supporter of
++ >: a system where every player has a list of all the people they know,
++ >: by what name, how well etc...and the reason shown above is one of the
++ >: many that I think such a system is necessary for any MUD trying to
++ >: achieve the next level of realism.
++ >
++ >Not to fire up the thread again, but from my experiences with players the
++ >loss of full overview of who is on the mud, and their names breaks down the
++ >original intent of e.g. LPmuds where healing through drinking and eating,
++ Er....hmmm, haven't encountered those...?
++ >and the restriction to only be able to drink in the inn itself (and not
++ >carry them - a long lost restriction) was actually meant to get social
++ >contact and cooperation going.
++ That's interesting - like that law about not being able to take open
++ alcohol containers out of bars? *shrug* this all seems extremely
++ artifical to me, though not having seen it/used a system like this,
++ I guess it might be bad for me to make a judgement.
Is it that artifical? Would you care to take a real life experiment?
Select ten bars at random. Order 10 beers at each bar, put them
in your bag, and leave the bar. Now, except for heaving a wet bag
smelling of beer, the bartender will grab you and drag you back in,
because he wants his glasses back.
Abigail
Thomas Hood
Ah, but in most muds, you don't buy GLASSES of beer, it's usually
barrels or bottles. I admit this is not always the case, but it's true
in most diku muds.
Thomas Hood
th...@ganymede.cs.mun.ca
Chris Lawrence (Contra)
Orion Henry (ohe...@sdcc10.ucsd.edu) wrote:
: >++ Ah. My intention was to provide a two level system: a human player
: >++ has an account, and then a number of characters which he can play
: >++ under that account (however many characters he creates). My idea was
: >++ that WHO would only report what _accounts_ were logged in, leaving the
: >++ determination of what (or how many) of that account's characters were
: >++ being actively played as indeterminate. Then, as you can't tell what
: >++ characters an account owns...
: >
: >I've no clue what you mean by this.
: Heh, I have something like this, and I like it A LOT. Message
: boards and chat rooms are all accesable from "account mode", and you
: can only have one character logged in from your account at a given
: time...
Actually I allow multiple characters from a given account to be played
simultaneously, but only one connection to an account at any instant.
The aligns with my whole idea of abstracting the character and his
non-corporeal stats from the body to a seperate object, so that you
can now have a single character with multiple bodies -- which leads to
all sorts of fun when you allow bodies to be stolen from mobiles and
other players.
Stir in a concept of willpower and suppressed ownership, and you can
find yourself still connected to your body, but unable to control it,
and having to watch some other player do with it as he will. Add
gradient scales and you can have willpower fights as you try to resume
control of one of your old bodies, or take over a mobile's or other
player's body.
The end result is that on a single login, a human player can control
one or more characters, each of which has and more or less controls
one or more bodies.
Add in the factor that those "bodies" don't dissappear when their
player logs out, and so are vulnerable to anybody who can find them
and can overcome their protections (everything from Inns to
user-built castles and automation scripts), and the scene assumes a
little more detail. Playing is not so much a process of leading a
single character thru the levels (or however progress is measured) any
more, but of leading a campaign, and balancing the risks of gain and
loss over a larger set of possibilities.
I realise many players won't be interested in these features, and some
will be turned off. But I figure there will be a small set who take
strong advantage of them, providing a complex and rich environment in
ways not seen elsewhere.
Matthew R. Sheahan
H. Aurag (au...@ERE.UMontreal.CA) wrote:
> Yes I think a lot of us are bord of actually existing muds.
if you haven't, please try Lost Souls (lostsouls.org 3000) and let me
know what you think of it.
chiaroscuro
Raz
It was all I could do to contain my excitement when Chris Lawrence (Contra)
wrote:
> There is a passage only wide enough for one to get thru, and a logged
> out player is there? Magically summon them, attack them, kill them,
> drive them away, there are *lot* of possible solutions.
That's the sort of thing I immediately thought of when you first mentioned
your automaton scripts, but I never got around to asking about it before
now:
You are planning to allow all of the above to happen when the human player
is not logged on to defend themselves? From a player's point of view, I
wouldn't like this too much... if someone kills me when I'm offline, I would
natually see it as the game's fault for not defending my character as well
as I could have done.
I agree that having players disappear as blase-y as they do now is a bit
naff, but I can see this turning a lot of players off your game. I assume
you must have safe areas of some sort... are they 100% safe? Realistically,
I suppose such a place couldn't exist =)
[re: multiple characters per account]
> Note: I explicitly allow a human to play multiple characters at the
> same time, both in the sense of seperate and distinct characters, and
> in the manner of an over-soul animating and controlling multiple
> bodies. This latter of course allows the game of stealing bodies from
> mobiles and other players...
...and the practice of multi-players using one of their characters to
inexplicably/inconsistently(/whatever) aid one of their others; something
which (I believe) is frowned upon pretty much across the board..?
You have some plan to stop this, or does it not bother you?
The direction I'm planning to take is to allow players to create a pool of
however many characters they like, but only allow one in-game at a time.
(Pretty much the same as other existing games)
Raz
Thomas Hood
> ++ >: ++ merely a player-defined description (which could be their name
> ++ >: ++ admittedly). I then allow players to name each other.
> ++ >
> ++ >: It is more realistic. That also means it is hard to talk about
> ++ >: others, and tells don't really work well.
> ++ >
> ++ >True, discussion of a third party, as I gave in my example, can become
> ++ >messy. However tells (or @pages depending on your server heritage)
> ++ >continue to work file -- they just run thru your alias list.
>
> ++ *gack*
>
> ++ *coke*
>
> ++ *cough*
>
> ++ Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
>
> ++ BWAHAHAHAHAHAHAHAH*snort*choke*cough*
>
> ++ Erm sorry. That was funny. You crack me up man.
>
> What's so unrealistic about tells? It's just like picking
> up the phone and call your friend, isn't? Oh well, maybe
> you live in a part of the world where there aren't phones
> yet. ;)
>
> Abigail -- Realism should yield to fun.
Yeah, but tells... maybe a good idea would be that all mud-wide channels
would only be available from the starting point, whatever that may be.
Oh, you'd have an emergency channel, but only gods would hear that.
I think that would work. Shout, of course would only be heard a couple
of rooms away.
Thomas Hood
th...@ganymede.cs.mun.ca
Orion Henry
>++ Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
>
>up the phone and call your friend, isn't? Oh well, maybe
>you live in a part of the world where there aren't phones
>yet. ;)
Heh. Again it's all how you look at it - the first MUD I played
didn't have world-wide tells, so it seemed incredibly overpowered to
me when I started playing muds that did. (On my first MUD,
Shadowdale if anyone cares, tells were zone-wide - you had to have a
telepathy spell or a helm of telepathy to talk world-wide.)
On the other hand, this is only a restriction for fantasy MUDs. I
have no idea why there aren't more Blade Runner/Cyberpunk/otherwise
futuristic MUDs. Many of the problems we're talking about removing
fit right in there, such as personal communicators (tells) and
trying to map out vast wildernesses (inside a ship you only have so
many ways you can go, and even planets can be this way ala the
Foundation books or Capitol from Orson Scott Card's Worthing
stories).
Most of the "futurist" muds I've played start you out in the temple
of Midgard with a pair of cool newbie sleeves and a training dagger.
Bleh.
Orion Henry
>> ++ >and the restriction to only be able to drink in the inn itself (and not
>> ++ >carry them - a long lost restriction) was actually meant to get social
>> ++ >contact and cooperation going.
>>
>> ++ That's interesting - like that law about not being able to take open
>> ++ alcohol containers out of bars? *shrug* this all seems extremely
>> ++ artifical to me, though not having seen it/used a system like this,
>> ++ I guess it might be bad for me to make a judgement.
>>
>> Is it that artifical? Would you care to take a real life experiment?
>> Select ten bars at random. Order 10 beers at each bar, put them
>> in your bag, and leave the bar. Now, except for heaving a wet bag
>> smelling of beer, the bartender will grab you and drag you back in,
>> because he wants his glasses back.
>
>Ah, but in most muds, you don't buy GLASSES of beer, it's usually
>barrels or bottles. I admit this is not always the case, but it's true
>in most diku muds.
Barrels, on most that I have played. What does that say about MUD
coders' drinking habbits? :)
Seriously - I would LOVE it if I bought a glass of beer, tried to
leave, and then was dragged back into the bar. There's nothing
wrong with that at all. But I'm guessing it's more like you buy a
glass of beer, then try to leave and it says, "You can't leave yet"
or something similar - I doubt there are any options for trying to
steal the glasses, or shove past whoever is blocking your way, or
whatever.
And therein is the root of any MUD that claims to be realistic. You
shouldn't have to _justify_ rules set in the code, like not letting
people out of bars. Instead, you should create a world where it's
only natural that you can't walk out of a bar with your glass. And
if someone invents glasses that are cheap enough that you _can_
leave with them, then great! As long as nothing is arbitrary, it
should all work fine. You code a _system_ and everything just
works, rather than coding a bunch of little specific routines to
make a bartender do this or that. Difficult? Absolutely. But
trust me when I say the effort is worth it.
Thomas Hood
>>>>>and the restriction to only be able to drink in the inn itself (and not
>>>>That's interesting - like that law about not being able to take open
>>>>alcohol containers out of bars? *shrug* this all seems extremely
>>>>artifical to me, though not having seen it/used a system like this,
You know, it might be cool if you buy a glass of beer, and a mob
instantly appears, blocking the door until you drink the beer and give
the glass to the mob(bouncer or something) then he smiles and leaves.
That would be cool, no?
Thomas Hood
th...@ganymede.cs.mun.ca
Weasel
In article <Dx9Cp...@news2.new-york.net>,
Abigail <abi...@melgor.ny.fnx.com> wrote:
>What's so unrealistic about tells? It's just like picking
>up the phone and call your friend, isn't? Oh well, maybe
>you live in a part of the world where there aren't phones
>yet. ;)
Well if you consider that 95% of the MUDs out there are based in a
fantasy world set in a medieval time period, they're all in a world where
there aren't phones yet.
I admit however, that I enjoy having tells since we lose the
realistic ability to go wake someone up and talk to them at any time of
the day or night that we would have in a world, so it's sort of give and
take...
-Weasel
PoMUD: 128.59.131.31 6666
Steve Christy
On Thu, 5 Sep 1996 11:46:37 GMT, abi...@melgor.ny.fnx.com (Abigail)
wrote:
>In rec.games.mud.lp Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>++ >: ++ By default you don't see other player's names when you see them,
>++ >: ++ merely a player-defined description (which could be their name
>++ >: ++ admittedly). I then allow players to name each other.
>++ >
>++ >: It is more realistic. That also means it is hard to talk about
>++ >: others, and tells don't really work well.
>++ >
>++ >True, discussion of a third party, as I gave in my example, can become
>++ >messy. However tells (or @pages depending on your server heritage)
>++ >continue to work file -- they just run thru your alias list.
>
>++ *gack*
>
>++ *coke*
>
>++ *cough*
>
>++ Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
>
>++ BWAHAHAHAHAHAHAHAH*snort*choke*cough*
>
>++ Erm sorry. That was funny. You crack me up man.
>
>What's so unrealistic about tells? It's just like picking
>up the phone and call your friend, isn't? Oh well, maybe
>you live in a part of the world where there aren't phones
>yet. ;)
>
>
>
>Abigail -- Realism should yield to fun.
Yes, your defense of tells is just so compelling. But why do they get
to make these 'phone calls' to other players for free? And what if
they don't have a phone in their inventory? How high are the long
distance rates? What company did they go with? Do they get bad
connections to players with other companies? What if they're walking
around and the batteries in their cellular go dead?
I can't see the relevance in your comparison... Tells to me are more
like psychic contact.... or something... Though projection? :) I can't
see the realism in this... Although I'm sure some may disagree. Of
course you could always make a modern day or futuristic MUD.
Kris Van Hees
Reply to many many posts:
With all discussion back and forth about nifty realistic things and
the discussion whether it would work and be playable, etc, etc...
Anyone going to do all this and see if there are players who like it
and sufficient performance to make it playable? Discussion is nice, but it's
quite academic right now. people in favour, people who don't believe in it.
Without someone actually doing what they claim would be better I don't see the
discussion ever ending.
Aedil
Abigail
In rec.games.mud.lp Kris Van Hees <ae...@melgor.ny.fnx.com> wrote:
++ Reply to many many posts:
++ With all discussion back and forth about nifty realistic things and
++ the discussion whether it would work and be playable, etc, etc...
++ Anyone going to do all this and see if there are players who like it
++ and sufficient performance to make it playable? Discussion is nice, but it's
++ quite academic right now. people in favour, people who don't believe in it.
++ Without someone actually doing what they claim would be better I don't see the
++ discussion ever ending.
Oh, common, now you are spoiling the fun. ;)
Abigail
Mark Searle
In article <DxEq6...@news2.new-york.net>, Kris Van Hees
<ae...@melgor.ny.fnx.com> writes
>Reply to many many posts:
>
>
>
> Aedil
It'd be possible to code many of the discussed ideas and i personally am
currently trying to apply some of the ideas whilst building for a mud.
Discussion is surely the only way to have progress in mudding.
Kris Van Hees
In rec.games.mud.lp Mark Searle <Ma...@msearle.demon.co.uk> wrote:
: It'd be possible to code many of the discussed ideas and i personally am
: currently trying to apply some of the ideas whilst building for a mud.
"It would be possible" isn't getting anyone anywhere. Trying to apply some of the
ideas is nice, but well... apparantly a "realistic" mud is something like
artificial intelligence: you'll never be able to get people to agree you
accomplished it.
: Discussion is surely the only way to have progress in mudding.
Don't you think that actually implementing things is the only way to have
progress? I remember discussions about distributed muds and all that,
but still have to see the first real distributed mud. I read lots of
discussion about realistic muds with really nifty ideas and regardless of
whether I believe it is even possible... I haven't seen them implemented
yet.
Discussion is good, but it should lead to something, and lots of people are
writing that this and that is needed and possible, but where is it? I have
yet to see the real progress being substantiated anywhere.
Aedil
PS: I have done implementations of small things that were more along the
line of realistic behaviour to give players something to look at. Of
course only few even bothered to look at things, rather than killing
everything on sight. Even when the reactions were like the entire
group of city guards hunting down the player.
Ben Greear
In article <32327d7d...@news.phoenix.net>,
Steve Christy <at...@intcomm.net> wrote:
>>Abigail -- Realism should yield to fun.
>
> Yes, your defense of tells is just so compelling. But why do they get
>to make these 'phone calls' to other players for free? And what if
>they don't have a phone in their inventory? How high are the long
>distance rates? What company did they go with? Do they get bad
>connections to players with other companies? What if they're walking
>around and the batteries in their cellular go dead?
If there are no tells or global channels, you might as well be playing
a single user dungeon. You shouldn't get too technical about fantasy,
after all, in a world where a human wearing a ghastly assortment of
equipment and weapons, carrying 3 times his/her body weight in inventory,
can slay a mighty dragon single handedly, it should be no supprise that
they can somehow communicate to others across their imaginary world.
Ben, who is back from summer vacation, and glad to see the MUD newsgroups
are on topic and spam free!!!
Ben Greear
In article <DxEq6...@news2.new-york.net>,
Kris Van Hees <ae...@melgor.ny.fnx.com> wrote:
>Reply to many many posts:
>
> With all discussion back and forth about nifty realistic things and
>the discussion whether it would work and be playable, etc, etc...
>
> Anyone going to do all this and see if there are players who like it
>and sufficient performance to make it playable? Discussion is nice, but it's
>quite academic right now. people in favour, people who don't believe in it.
>Without someone actually doing what they claim would be better I don't see the
>discussion ever ending.
>
> Aedil
Heh, I started to write a MUD from scratch over a year ago, I'm fairly
diligent and it IS actually starting to take shape, but its a long, long
road as Tom would say. I really DO appreciate all the ideas bantered about,
even if I never plan to implement them, they often lead me on a train of
thought that leads me to come up with a completely new and (novel?? :))
approach to something.
Another thing, most of these changes ppl are talking about are very deep
in the game. It would take a massive overhaul of code to implement these
things, not just something you could sit down in a day or two and get
working, at least that is my opinion :)
Ben
Travis S Casey
Kris Van Hees <ae...@melgor.ny.fnx.com> wrote:
>Reply to many many posts:
>
> With all discussion back and forth about nifty realistic things and
>the discussion whether it would work and be playable, etc, etc...
>
> Anyone going to do all this and see if there are players who like it
>and sufficient performance to make it playable? Discussion is nice, but it's
>quite academic right now. people in favour, people who don't believe in it.
>Without someone actually doing what they claim would be better I don't see the
>discussion ever ending.
There are people out there working on some of these things, including
myself. I can't speak for others, but in my case I'm working on a
master's degree and have a job, a wife, two cats, and an arch position
on an open mud, so I don't have a lot of spare time to work on building
completely new stuff.
I'm slowly working on a new mud in which I'm going to try out a lot of
the ideas that have been batted about here; however, given my situation,
I don't expect to have it ready for opening for about two years yet.
I think you'll find many other people in the same situation... new
coders are still learning what they can do with the stuff they already
have, and don't usually want to push the boundaries of their muds; the
experienced coders who do want to do so, however, generally have less
free time in which to do it.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Administrator, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-7339; Room 011 Love
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
Nathan Fenenga Yospe
On 9 Sep 1996 15:29:13 GMT, ca...@mu.cs.fsu.edu, claiming to be Travis S Casey, posted to rec.games.mud.admin the following:
: Kris Van Hees <ae...@melgor.ny.fnx.com> wrote:
: There are people out there working on some of these things, including
: myself. I can't speak for others, but in my case I'm working on a
: master's degree and have a job, a wife, two cats, and an arch position
: on an open mud, so I don't have a lot of spare time to work on building
: completely new stuff.
: I'm slowly working on a new mud in which I'm going to try out a lot of
: the ideas that have been batted about here; however, given my situation,
: I don't expect to have it ready for opening for about two years yet.
: I think you'll find many other people in the same situation... new
: coders are still learning what they can do with the stuff they already
: have, and don't usually want to push the boundaries of their muds; the
: experienced coders who do want to do so, however, generally have less
: free time in which to do it.
True. I have an interesting situation here. I _am_ involved in far too
many things, and so on and so forth, but I commited to running this Rom2.4
sci-fi educational clone. A month ago, I realized that it would be
actually easier to rewrite the mud from scratch, than to continue working
within the Rom code. Nevertheless, around my other duties, it grows
tiresome. And all the while, me and two others are attempting to finish a
node based, fully 3-D, evolutionary graphical mud, with a capacity of a
few thousand simultanious players, or more, before one of the team members
leaves for grad school.
: --
: |\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
: ZZzz /,`.-'`' -. ;-;;,_ System Administrator, FSU CS department
: |,4- ) )-,_..;\ ( `'-' (904) 644-7339; Room 011 Love
: '---''(_/--' `-'\_) No one agrees with me. Not even me.
: rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
Like the sig.
--
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yo...@hawaii.edu
Kris Van Hees
In rec.games.mud.lp Travis S Casey <ca...@mu.cs.fsu.edu> wrote:
: I think you'll find many other people in the same situation... new
: coders are still learning what they can do with the stuff they already
: have, and don't usually want to push the boundaries of their muds; the
: experienced coders who do want to do so, however, generally have less
: free time in which to do it.
Of course I know the situation, mostly because I am in the same situation.
Well, I have my master's, but have a job, lots of business trips, a driver
to be finished, mudlib design, porting Viking, ...
My point is mostly that the discussions here are very interesting and I
have much interest in them, and follow it closely, but quite alot of ideas
are so exotic or complicated that I doubt they will ever get implemented,
though still it goes back and forth on how it should work and everything.
Why not concentrate on establishing what is realistic in design and can be
implemented in a realistic way. Artificial intelligence in mobiles is nice,
but I doubt anyone will have the time to do it. For games like MUDs it
seems to me that it is more important to make people believe there is some
nifty mechanism behind things without going to estremes. After all, very
few players really look around and watcvh the world evolve.
Aedil
Chris Lawrence (Contra)
Raz (r...@mushroom.demon.co.uk) wrote:
: It was all I could do to contain my excitement when Chris Lawrence (Contra)
: wrote:
: > There is a passage only wide enough for one to get thru, and a logged
: > out player is there? Magically summon them, attack them, kill them,
: > drive them away, there are *lot* of possible solutions.
...
: You are planning to allow all of the above to happen when the human player
: is not logged on to defend themselves?
Absolutely. Yes.
: From a player's point of view, I
: wouldn't like this too much... if someone kills me when I'm offline, I would
: natually see it as the game's fault for not defending my character as well
: as I could have done.
I would see the character's death as the fault of either poor
customisation of the defense routines, or just flat-out being
out-classed and overwhelmed by the attacker.
The system's automated combat routines are effective, but not
wonderful. To quote a response from an earlier thread:
} Given three fighters who are effectively equivalent, A, B, and C,
} where A is played by an aggressive and skillful player of topmost
} skill, B is played by an unskilled player who attempts to guide his
} own combat but without ANY skill and so may be worse than the
} automated fighter, and C is played by a player who relies on the
} default game fighting routines, and given three more fighters,
} respectively identical to the above, labelled A', B', and C', the
} table should map out as:
}
} | A B C
} ---+--------------
} A'| 50% 30% 10%
} B'| 70% 50% 40%
} C'| 90% 60% 50%
} |
Where the percentage values are the probability that X will kill X'
as vs X' killing X.
Now the above was written in response to live inter player combat,
with both combatants being able to actively participate. Moving to
the scenario of the logged-off player as vs another, then I would see
the same table still holding true, except that the definitions are
now:
A is a logged off player with highly customised and skilled
automated combat routines.
B is a logged off player with piss-poor automation scripts.
C is a logged off player who relies on the system default automation
scripts.
and A', B' and C' would either be other matching logged off players,
or logged-on players with the original definitions.
Note also that the above patterns can be easily made more complex with
user-written defenses, such as castles, inns, etc, as well as having,
for instance, the attacked character auto-summon other characters to
aid in its defense.
> l
The Small Room
...
JoeBob is here.
> kill joebob
You attack JoeBob.
Suddenly Bubba, Bert, Billy, Ben, and Bussa appear in a flash of
light!
You are attacked by Bubba!
You are attacked by Bert!
You are attacked by Billy!
You are attacked by Ben!
You are attacked by Bussa!
...
You are DEAD!
Bubba. Bert, Billy, Ben, and Bussa dissappear in a flash of light!
: I agree that having players disappear as blase-y as they do now is a bit
: naff, but I can see this turning a lot of players off your game.
Yup. I expect that a *lot* of players won't like it. Then again, I'm
not trying to run a popularity brigade, I'm trying to engineer a
system that __I__ think is fun in the forlorn hope that someone else
might happen to agree -- and having a lot of fun with it in the process.
: I assume
: you must have safe areas of some sort... are they 100% safe?
I have no 100% safe areas. Nothing is guaranteed in that manner.
: Realistically,
: I suppose such a place couldn't exist =)
Exactly. Any user can attempt to program such a place (I allow free
user programming), but then its just up to another user to figure out
a way thru that system.
: [re: multiple characters per account]
: > Note: I explicitly allow a human to play multiple characters at the
: > same time, both in the sense of seperate and distinct characters, and
: > in the manner of an over-soul animating and controlling multiple
: > bodies. This latter of course allows the game of stealing bodies from
: > mobiles and other players...
: ...and the practice of multi-players using one of their characters to
: inexplicably/inconsistently(/whatever) aid one of their others; something
: which (I believe) is frowned upon pretty much across the board..?
: You have some plan to stop this, or does it not bother you?
Actually I see this as a bonus feature, something to be actively taken
advantage of, and something which can make the game world even more
rich, unpredictable, and detailed. Outside of these game design
specific views, I have no plans to stop, curb, or control it, viewing
it not as a technical or game-design problem, but a social problem.
If I ever do make my server available to others (unlikely), then I
guess they could turn off this feeture.
Chris Lawrence (Contra)
Steve Christy (at...@intcomm.net) wrote:
: Yes, your defense of tells is just so compelling. But why do they get
: to make these 'phone calls' to other players for free? And what if
: they don't have a phone in their inventory? How high are the long
: distance rates? What company did they go with? Do they get bad
: connections to players with other companies? What if they're walking
: around and the batteries in their cellular go dead?
I note here that the US telcos have been quietly pushing for *years*
for "free"long distance ala the current "free" local area
calls in most of the US.
Orion Henry
> With all discussion back and forth about nifty realistic things and
>the discussion whether it would work and be playable, etc, etc...
That's the only reason I read this group. Everything else is, IMO,
crap. Ads for crappy MUDs and people bitching about the immortals
on whateverMUD.
> Anyone going to do all this and see if there are players who like it
>and sufficient performance to make it playable?
As to the first, I'm quite sure there are enough to at least get it
started - it will be a niche thing, to be sure, but MUDs in general
are that way so I hardly see it as a problem. As to the second,
yes. Obviously you can't have everything, but with the correctly
designed code and some halfway descent resources, it is most
certainly possible.
>Discussion is nice, but it's quite academic right now.
As I said, I'm enjoying the discussion quite a bit, even though it
is far from academic for me.
>people in favour, people who don't believe in it.
Well, people who don't believe in it shouldn't even be posting to
the thread. There are hundreds of perfectly unrealisitc muds for
them to play, so what is the point in posting, "duh, realism sucks,
and is hard to code"? For people in favor, there are a myrad of
different methods - look at the difference between what JC Lawrence
is doing, and what I'm doing. Worlds apart, but both can be placed
into the category of next-generation, realistic MUDs.
>Without someone actually doing what they claim would be better I don't see the
>discussion ever ending.
As I said, I know that Mr. Lawrence is well into writing one of
these, and mine is nearly done with the coding phase (still got a
lot of bug-hunting and fleshing out on the world).
Thus I hardly call it idle speculation.
Orion Henry
>PS: I have done implementations of small things that were more along the
> line of realistic behaviour to give players something to look at. Of
> course only few even bothered to look at things, rather than killing
> everything on sight. Even when the reactions were like the entire
> group of city guards hunting down the player.
You can't. I think I've mentioned this before - *there is no such
thing as a halfway realistic MUD*. You have to do it totally, or
not at all. Things like clothing sizes, weapon ranges, light
levels, mounted combat, item damage, lighting rooms on fire,
limb-based damage, no classes, no levels, no hitpoints, complex
fatigue systems, intelligent mobiles, shopkeeper hours, languages,
race politics, etc etc, have all been done or attempted before. But
realistic MUDs aren't _about_ these things. It's about writing a
system which is internally conistent, from the ground up, in which
every single item fits like a piece of a jigsaw puzzle, so that the
final result is far more than just the sum of the parts. In a lot
of cases it is subtle differences, but all these differences add up
until you have an entirely different experience. If you think you
can "ease into" a realsitic MUD by adding little features that
qualify as realistic, all you're going to do is annoy players.
Chris Lawrence (Contra)
Kris Van Hees (ae...@melgor.ny.fnx.com) wrote:
: Don't you think that actually implementing things is the only way to have
: progress?
I know a few programmers who are actively engaged in programming
various of the ideas discussed into their servers or games.
: I remember discussions about distributed muds and all that,
: but still have to see the first real distributed mud.
CoolMud? Its out there. It does it. Nobody(?) runs it.
While the idea is cute and the technology required is non trivial but
within the realm of possible, there is no compelling reason for any
two sites to link themselves into a distributed system currently.
: PS: I have done implementations of small things that were more along the
: line of realistic behaviour to give players something to look at. Of
: course only few even bothered to look at things, rather than killing
: everything on sight. Even when the reactions were like the entire
: group of city guards hunting down the player.
I believe that you won't see much reaction until nearly the entire
system has been re-designed to take advantage of and even require the
new methodologies. There are an awful lot of people out there who
won't buy a spanner because their trusty pliers work well enough, even
if they do bugger the nuts.
Weasel
In article <DxGJt...@news2.new-york.net>,
Kris Van Hees <ae...@melgor.ny.fnx.com> wrote:
>Don't you think that actually implementing things is the only way to have
>but still have to see the first real distributed mud. I read lots of
Isn't MUME a distributed MUD? I've never really poked into the
specifics of it, but I think it is...
>Discussion is good, but it should lead to something, and lots of people are
>writing that this and that is needed and possible, but where is it? I have
>yet to see the real progress being substantiated anywhere.
>
>Aedil
There are some people out here that actually implementing this
stuff. You just aren't looking in the right places :) I often troll
through this group to see if anyone has brought up a good idea or a good
line of reasoning for some accomplishable change (ie. "Make the mobs have
complete AI" doesn't work for me :) and I program them into my MUD if I
really like them and think that it makes the MUD more realistic and fun.
-Weasel
PoMUD: tuik.nob.org 6666
--
-=======================--===========================--======================-
"Lying in my bed again, ||"I've often thought that ||"Life is like a
And I cry 'cause you're ||the process of aging could ||dice game man, I'm
not here." ||be slowed down if it had to||in to win."
David Gay
In article <514kh2$h...@apakabar.cc.columbia.edu> wea...@tuik.clar47.rhno.columbia.edu (Weasel) writes:
Isn't MUME a distributed MUD? I've never really poked into the
specifics of it, but I think it is...
No it isn't. It just uses some servers spread around the world for access (and data
compression).
--
David Gay - Yet Another Starving Grad Student
dg...@cs.berkeley.edu
Mark Searle
>In rec.games.mud.lp Mark Searle <Ma...@msearle.demon.co.uk> wrote:
>: It'd be possible to code many of the discussed ideas and i personally am
>: currently trying to apply some of the ideas whilst building for a mud.
>
>"It would be possible" isn't getting anyone anywhere. Trying to apply some of
>the
>ideas is nice, but well... apparantly a "realistic" mud is something like
>artificial intelligence: you'll never be able to get people to agree you
>accomplished it.
believes that muds will progress in the future. I may be the best coder
in the world (if only) and still have no ideas of further developments
in mudding but through the newsgroups ideas are brought up which _could_
be implemented though many would not.
>
>: Discussion is surely the only way to have progress in mudding.
>
>Don't you think that actually implementing things is the only way to have
>progress? I remember discussions about distributed muds and all that,
>but still have to see the first real distributed mud. I read lots of
>whether I believe it is even possible... I haven't seen them implemented
>yet.
yourself :)
>
>Discussion is good, but it should lead to something, and lots of people are
>writing that this and that is needed and possible, but where is it? I have
>yet to see the real progress being substantiated anywhere.
bulletin board of a mud and if that development is popular then other
imms will pick it up and have it on their mud. Since muds are
variations on a theme it becomes simple for an imm to pinch ideas from
another mud to put on theirs. Newsgroups are another medium of
broadcasting potential ideas. This thread is god knows how long so it
obvious that people are concerned about realistic mob behaviour.
>
>Aedil
>
>PS: I have done implementations of small things that were more along the
> line of realistic behaviour to give players something to look at. Of
> course only few even bothered to look at things, rather than killing
> everything on sight. Even when the reactions were like the entire
> group of city guards hunting down the player.
you feel unnapreciated you might as well not bother doing the work.
There are different types of mudder and one of the main differences are
the level-hungry and the socialite, i'm in the latter category.
--
Mark Searle enjoys mudding.
Travis S Casey
>have much interest in them, and follow it closely, but quite alot of ideas
>are so exotic or complicated that I doubt they will ever get implemented,
>though still it goes back and forth on how it should work and everything.
>
>Why not concentrate on establishing what is realistic in design and can be
>implemented in a realistic way. Artificial intelligence in mobiles is nice,
>but I doubt anyone will have the time to do it. For games like MUDs it
>seems to me that it is more important to make people believe there is some
>nifty mechanism behind things without going to estremes. After all, very
>few players really look around and watcvh the world evolve.
Actually, I agree... somewhat. It's good to talk about things that people
might actually be able to do right now--the "rethinking rooms" discussion
seems to have been staying mostly within the realm of what can be done
now.
It's also good to discuss what we'd *like* to do, even if it can't be
done yet. For one thing, people often don't see the downsides of ideas
until they talk them over with others--for example, on the "connecting
muds" debate, a lot of people hadn't thought about the potential problems
that connected muds could create for mud administrators. Secondly, even
if something can't be done yet, it's possible that someone might think up
another way to solve the same problem (or a significant subset of the
problem) that *can* be done right now. Lastly, what isn't possible
today may be possible a few years from now... and having thought about
these things beforehand will help out when we *can* do them.
Raz
It was all I could do to contain my excitement when Kris Van Hees wrote:
> Anyone going to do all this and see if there are players who like it
> and sufficient performance to make it playable?
Of course! You not been reading all these threads through? ;)
Design and coding on my own engine has begun, and aside from the posters
who've followed up so far, I know of at least three other people or teams
working on custom 'real' Mud systems.
Raz
Raz
It was all I could do to contain my excitement when Orion Henry wrote:
[re: Allowing players to introduce themselves]
> Yeah, plus all kinds of fun stuff that can happen - someone has
> introduced himself as a bunch of different names and suddenly runs
> into people that all known him by different personalities (remember
> "Silke" on those cheesy Eddings books?).
Heh, now that you (and Contra) mention this, I should say that I hadn't
actually planned on allowing to players to introduce themselves with any
name they wished =) My system uses the command syntax "introduce [to]
stranger [{number}]", and takes things from there. The 'stranger' is then
told that <player name> introduces themself, whereupon they can either
"introduce [to] <player>" or "ignore <player>".
The only reason for making players use only their chosen name was storage
considerations. Assuming:
- 30 characters per player name
- 100 players in the playerfile (quite a small number)
From my non-coder's viewpoint, I'd imagine that every player would need
their own array of 100 'slots', each slot being 30 bytes in size. After all
the maths is applied, it leaves an array of ~300k purely to record the names
that player A knows players B to n by, which seemed a little too big to me.
Then again, 300k against the 10Mb that a modest mud of today can use, it
sounds piddling. Hmm, perhaps it's time to give my friend another
headache... ;)
> I'm pretty torn on the whole who-list thing. Basically I figure I'm
> going to have to cut it out completely in the long run, but I am
> hesitant to do so.
I don't think you need to, I know I won't. After building in the system of
player introduction, there's no harm in showing the *player* (as opposed to
the player's character) a list of names in an out-of-character context.
Even if the engine allows 'tell's in some shape or form, if you try to
contact a player you don't 'know', then the game will simply report
something along the lines of "You aren't familiar with anyone called...".
If you don't support tell's, as I know you don't, you've got no problem at
all =)
[re: Ultima's 'eggs']
> The problem is that this, along with systems which "shut down" areas
> that aren't in use, is that on a busy MUD this ceases to be useful,
> and thus isn't something you can really rely on, especially if you
> plan on having a stable MUD which won't crash all the time to make
> all the excess egg-babies disappear.
As for population culling, the way I see it is that only the non-Unique
kill-fodder Beings are going to be sprogged in this way, so a simple routine
to periodically check for and purge the oldest Beings still wandering around
and not connected to a player in any way should suffice to balance things
out. Hopefully =)
Raz
Raz
[Moved the following quote from the Mob thread into this one]
It was all I could do to contain my excitement when Orion Henry wrote:
> I've stuck with repops, but it's quite a bit more subtle. That is,
> the system looks at an EMPTY area and considers what needs to be
> fixed - doors that should be locked, walls that should be repaired,
> mobs that should be "born" to fill holes in the population.
Just a part in that paragraph that reminded me of an earlier thing that got
discussed: It would presumably be nice to 'liven up' the playing
environment, for example by allowing characters to hack paths through
forests, rediscovering lost temples, etc, right? Well, getting back to the
challenge of auto-generating Spaces, I'm curious as to how these two ideas
could be brought together efficently.
To elaborate, the forest 'exits' (here the undergrowth blocking passage)
could easily hold values such as resistence to damage and the ammount of
hacking which is necessary to break through it, but this is only easy in
rooms that are predefined. In the so-called 'virtual spaces' that
information could not be remembered though, because fields for this data
wouldn't exist, and assigning those bytes regardless (in the array which
maps coordinates to defined vnums) would be wasteful in the extreme, as in
this case only forest Spaces would make use of it...
I have a feeling I haven't explained that very well, but make what you can
of it =) Anyone have ideas on how a 'living environment' like that could be
supported efficiently? Perhaps I should say *other* ideas: bearing in mind
Carter T Shock's detailed (and overpowering for a poor pleb like me! ;) )
post regarding world storage.
Raz
Orion Henry
>[Moved the following quote from the Mob thread into this one]
>
>> the system looks at an EMPTY area and considers what needs to be
>> fixed - doors that should be locked, walls that should be repaired,
>> mobs that should be "born" to fill holes in the population.
>
>Just a part in that paragraph that reminded me of an earlier thing that got
>discussed: It would presumably be nice to 'liven up' the playing
>environment, for example by allowing characters to hack paths through
>forests, rediscovering lost temples, etc, right? Well, getting back to the
>challenge of auto-generating Spaces, I'm curious as to how these two ideas
>could be brought together efficently.
>To elaborate, the forest 'exits' (here the undergrowth blocking passage)
>could easily hold values such as resistence to damage and the ammount of
>hacking which is necessary to break through it, but this is only easy in
>rooms that are predefined. In the so-called 'virtual spaces' that
>information could not be remembered though, because fields for this data
>wouldn't exist, and assigning those bytes regardless (in the array which
>maps coordinates to defined vnums) would be wasteful in the extreme, as in
>this case only forest Spaces would make use of it...
Well, it's just a matter of how you treat the virtual space. Since
it's all just a lot of linked lists that are empty as long as there
is nothing out there, it would be like that - anything which is
different from the default would be explicitely defined in the list.
Obviously this is rather vague from a code point of view, but I
don't see this as a particularly difficult coding question, more a
matter of what kind of resources you have availible. As I said, I
find the whole "exits" array system somewhat abhorent, especially in
a case like this. Storing where the forest has been "hacked
through" is no different from storing tracks, or roads, or anything
else in the virtual space.
Chris Lawrence (Contra)
Raz (r...@mushroom.demon.co.uk) wrote:
: [re: Allowing players to introduce themselves]
: > Yeah, plus all kinds of fun stuff that can happen - someone has
: > introduced himself as a bunch of different names and suddenly runs
: > into people that all known him by different personalities (remember
: > "Silke" on those cheesy Eddings books?).
: Heh, now that you (and Contra) mention this, I should say that I hadn't
: actually planned on allowing to players to introduce themselves with any
: name they wished =) My system uses the command syntax "introduce [to]
: stranger [{number}]", and takes things from there. The 'stranger' is then
: told that <player name> introduces themself, whereupon they can either
: "introduce [to] <player>" or "ignore <player>".
Actually the whole reason I came up with the feature was that I wanted
the extra complexity of allowing the names user to be using-player
defined. I thought that the whole idea of the name set not being
unique _or_ constant over the MUD would be delightful. Additionally
the requirement for character names to be unique, MUD-wide seems
incredibly artificial and tailored solely for the ease of the
programmers. Its right on a par with game resets and dropping your
EQ when logging out.
: The only reason for making players use only their chosen name was storage
: considerations. Assuming:
: - 30 characters per player name
: - 100 players in the playerfile (quite a small number)
: From my non-coder's viewpoint, I'd imagine that every player would need
: their own array of 100 'slots', each slot being 30 bytes in size. After all
: the maths is applied, it leaves an array of ~300k purely to record the names
: that player A knows players B to n by, which seemed a little too big
: to me.
Nahh, use a list. Let each player have a list whose nodes are of the
form:
node {
Name_To_Use_For_Other_Player
Internal_ObjectID_Of_That_Player
}
Each player's list is then only as long as the number of aliases he
has defined, and the overhead for the node linkages is small.
: Then again, 300k against the 10Mb that a modest mud of today can use, it
: sounds piddling. Hmm, perhaps it's time to give my friend another
: headache... ;)
New ideas and challenges are always fun -- its one of the things I use
these newsgroups for most: To find new ideas and see if my system
could actually implement them.
Probably the only thing I've hit so far that I've been unable to
figure out a good way to do in any consistent manner is something
George Reese (?) said the LP LIMA system had, which is the ability to
use prepositions to position objects relative to each other. Thus you
can have objects, over, under, beside etc other objects. (eg the book
is under the rug).
: > I'm pretty torn on the whole who-list thing. Basically I figure I'm
: > going to have to cut it out completely in the long run, but I am
: > hesitant to do so.
: I don't think you need to, I know I won't. After building in the system of
: player introduction, there's no harm in showing the *player* (as opposed to
: the player's character) a list of names in an out-of-character context.
: Even if the engine allows 'tell's in some shape or form, if you try to
: contact a player you don't 'know', then the game will simply report
: something along the lines of "You aren't familiar with anyone called...".
: If you don't support tell's, as I know you don't, you've got no problem at
: all =)
The other main use of WHO is determining when another human player is
logged on. This is commonly used to form groups, pkill, socialising,
etc, and is why I intend to publish what accounts are logged on (ie
the humans), but not what characters those humans are currently
playing.
: As for population culling, the way I see it is that only the non-Unique
: kill-fodder Beings are going to be sprogged in this way, so a simple routine
: to periodically check for and purge the oldest Beings still wandering around
: and not connected to a player in any way should suffice to balance things
: out. Hopefully =)
About the only thing I can say here is that I stylistically dislike
the concept of de-activating sections of the world, and I believe it
leads to MUD world logical inconsistancies (the state of a game world
section upon entry is now dependant on how recently it was visited
AND the inactive propcesing for that area) and changes the system from
essentially being deterministic to being utterly random.
Chris Lawrence (Contra)
Raz (r...@mushroom.demon.co.uk) wrote:
> > I've stuck with repops, but it's quite a bit more subtle. That is,
> > the system looks at an EMPTY area and considers what needs to be
> > fixed - doors that should be locked, walls that should be repaired,
> > mobs that should be "born" to fill holes in the population.
>
> Just a part in that paragraph that reminded me of an earlier thing that got
> discussed: It would presumably be nice to 'liven up' the playing
> environment, for example by allowing characters to hack paths through
> forests, rediscovering lost temples, etc, right? Well, getting back to the
> challenge of auto-generating Spaces, I'm curious as to how these two ideas
> could be brought together efficently.
This has been tickling the back of my cranium as well. I like the
idea of a stored mutating state for a generated space (or at least
that's the way I think of it.)
> To elaborate, the forest 'exits' (here the undergrowth blocking passage)
> could easily hold values such as resistence to damage and the ammount of
> hacking which is necessary to break through it, but this is only easy in
> rooms that are predefined. In the so-called 'virtual spaces' that
> information could not be remembered though, because fields for this data
> wouldn't exist, and assigning those bytes regardless (in the array which
> maps coordinates to defined vnums) would be wasteful in the extreme, as in
> this case only forest Spaces would make use of it...
Which is probably the reason to explicitly NOT go in this direction.
Its wasteful in the extreme.
> I have a feeling I haven't explained that very well, but make what you can
> of it =) Anyone have ideas on how a 'living environment' like that could be
> supported efficiently? Perhaps I should say *other* ideas: bearing in mind
> Carter T Shock's detailed (and overpowering for a poor pleb like me! ;) )
> post regarding world storage.
>
> Raz
I've encluded Carter's post below as reference material. I suspect
that your confusion sources to his references to R-Trees, Quad-Trees
and the like as that's what got me. Both R-Trees and QuadTrees are
typically used in relation to image processing, but can be adapted for
other uses. Both actually map very nicely (if somewhat indirectly for
QT's) to mapping auto-generated spaces.
Possibly some references on the area would help clear up the
definitions.
From http://www.cs.cuhk.hk/~drsam/methods.html:
--<cut>--
What is R-Tree
A R-Tree, proposed by Antonin Guttman[1], is an index structure for
point and spatial data at the same time. Insert, delete and search can
be intermixed without periodic reorganization. It uses a tuple to
represent a spatial data in the database. In order to retrieve the
data, each tuple has a unique identifier, tuple-identifier. At the
leaf node of a R-Tree, it has index record that can reference the
spatial data. The index record is (I, tuple-identifier). I is an
n-dimensional rectangle and it is the bounding rectangle of the
spatial data indexed. This rectangle is also known as minimal bounding
rectangle, MBR. and each entry in tuple-identifier is the upper and
lower bounds, [upper, lower], of the rectangle along the
dimension. Non-leaf nodes contain entries (I, childnode-pointer) where
I is the minimal rectangle bounding all the rectangles in the lower
nodes' entries. Childnode-pointer is the pointer to a lower node in
the R-Tree. Let M and m<=M/2 be the maximum and minimum number of
entries can be filled into one node respectively.
Properties of R-Tree
A R-Tree satisfies the following properties:
A R-Tree is a height balance tree and all leaves are on the same
level.
Root node has at least two children unless it is the leaf node.
Every non-leaf node contains between m and M entries unless it is
the root.
For each entries (I, childnode-pointer) in a non-leaf node, I is
the smallest rectangle that spatially contains all rectangles in
its child nodes.
Every leaf node contains between m and M index records unless it
is the root.
For each index record (I, tuple-identifier) in a leaf node, I is
the smallest rectangle that spatially contains the n-dimensional
data object represented by the indicated tuple.
R*-Tree
The R-tree is based on a heuristic optimization. The optimization
criterion is to minimize the area of each enclosing rectangle in the
inner nodes. R*-Tree which incorporates a combined optimization of
area, margin and overlap of each bounding rectangle in the inner nodes
was proposed in [6]. For slightly higher implementation cost, it
outperforms the existing R-Tree variants.
Minimizing the area covered by a bounding rectangle should
minimize the dead space. This will improve performance since
decisions which paths have to be traversed, can be taken on higher
level
Minimizing the overlap between bounding rectangles decreases the
number of paths to be traversed.
Minimizing the margin of a bounding rectangle will make the
rectangle more quadratic. It is because for fixed area, the object
with the smallest margin is the square. Quadratic rectangles can
be packed easily and thus building a smaller rectangle.
VP-Tree
Conventional spatial index structures divide the multi-dimensional
vector space into partitions which have approximately the same number
of data points as each other. It facilitates in finding the nearest
neighbor of a given query point because it is only necessary to touch
a small number of partitions. Most partitioning methods are based on
absolute coordinate values of the vector space. R-Tree and R*-Tree
described before use this type of partitioning method. The structures
partitioned in this way are useful for queries based on absolute
coordinates, like range queries. However, in general, it does not
maintain any distance information, such as distance between points
within a partition and the partition's boundaries. Since this
information is critical in pruning the search space for
nearest-neighbor search, index structures using partitioning methods
based on absolute coordinate are thus not so useful for
multi-dimensional nearest-neighbor search.
Nearest-neighbor search by definition is to find out one point with
minimum point-to-point distance from a given query point, so it is
natural to use partitioning method based on relative distance rather
than absolute coordinate values. Vantage-Point tree, or VP-Tree,
method was proposed by Peter N.Yianilos. It uses the partitioning
method based on relative distance and aims for handling
multi-dimensional nearest neighbor search.
As mentioned before, VP-Tree method bases the partitioning on the
relative distances among the data points, rather than their absolute
coordinate values. It also bases on a particular vantage
point. Actually, vantage point is nothing special but a point selected
from a vector space, or a set of data points. However, the choice of
vantage point plays an important role in the performance of indexing
algorithm.
--<cut>--
And for QuadTrees:
--<cut>--
QUADTREE IMAGES by Bob Glickstein
A ``quadtree'' is a means of encoding an image as a tree structure.
Each node of the tree has up to four children. The root node
represents the entire image; its children represent the four quadrants
of the entire image; their children represent the sixteen
subquadrants; the children of those represent the sixty-four
sub-subquadrants, and so on.
A leaf node corresponds to a single pixel, and is marked with the
color of that pixel (in this implementation, black or white only). If
a non-leaf node has two or more children of the same color, then that
color is stored in the parent and the children are deleted. Thus, if
an entire quadrant (subquadrant, sub-subquadrant, etc.) of the image
is white, that information can be stored in a single quadtree node,
and all of the children of that node can be removed.
For certain images, this encoding yields enormous savings in storage
size. Such images are typically line drawings or other bitmaps with
several areas of solid black or white. Images with a lot of dithering
or stippling, such as scanned images, tend to yield little or no
savings in space.
An amusing aspect of quadtrees is that they can be displayed according
to a depth-first or a breadth-first traversal of the tree. In a
depth-first traversal, first the prodemonant color of the entire image
is displayed; then the predominant color of the first quadrant is
displayed; then the predominant color of the first subquadrant of the
first quadrant, and so on. The user can watch the quadrants and
subquadrants being drawn. A breadth-first traversal, however, is much
more interesting. Since it displays first the predominant color of
the entire image, followed by the predominant colors of the four major
quadrants, followed by the predominant colors or the sixteen
subquadrants, and so on, the effect is one of a gradually resolving
image with finer and finer detail at each step.
--<cut>--
Or to look at it another way, R-Trees, VP-Trees, and Quad-Trees
provide a tree data structure where walking the tree from the root
node down towards the leaves provides finer and finer grained data
about the location, with each system providing various optimisations
for that progression. For QT's the progression is exactly that of
providing more and more finely grained data. For R-Trees and the
like, the progression is that of detailing more and more accurately
what data sets (nodes) define a specific location or area.
I've not been able to find a good source for what he describes as
"morton codes", tho I have run into the concept before (and don't
remember any implementation details or algorithms). <<Can anyone help
here?>> However I think the concept he describes is fairly clear and
understandable.
My own thoughts I posted at the time:
} Another option, which could be done as an extension of your idea for
} the mapping/surface portion, is to avoid the concept of continuous
} mapping. Instead only those specific coordinate points (cells) would
} be defined which deliniate changes in pattern in the
} surface/map/object. Additionally a cell could define its linkage, or
} lack of linkage, and the character of that linkage, with other
} immediately proximate points
}
} In this way the map would be be a net of defined points and
} interpolations between those points. A sparsely detailed area would
} consist of very few defined points and render/access quickly. A high
} detailed area would have far more defined points and could provide a
} computational challenge.
In a crude sort of way you could consider this derived from fractal
compression, or at least the concept of a node which marks a change of
characteristic, and having that node also indicate the quality of
the changed characteristic when moving in various directions from the
node bears some resemblance. (eg The node says that this the edge of
the water. Everything to the south and down of the node is water, and
everything else in every other direction is not water)
I believe this could be extended in line with Carter's system to offer
a pretty slick system.
Consider a system ala:
Nodes are only stored if the _location_ of that node indicates a
change in character in whatever that node is describing.
If the characteristic being described is water, there would be nodes
located along the edges of the body of water, but ONLY where the
direction of that edge changed direction. If the character of the
water changed within its space (eg colour, waves, etc) nodes would
only be present at the locations where the characteristic changed.
Thus there would be nodes all around edge of the area where the
water changed from blue to green, with only just enough nodes to
define the shape of that area.
Store the nodes in say an R*-Tree as described above, and finding
the the nodes which affect the view of a player located at
specific coordinates is just a matter of descending the tree
until finding a node which is larger than the player's view, but
whose children are smaller than the player's view. Then just
descend from there to define the area.
Now add in the concept of having multiple trees, with each tree
representing a different characteristic of the "land". Say one tree
could be weather, another could be object locations cross linked with
object descriptions/definitions, a third could be light level, another
define the surface of the land etc.
You could even cross-link the trees to each other to help quickly
locate the nodes relevant to a given area. Heck you could actually
just make it one R*-Tree and have each node be one of a variety of
types so that as the tree is descended the different types fill in as
their unique characteristics change.
Thinking about this has gotten me thinking further about the
possibilities of a true graphical MUD ala VRML. I could see definite
possibilities for coding an R*-Tree of the VRML descriptions of the
various objects in game, and then following an algorithm something
like this to draw the image for the end user:
Presuming that the structure of VRML supports some concept of detail
level, and thus the ability to retrieve only the relevant data about
an object at a given detail level (eg you can't see the crags on the
mountain in the far distance, but you can when you are close to it):
From root of tree, descend tree.
For each node, determine the spatial distance of that node from the
player.
If "close enough", get data from that node at the resolution level
comparable for the distance to the node. ie of the node is close,
get highly detailed data. If farther away, get less detailed.
Draw and render as appropriate, rezz'ing in the image.
Noting again that I don't know squat about VRML, or if it would lend
itself to this at all.
None of this of course registers the _change_ to the location because
of recent events there (eg hack down the trees). This could be done
by inserting nodes in the R-Tree to define new changes in
characterisitic. Consider the case of two nodes:
NodeX<---distance--->NodeY
NodeX is defined as light scrub for everything east of it. NodeY is
defined as heavy forest for everything east of it. (I'm simplifying a
lot here, as normally each node would also define its relationship to
other proximate nodes).
A player happens to be standing somewhere in the light forest, and
lights a fire. There is now a smoke plume, and so a new node is
created.
NodeX(scrub)<--->NodeZ(smoke)<--->NodeY
Later on he walks a bit and hacks out a clearing:
NodeX(scrub)<--->NodeZ(smoke)<--->NodeQ(clearing)<--->NodeY
After a while the fire he started burns out, leaving a charred area:
NodeX(scrub)<--->NodeR(charred)<--->NodeQ(clearing)<--->NodeY
Of course in actual fact the structure would be a heck of a lot
messier than this, as the smoke plume would have to have boundaries,
and would have considerable height. This it would probably be
decribed by say half a dozen nodes sketching out a circle (the base of
the plume) and a series of matching nodes describing how the plume
ascends thru space. Similar would be true for the clearning, and
ultimately for the charred area when it replaces the smoke.
| From: ct...@umiacs.umd.edu (Carter T. Shock)
| Newsgroups: rec.games.mud.admin,rec.games.mud.misc,rec.games.mud.diku
| Subject: Re: Rethinking Rooms
|
| In article <84043946...@mushroom.demon.co.uk>,
| Raz <r...@mushroom.demon.co.uk> wrote:
| >[Conversation moved from 'Skill-based systems' to here =) ]
| >
| >representing the whole world on a matrix of 1m x 1m squares... =)
| >
| [snip]
| >
| >Yep, plus it's a sod to map, and the values on the axes would get
| >astronomical (imaging mapping a world the size of Earth with 1m x 1m
| >units... circumference is, what, 35000kms? Ouch.)
| >
| [snip]
| >Oh, while I remember: my rambling diatribe above doesn't even begin to
| >include the joys of the Z axis! =) It's no problem at all to allow players
| >to fly over any of the outdoor locations in the game,
|
| >From the player's perspective, yeah, it could be a bear to map, but
| then maps (and movement) could be more natural. If we're going to
| allow the player to sight distant objects, then it is reasonable to
| have them map by landmark. (follow the river until you see the
| mountains.. etc. perhaps an orienteering skill? :)
|
| The only other obstacle appears to be disk storage and granularity of
| your grid. In short, the 1m x 1m granularity poses no special
| problems. You can even go smaller if you want. The trick is to map
| only "what's there".
|
| I'm kind of excited to have stumbled on this topic, as I've started to
| build the rudiments of such a toy. The basics go like this:
|
| Assume for the moment that we've got a 1m x 1m gridding of the
| world. We'll talk about how to store it efficiently in a minute.
|
| Rather than keeping all known information about the world in a single
| grid with each cell having lots of attributes, we'll break it up into
| several layers. One layer can be a resource map (description of where
| ores and other fun raw materials are found). Another can be forest
| cover, a third can be water. Each of these can be represented as a
| collection of regions. i.e. there is absolutely no reason to go thru
| the damned grid and mark every single cell as "water" or "not-water".
| You just declare it as a region and throw it into an appropriate
| structure (like a region quadtree or an R-Tree). These fancy spatial
| data structures can store off the whole world in very little space.
|
| For buildings and such, store them as polygons in either an R-Tree or
| a PMR-Quadtree. Again, no reason to ever store off the explicit cells
| in the grid, only those objects that are in the cells.
|
| Elevation is a bit trickier. If you maintain the previous data
| structures in 3-D they can get kinda big, and the average world
| doesn't tend to have many discontinuous tall features (not too many 1
| meter square, mile high objects floating 100 feet off the ground)
|
| You can do elevation with additional region maps, one for each step in
| elevation. Limit things by saying your people can only fly so high
| before the air runs out or dig so deep before they hit magma and fry.
|
| So, how much space does it take to encode a point in an earth sized
| world on a 1m x 1m grid? First things first, cheap and dirty way to do
| a round world as a flat representation is to generate a square matrix
| and stand it on one corner (like a diamond). Moving from square to
| square is trivial except for the edges where you need to wrap the same
| "latitude". Again not hard, but you have to do it. Each cell needs a
| unique code. The earth is about 40,000km around at the equator.
| Let's make it a 40,000km sphere.
|
| 40,000,000m / (2^32) = .009
|
| So, if we grid the earth using a long integer, minimum granularity is
| what? 9 millimeters?
| So, "longitude" and "latitude" are longs.
| Altitude...
| Make the earth's crust and breatheable atmosphere 20 miles deep/high
| ~100K feet
| ~33km
| 2^15 = 32K
|
| So, with a vertical granularity of 1 meter, you can do about 40 miles
| with a 16 bit short.
|
|
| The final trick is coming up with a way to store this stuff off on
| disk such that you can get it back in a hurry. Bonus points if you
| come up with location codes for objects (rooms, structures, people)
| that result in objects that are spatially close being stored close
| together out on the disk.
|
| Again, trivial. Any space filling curve will do. Morton codes
| are easiest. It works like this:
|
| given an x,y,z location, interleave the bits of the three values
| to produce a single key, then sort all objects using that key.
|
| Example: using just x = 5, y = 3
| x = 0101
| y = 0011
|
| y-major code = 00011011
| x-major code = 00100111
|
| The beauty of this is that the code preserves in its most significant
| bits the most significant bits of the individual pieces that were used
| to make it. It's also nice because you can do range searches. To find
| all objects in the list in a 4m x 4m area (assuming a granularity
| of 1m) you search the list with a key like: 1001XXXX The key matches
| any code with 1001 as the first 4 bits and anything in the last 4
| bits. So things like "this sound can be heard for 30 meters" and
| "everybody within a mile radius dies" become trivial.
|
| Sorry about the length, but it really is pretty easy to store a highly
| detailed world without using up gobs of space.
| -Todd
| ..
| |-------------------------------------------------------------------------|
| | Carter T. Shock | University of Maryland |
| | ct...@umiacs.umd.edu | Institute for Advanced Computer Studies |
| | "Onward through the fog..." | #include <std/disclaimer.h> |
Angus Young
Raz (r...@mushroom.demon.co.uk) wrote:
: It was all I could do to contain my excitement when Orion Henry wrote:
: [re: Allowing players to introduce themselves]
: > Yeah, plus all kinds of fun stuff that can happen - someone has
: > introduced himself as a bunch of different names and suddenly runs
: > into people that all known him by different personalities (remember
: > "Silke" on those cheesy Eddings books?).
: Heh, now that you (and Contra) mention this, I should say that I hadn't
: actually planned on allowing to players to introduce themselves with any
: name they wished =) My system uses the command syntax "introduce [to]
: stranger [{number}]", and takes things from there. The 'stranger' is then
: told that <player name> introduces themself, whereupon they can either
: "introduce [to] <player>" or "ignore <player>".
: The only reason for making players use only their chosen name was storage
: considerations. Assuming:
: - 30 characters per player name
: - 100 players in the playerfile (quite a small number)
: From my non-coder's viewpoint, I'd imagine that every player would need
: their own array of 100 'slots', each slot being 30 bytes in size. After all
: the maths is applied, it leaves an array of ~300k purely to record the names
: that player A knows players B to n by, which seemed a little too big to me.
: Then again, 300k against the 10Mb that a modest mud of today can use, it
: sounds piddling. Hmm, perhaps it's time to give my friend another
: headache... ;)
or ~3k if you are ingenious and use some bitwise operations to
store who you know. Each player gets a unique id, if players A's id is
toggled in B's bit string then they know them. Naturally this will grow
in time but is sure a hell of alot better then storing whole names in
an array, both memory wise and search wise to see if you know someone.
Personally, i think the whole have to introduce thing is silly. Muds are
still very much used just for socializing and its hard to talk to do
with all these silly restrictions. Everytime you make a new char you would
spend the next 3 days reintroducing yourself back to your friends so you
can have fun again, sounds like a pain in the butt to me.
: > I'm pretty torn on the whole who-list thing. Basically I figure I'm
: > going to have to cut it out completely in the long run, but I am
: > hesitant to do so.
I'm sure everyone out there at least once has logged on a mud
looking for a person in particular to talk to. fastest way to do it is
type 'who'. I know i wouldnt play on a mud that limited thigns in this way.
: I don't think you need to, I know I won't. After building in the system of
: player introduction, there's no harm in showing the *player* (as opposed to
: the player's character) a list of names in an out-of-character context.
: Even if the engine allows 'tell's in some shape or form, if you try to
: contact a player you don't 'know', then the game will simply report
: something along the lines of "You aren't familiar with anyone called...".
: If you don't support tell's, as I know you don't, you've got no problem at
: all =)
tell joebob dude, i skipped class today and need the homework, what
was it?
game says, 'tells dont work on this mud'
Bah, time for a new mud.
: [re: Ultima's 'eggs']
: > The problem is that this, along with systems which "shut down" areas
: > that aren't in use, is that on a busy MUD this ceases to be useful,
: > and thus isn't something you can really rely on, especially if you
: > plan on having a stable MUD which won't crash all the time to make
: > all the excess egg-babies disappear.
: As for population culling, the way I see it is that only the non-Unique
: kill-fodder Beings are going to be sprogged in this way, so a simple routine
: to periodically check for and purge the oldest Beings still wandering around
: and not connected to a player in any way should suffice to balance things
: out. Hopefully =)
umm..yeah :) (sorry didnt follow this part of the thread)
: Raz
Angus
Kris Van Hees
In rec.games.mud.lp Raz <r...@mushroom.demon.co.uk> wrote:
: It was all I could do to contain my excitement when Kris Van Hees wrote:
: > Anyone going to do all this and see if there are players who like it
: > and sufficient performance to make it playable?
: Of course! You not been reading all these threads through? ;)
My apologies I have indeed not read every single posting mostly due to lack
of interest in some rather (in my opinion) far-fledged ideas.
: Design and coding on my own engine has begun, and aside from the posters
: who've followed up so far, I know of at least three other people or teams
: working on custom 'real' Mud systems.
What I am really waiting for right now (and I realize it will take time) is
a pointer of a mud where one can look at and see something implemented, and
on which then can be commented in a constructive way.
Aedil
Chris Lawrence (Contra)
Kris Van Hees (ae...@melgor.ny.fnx.com) wrote:
: My apologies I have indeed not read every single posting mostly due to lack
: of interest in some rather (in my opinion) far-fledged ideas.
I am interested. What did you consider far-fledged?
laura c mollett
In <50q36a$c...@sdcc12.ucsd.edu> ohe...@sdcc10.ucsd.edu (Orion Henry) writes:
>>++ Did you say TELLs?! TELLS?!?! On a "realistic" MUD?!
>>
>>What's so unrealistic about tells? It's just like picking
>>up the phone and call your friend, isn't? Oh well, maybe
>>you live in a part of the world where there aren't phones
>>yet. ;)
>Heh. Again it's all how you look at it - the first MUD I played
>didn't have world-wide tells, so it seemed incredibly overpowered to
>me when I started playing muds that did. (On my first MUD,
>Shadowdale if anyone cares, tells were zone-wide - you had to have a
>telepathy spell or a helm of telepathy to talk world-wide.)
>On the other hand, this is only a restriction for fantasy MUDs. I
>have no idea why there aren't more Blade Runner/Cyberpunk/otherwise
>futuristic MUDs. Many of the problems we're talking about removing
>fit right in there, such as personal communicators (tells) and
>trying to map out vast wildernesses (inside a ship you only have so
>many ways you can go, and even planets can be this way ala the
>Foundation books or Capitol from Orson Scott Card's Worthing
>stories).
Some of this is in how the players role-play, as much as in how the
overall system is set up. I play on Legend (worldbase is history
"as they believed it was") and played a character Gnat based on the
_Phule's Company_ books. She decided at some point that grouptell
was the equivalent of wrist communicators and started handing them
out to anyone she grouped up with (occasionally real objects, more
often via emotes - who cares this was for role-play :). She then
spent time asking Mother to transmit information (Mother is the
communications expert from the book) etc. etc. Chat, to Gnat, was
more like TV, and tell like opening long-distance person-to-person
communication (via computers, not phones in the book). She wouldn't
talk to someone in the group who wouldn't accept a communicator and
when she wrote up activities for the Legendary Times (Legend's
newsletter), all the gtells were referred to as if accomplished with
wrist communication.
Sure, this would be possible to install as an overall system, but part
of the fun of leaving it open is in flexibility. Gnat could have one
justification for gtell, tell, and chat while other players had another.
(Some think of it as "magic" which doesn't bother Gnat as tech IS
magic to someone not expecting it). I don't really think an overall
system for this is necessary, just encourage the players to think up
an in-character rationalization as that allows a combination of "magic"
and "tech" backgrounds without limiting to one or another.
Laura aka Sabella
Asst Immort, Player Relations
LegendMUD mud.aus.sig.net 9999
Travis S Casey
Raz <r...@mushroom.demon.co.uk> wrote:
>
>To elaborate, the forest 'exits' (here the undergrowth blocking passage)
>could easily hold values such as resistence to damage and the ammount of
>hacking which is necessary to break through it, but this is only easy in
>rooms that are predefined. In the so-called 'virtual spaces' that
>information could not be remembered though, because fields for this data
>wouldn't exist, and assigning those bytes regardless (in the array which
>maps coordinates to defined vnums) would be wasteful in the extreme, as in
>this case only forest Spaces would make use of it...
One possibility would be to allow for several different "room" data
structures; in an object-oriented language, this could be done without
too much trouble. In standard C, it could be done by using structs
to hold data that can vary for different types of room, having a void
pointer to point to that struct, and putting a code in either the main
room data or the struct itself to indicate which type of room this is.
The code for handling rooms would probably have to be extensively
modified to handle this, but I don't know for sure... I'm not a Diku
person, just someone who knows C.
In Pascal, you could do this with variant records... but I don't think
anyone out there is writing muds in Pascal. :-)
Nick
Personaly I think more realistic mobs and other ideas for more realism
should be used to promote player interaction. I personaly feel it's more
fun to compete with other intelegence oppenents.
To give an example I think someone mentioned that on one mud if you attack
a city guard, it would call for other guards to help it. I think it
would be more realistic (and fun) if in addition to this a player was
elected at the mayor of the city, who commanded the guards. He would also
set taxes and use that money to hire new guards and whatever else is
needed to run a city. He could make laws in the city (set flags for what
the guards will attack you for ie killing a player or mob, stealing from a
player or mob), and determine what patrols the city guards run, etc.
These things could of course lead to conflict with other players. What do
you do if you set up a tax to enter the city and a high level player
decides to kill the tax collector and guards instead of paying it? The
mayor would have to replace the tax collector along with any guards that
were killed. Would the mayor then go after the player and try to pk him?
If there is more than one city, there could be inter-city wars. Groups of
players and soldier mobs could be led into attacks on other citys. Losing
cities would be looted making it even more difficult for them to defend
themselves. And the winning city may also be weakened so that it would be
open to attack by a third city.
Other players could also be hired as assitant mayors, or commanders of
guards to take care of higher level charicters who attack guards.
Players could become citizens of a particular city inorder to pay less in
taxes, but could be ordered to fight in wars.
Of course inter-city conficts could be just one part of a totaly realistic
mud, interwoven between guild, clan, race and religous conflicts.
------
Nick Chapman
ni...@mail.bcpl.lib.md.us
pgp public key at http://people.delphi.com/nickchapman/pgp.html
"In an infinte universe, all things are not only possible but, no matter how improbable, certain to exist somewhere at some time."
- Raymond E. Feist
Michael Omotayo Akinde
In article <DxEq6...@news2.new-york.net>, ae...@melgor.ny.fnx.com (Kris Van Hees) writes:
>Reply to many many posts:
>the discussion whether it would work and be playable, etc, etc...
>quite academic right now. people in favour, people who don't believe in it.
>Without someone actually doing what they claim would be better I don't see the
>discussion ever ending.
This sounds interesting. I'm member of a project group (7th Sem) at the
department of Computer Science at Aalborg University, and our project for
this semester is to develop a form of AI for a MUD. (The alternative was to
make an AI to help in buying cars. :-)) Our supervisor (and the guy who's going
to give us grades at the end of the semester :-() is Claus S. Jensen, one of
the original wizards on Deeper Trouble. (In case you know it.)
Due to limited time - (4 months) - our initial version will have to be pretty
restricted. Also, only one of us has more than a "user-level" acquitance with
MUDS, so there'll probably be some time-wasting as we find out what is realistic
to design and implement. Currently we're expecting to limit ourselves to building
a Mob-AI, in order to make the behaviour of Mobs more "realistic". (I.e. City
guards calling for backup, dragons hoarding gold, trolls doing whatever they do
in Tolkien (turn to stone?) etc.) The AI will probably be implemented with
Bayesian nets (which is much more elegant for this purpose than neural nets, IMO.)
Of course we could keep our project nice and theoretical (we don't even have to
write a line of code, if we don't want to) - but all of us think it'd be cool
if the system we'd develop could actually be used (or built upon) somewhere. Also,
three of us are avid c/c++ programmers, and would very much like to try our
hand at _coding_ this AI.
In other words: We're very much interested in hearing from other MUD'ders, both
with regard to what behavior you think should be coded into such an AI, as well
as people who might be interested in testing such a system out on their own MUD.
(As I've only just joined this newsgroup, I haven't been able to get all of
this discussion.) Our primary job is to code an AI for a MUD, not code a MUD -
so all help and suggestions are welcome.
Regards,
Michael.
stra...@cs.auc.dk
Nathan Fenenga Yospe
On 18 Sep 1996 09:44:36 GMT, stra...@cs.auc.dk, claiming to be Michael Omotayo Akinde, posted to rec.games.mud.admin the following:
: In article <DxEq6...@news2.new-york.net>, ae...@melgor.ny.fnx.com (Kris Van Hees) writes:
: >Reply to many many posts:
: > With all discussion back and forth about nifty realistic things and
: >the discussion whether it would work and be playable, etc, etc...
: > Anyone going to do all this and see if there are players who like it
: >and sufficient performance to make it playable? Discussion is nice, but it's
: >quite academic right now. people in favour, people who don't believe in it.
: >Without someone actually doing what they claim would be better I don't see the
: >discussion ever ending.
I dunno. I'm working on a couple of concepts.
: This sounds interesting. I'm member of a project group (7th Sem) at the
: department of Computer Science at Aalborg University, and our project for
: this semester is to develop a form of AI for a MUD. (The alternative was to
: make an AI to help in buying cars. :-)) Our supervisor (and the guy who's going
: to give us grades at the end of the semester :-() is Claus S. Jensen, one of
: the original wizards on Deeper Trouble. (In case you know it.)
The first mud I ever saw, over the shoulder of a friend. :) I actually got
hooked on Merc derivatives instead, though. Sounds like a fun class. Wish
I could get assignments like that.
: Due to limited time - (4 months) - our initial version will have to be pretty
: restricted. Also, only one of us has more than a "user-level" acquitance with
: MUDS, so there'll probably be some time-wasting as we find out what is realistic
: to design and implement. Currently we're expecting to limit ourselves to building
: a Mob-AI, in order to make the behaviour of Mobs more "realistic". (I.e. City
: guards calling for backup, dragons hoarding gold, trolls doing whatever they do
: in Tolkien (turn to stone?) etc.) The AI will probably be implemented with
: Bayesian nets (which is much more elegant for this purpose than neural nets, IMO.)
Hmmm. One of my projects takes a very different approach. The AI is in the
world generators, which use depletive chaotic update algorithms. This
makes the actions of players completely relavent on the future history of
the world. Mobiles are, in general, temporary constructs of the world, and
fade into the algorithm when they are swapped out of active memory.
(Actually, they are factored into a complex seed for the algorthm, and may
never regenerate. Depends on if the algorithm rates their survival high or
low.) All objects of every type are of a physical class, with no
conceptual differentiation, even for player objects. The interpretation is
at a higher level. Likewise, a player could become anything, though their
functionality could be severely reduced as, say, a rock. Localized AI is
accomplished by a cumulative emulation. In short, NPCs behave exactly how
the game has observed PCs to behave.
: Of course we could keep our project nice and theoretical (we don't even have to
: write a line of code, if we don't want to) - but all of us think it'd be cool
: if the system we'd develop could actually be used (or built upon) somewhere. Also,
: three of us are avid c/c++ programmers, and would very much like to try our
: hand at _coding_ this AI.
The code for ours is sufficient for partial demonstration of concept at
this point.
: In other words: We're very much interested in hearing from other MUD'ders, both
: with regard to what behavior you think should be coded into such an AI, as well
: as people who might be interested in testing such a system out on their own MUD.
: (As I've only just joined this newsgroup, I haven't been able to get all of
: this discussion.) Our primary job is to code an AI for a MUD, not code a MUD -
: so all help and suggestions are welcome.
As I stated, I took the idea of a basis of the mud itself having AI,
rather than the mobiles. Nevertheless, I suspect the real key is to make
the mobiles capable of anything a PC is capable of. Once that is
accomplished, set a behavior algorithm, self modifying, to track a bunch
of PCs. Chaotic models can do quite a bit, once you have the initial
conditions and reactional paths properly set.
Paul McInnes
Kris Van Hees wrote:
>
> In rec.games.mud.lp Mark Searle <Ma...@msearle.demon.co.uk> wrote:
> : It'd be possible to code many of the discussed ideas and i personally am
> : currently trying to apply some of the ideas whilst building for a mud.
>
> "It would be possible" isn't getting anyone anywhere. Trying to apply some of the
> ideas is nice, but well... apparantly a "realistic" mud is something like
> artificial intelligence: you'll never be able to get people to agree you
> accomplished it.
>
>
> Don't you think that actually implementing things is the only way to have
> progress? I remember discussions about distributed muds and all that,
> but still have to see the first real distributed mud. I read lots of
> discussion about realistic muds with really nifty ideas and regardless of
> whether I believe it is even possible... I haven't seen them implemented
> yet.
>
> writing that this and that is needed and possible, but where is it? I have
> yet to see the real progress being substantiated anywhere.
>
>
> PS: I have done implementations of small things that were more along the
> line of realistic behaviour to give players something to look at. Of
> course only few even bothered to look at things, rather than killing
> everything on sight. Even when the reactions were like the entire
> group of city guards hunting down the player.
There are many relatively small decisions that shape the face of a MUD
that can be influenced by this kind of discussion. In particular, having
a chance to bounce ideas of people can be a nice way of working out what
is really important to you, and create a stronger idea of the kind of
"feel" you are trying to create with a mud.
Sometimes this means asking fairly abstract questions like "what do I
mean by realism" or "what do I mean by role-playing". For some people the
answer to the former might simply be that they want a less absured system
of stat development, or a more detailed and realistic interection with
objects. This kind of small-scale tinkering is very much about personal
preference and probably wont have a huge impact on the game, but the
cumulative effect can be substantial, so it doesn't hurt to really get
your ideas and goals clear.
For other people, these kinds of questions can lead to the realistation
that far more substantial changes are required, and whole new elements
need to be added to the MUD. These more substantial changes might be
necessary because the person has a very distinct view on what a MUD might
be, and this kind of discussion is important because it shapes the future
of MUD design. Where will MUDs be in 10 years time? Who knows, but I
suspect that following these newsgroups might provide some interesting
clues.
Ben Greear
In article <51oga4$e...@newsfeed.cs.auc.dk>,
Michael Omotayo Akinde <stra...@cs.auc.dk> wrote:
>In article <DxEq6...@news2.new-york.net>, ae...@melgor.ny.fnx.com (Kris Van Hees) writes:
>
>Due to limited time - (4 months) - our initial version will have to be pretty
>restricted. Also, only one of us has more than a "user-level" acquitance with
>MUDS, so there'll probably be some time-wasting as we find out what is realistic
>to design and implement. Currently we're expecting to limit ourselves to building
>a Mob-AI, in order to make the behaviour of Mobs more "realistic". (I.e. City
>guards calling for backup, dragons hoarding gold, trolls doing whatever they do
>in Tolkien (turn to stone?) etc.) The AI will probably be implemented with
>Bayesian nets (which is much more elegant for this purpose than neural nets, IMO.)
>
>with regard to what behavior you think should be coded into such an AI, as well
>as people who might be interested in testing such a system out on their own MUD.
>(As I've only just joined this newsgroup, I haven't been able to get all of
>this discussion.) Our primary job is to code an AI for a MUD, not code a MUD -
>so all help and suggestions are welcome.
>
>
>Michael.
>stra...@cs.auc.dk
>
Sounds like a good project. I have a few questions and perhaps a
suggestion or two. First of all, are you going to try to make the mobs talk?
I for one never saw an even remotely easy way to do that well, and to do it
cheezy would probably not add much. Also, which mud base are you going
to code from? This choice will probably have a great impact on how and what
you can add to mob's ai.
I realize you are doing this for a grade, and perhaps not just for the
greater good of mud kind, but, if you wish to make it truly useful, and
insure it's inclusion in many muds (this may or may not be your goal), I
think that you would just have to write psuedo-code and let imps of
individual muds do the actual coding.
At any rate, I would love to hear your and other's ideas on what mob AI
should do.
Ben Greear
Unknown
Nick Chapman wrote:
[snip]
> To give an example I think someone mentioned that on one mud if
> you attack a city guard, it would call for other guards to help
> it. I think it would be more realistic (and fun) if in addition
> to this a player was elected at the mayor of the city, who
> commanded the guards. He would also set taxes and use that money
> to hire new guards and whatever else is needed to run a city. He
> could make laws in the city (set flags for what the guards will
> attack you for ie killing a player or mob, stealing from a player
> or mob), and determine what patrols the city guards run, etc.
[snip]
I've been thinking of this for quite a while. I like the idea of
letting players run the world they're part of, different levels of
game play. A ranger might work for an organization, guild, community
or whatever, doing the tasks that the guild assigns to him. The
ranger could explore new territories, draw maps and bring them back
to his employer. The employer, e-g the guild master, plays the game
on a different level. She has to take care of the economies of the
guild, assign missions and tasks for the members and in general work
for whatever the guild stands for.
The guild resides in a building inside a town. The guild is due to
pay rent for the building as well as taxes to the town. The town has
a mayor and a city council which may consist of players as well as
NPC's. Or maybe the town is run by a malicious dictator, a Lord who
took the town by force a couple of years ago, dismissing the council
and appointed one of his own minions as mayor. The Lord and his
minions are of course human players.
The player who controls the Lord is likely to concentrate not on
swinging his sword but on the political climate in the country. Due
to the week ruler (is he an NPC?) of the country, the nobles are
fighting each others, hence making it possible for the Lord, who is
quite strong, to expand his domains.
The point is that the control structure of the whole environment is
decided at run-time by the players and will likely change
dramatically during the course of time.
The players are not 'on the same level' throughout the game. The
Lord in my example above might hire a second player, a notorious
bounty hunter, to do some work for him. The two players play the
same game but while the bounty hunter is out doing his dirty work,
the Lord puts up the strategy for his next war of conquest, hiring
soldiers, spreading propaganda etc.
Did I mention the word implementation?
Just some thoughts,
Malte
--
Malte Tancred
OOPS art, HB
ma...@oops.se
http://www.oops.se/~malte
Mathue Moyer
Ben Greear (gre...@pollux.cs.uga.edu) wrote:
: Sounds like a good project. I have a few questions and perhaps a
: I for one never saw an even remotely easy way to do that well, and to do it
: cheezy would probably not add much. Also, which mud base are you going
: to code from? This choice will probably have a great impact on how and what
: you can add to mob's ai.
Well, I know it isn't as cool as we all might wish, but I always thought a sort
of Ultima-esque implementation might be worth coding, especially sinc it would
be very easy to implement. Just give each mob a (list, tree, whatever you
want to use) of nodes, each of which contains a keyword and a list of replies
with weights. Then implement a special command for talking to mobs... maybe
something like: talk [to] <mob> [about] <subject>
First you check to see if the mob has _anything_ it will respond to, and
respond with something like "<mob> doesn't feel like talking." if it doesn't.
If it _does_ have nodes defined, you search for (a close match to?) the keyword
given by the player and, if found, return one of the possible responses. Of
course, if you do use a weighted list of possible responses for each keyword,
players will never know if they've heard everything the mob has to say on the
subject. ;)
You can also use this mechanism to allow mobs to pass "rumors" back and forth.
This should probably be controlled by flags of some sort... perhaps a "gossip"
flag that indicates the mob will share and accept rumors. When two "gossip"
mobs meet, they could each give the other a response that the other didn't
already have... perhaps this too could be controlled by the weights? Just
randomly choose a node from the (list/tree/whatever) and choose one via weights
to share with the other mob. That would keep the rare rumors rare, and really
spread the common rumors.
You could also have the game itself automatically generate rumors as a result
of certain events. For instance, if a city guard witnesses a Pkilling, a
rumor might start to spread about how player Foo mercilessly slew player Bar.
All sorts of fun stuff available here. :) (IMO, anyway)
--
Mathue Moyer
Email: mat...@cts.com
URL: http://www.users.cts.com/king/m/mathue (once I have time to put it up)
Ben Greear
In article <520tlv$5...@ordeal.cts.com>,
Mathue Moyer <mat...@king.cts.com> wrote:
>Ben Greear (gre...@pollux.cs.uga.edu) wrote:
>
>Well, I know it isn't as cool as we all might wish, but I always thought a sort
>of Ultima-esque implementation might be worth coding, especially sinc it would
>be very easy to implement. Just give each mob a (list, tree, whatever you
>want to use) of nodes, each of which contains a keyword and a list of replies
>with weights. Then implement a special command for talking to mobs... maybe
>something like: talk [to] <mob> [about] <subject>
>
>of certain events. For instance, if a city guard witnesses a Pkilling, a
>rumor might start to spread about how player Foo mercilessly slew player Bar.
>
>All sorts of fun stuff available here. :) (IMO, anyway)
>
>--
> Mathue Moyer
>Email: mat...@cts.com
>URL: http://www.users.cts.com/king/m/mathue (once I have time to put it up)
Yeah, I like that approach. It would still be a little contrived, but I
can see how you could allow some decent rumors/information to leak into
the game this way. I especially like the bit about pkills. The only
problem I can see right away is that unless a great many mobs could talk,
it would be asking a lot of the players to try to talk to one of the few
who could respond, assuming they didn't know who these were in advance.
Also, it would require quite a bit more memory if you had a lot of
gossiping mobs.
Perhaps if you made only a very few who could gossip, and have these
mobs well known so you got the " ____ doesn't feel like talking now."
message only rarely.....
One thing about searching the strings, you would have to use exact matching,
for inexact is a pain in the arse to code, and very time intensive to
execute (by the cpu that is).
Ben Greear
Chris Lawrence (Contra)
Ben Greear (gre...@pollux.cs.uga.edu) wrote:
: One thing about searching the strings, you would have to use exact matching,
: for inexact is a pain in the arse to code, and very time intensive to
: execute (by the cpu that is).
There are quite a few algorithms to do "inexact" matching (eg Soundex)
with most having freely available source. Not all are CPU intensive.
Many in fact have highly optimised PD implementations.
Note: Natural language matches, such as matching "jog" when searching
for "run" are a different kettle of fish.
Mathue Moyer
Ben Greear (gre...@pollux.cs.uga.edu) wrote:
> One thing about searching the strings, you would have to use exact matching,
> for inexact is a pain in the arse to code, and very time intensive to
> execute (by the cpu that is).
Oops... I forgot about that part. :-P Might also want to have "gossip" mobs
occasionally do something like "The Town Crier mutters something about
'a quest'." Or perhaps when mobs share rumors you'd see "You overhear the
Town Crier telling the cityguard something about 'rabbits'."
It's definitely contrived, like you said, but it would still spice things up
a teeny bit. :)
mathue
Travis Siegel
Travis S Casey (ca...@xi.cs.fsu.edu) wrote:
: One possibility would be to allow for several different "room" data
: structures; in an object-oriented language, this could be done without
: too much trouble. In standard C, it could be done by using structs
: to hold data that can vary for different types of room, having a void
: pointer to point to that struct, and putting a code in either the main
: room data or the struct itself to indicate which type of room this is.
: The code for handling rooms would probably have to be extensively
: modified to handle this, but I don't know for sure... I'm not a Diku
: person, just someone who knows C.
: In Pascal, you could do this with variant records... but I don't think
: anyone out there is writing muds in Pascal.
Actually, there is one mud written in pascal.
It's called mymud, and is written for the dos platform.
It comes with full source, and (you guessed it)
it's in pascal. Great thing to play around with.
gry...@iaehv.iaehv.nl
In article <51tl88$f...@parabol.taide.net>, ma...@oops.se <Malte Tancred> wrote:
>Nick Chapman wrote:
>I've been thinking of this for quite a while. I like the idea of
>letting players run the world they're part of, different levels of
>game play. A ranger might work for an organization, guild, community
>or whatever, doing the tasks that the guild assigns to him.
I think this is exactly what a roleplaying game should be like,
Of course some players will hate it because it will force them to
think about what to do and how to go about it, but on a bigger
game it would work out wonderfull I believe.
Now only to find somebody who can make it come to be.
Marian
Chris Gray
[On the expense of having a zillion mob's talking to each other in order
to have nice rumours get around]
Since the interesting rumours are known to the system (it generates them
from interesting events after all), perhaps it can make the mob's only
do the expensive chatting stuff when they have something interesting to
say that the other mob hasn't heard. If there are no player characters
within hearing range (assuming that can be readily determined, which isn't
likely in a complex setup), you can just transfer the info directly,
instead of having to speak out loud. The "interesting" checks can be
something as simple as assigning increasing numbers to the rumours. If
mob A meets mob B, then check mob B's latest number versus mob A's. If
they aren't the same, transfer rumours between the two. You *will* miss
some using that technique, but then real life does too. Some rumours
might even die out.
Oh, and be sure to garble the rumour as it spreads!
--
Chris Gray c...@ami-cg.GraySage.Edmonton.AB.CA
Gerhard Hoogterp
ca...@xi.cs.fsu.edu (Travis S Casey) wrote:
>In Pascal, you could do this with variant records... but I don't think
>anyone out there is writing muds in Pascal. :-)
Getting sick of all these boneheads here who keep on telling that you
can only do MUDS in C on Unix boxes I wrote MyMUD. It's pascal with
versions for DOS and OS/2. Full source and usable on every LAN which
allows you to share a directory.
It shares a single database over the LAN which is used by the MUD
program. Every player starts the program under DOS or OS/2. It's just
an other model than the unix MUDs where everybody logs in on one
program. Here everybody logs in on one database.
And no, it can't handle hunderds of users at the same time. But if you
have a studentshouse with a LAN it's capable enough.
You can find the latest 2.2 version at:
http://slo-lijn.slo.nl/~gerhard/software
I would love to hear comments of people who realy used MyMUD..
Actualy there are two other MUD engines in Pascal. TPMUD (I think,
check ftp://ftp.math.okstate.edu/pub/Muds/servers) for which the
author was so afraid for his copyrights that we never heared from it
again (no source) and there's an engine at the TurboPascal programmers
page. (http://www.cs.vu.nl/~jprins/tp.html MyMUD has a link there too.
Check that you have the right one..)
As you see, there's actualy a choice..
--
G.Hoo...@slo.nl
http://slo-lijn.slo.nl/~gerhard
Tavril
In rec.games.mud.diku Gerhard Hoogterp <G.Hoo...@slo.nl> wrote:
: Getting sick of all these boneheads here who keep on telling that you
: can only do MUDS in C on Unix boxes I wrote MyMUD. It's pascal with
: versions for DOS and OS/2. Full source and usable on every LAN which
: allows you to share a directory.
Turbo Pascal is nice and all, but you do realize it blows, right?
Even standard C blows TP out of the water.. Why write a mud in Turbo
Pascal instead of C? Just to prove that Turbo Pascal does indeed compile
source into an executable? If so, try a COBOL mud.. I'm sure it's
possible, and hey, we'll all love you!
Ben Greear
Give the man a break. If he can write it in TP, then more power to him.
Have you written a MUD recently?? I very seriously doubt it. I don't
care what language you write it in, its a long and difficult process and
I can admire anyone who actualy FINISHES one!!
Ben Greear, who is _almost_ done (read 6 months)!!