Muds w/o boring stock races!
David Stone
Hi there. I am interested in finding any MUDs that do not utilize what
I think of as stock races. How many times have you seen this:
Choose a race: Human Elf Half-elf Hobbit Dwarf Ogre
Annoying, isnt it? What especially sucks is that in most cases these
races are also extremely one dimensional, for instance the ogre (or
troll/giant depending on where you go) will basically just get a strength
bonus and be stupid.
What I DO want to see in a MUD that offers races:
1) At least 2/3rds of the races available "non-traditional", ie,
_not_ ELVES, DWARVES, HALFINGS, OGRES, ORCS, HALF-ORCS, PIXIES, GNOMES,
HALF-<WHATEVERS>, etc. (preferably, I would like to see none!!)
2) Races with special advantages/disadvantages beyond simple stat
distribution!
3) Races with atmospheric or distingiushing characteristics (ie, like
the races on BatMUD with emotes, etc.)
4) Races that are not geared towards a single way of life (guild,
profession, etc.)
Some good examples of MUDs like these that I have come across are
BatMUD, DartMUD, RetroActive (topping the chart with 50 some crazy-ass
races, many fairly unique!), Darke MUD, and a few others. I either cannot
(due to slow links, MUD being down, whatever), have already and grown
tired of, or do not wish to play these muds. I would like to add to this
list, however.
Of course, my dream MUD would be one where the player can create the
manner of creature his character will be. I have never heard of such a
beast.
If you have something for me, let me know!
Stig Hemmer
Batmud (mud.bat.org 23):
Races:
Barsoomian, Devil, Catfolk, Duck, Lich, Cromagnon, Draconian, Drow,
Merfolk, Monolith, Cyclops, Dwarf, Elf, Thrikhren, Penguin, Giant,
Ent, Gnome, Zombie, Valar, Troll, Gnoll, Hobbit, Wolfman, Human,
Kobold, Minotaur, Leech, Ogre, Sprite, Orc, Satyr, Tinmen, Vampire.
Info on a semirandomly chosen race:
The Penguin race
General description:
The penguins are an ancient race of polar birds. Their bulky build and weird
appendages (also called flippers) make them a very clumsy but durable race.
Unappreciated by the masses, these cute little birds have unrivaled charisma
and are wiser than generally thought. Even though penguins can't use weapons
their peck is know for its sharp and swift sting. The Grandmaster Penguin
Alvin is now in the happier hunting grounds and wishes that his children will
breed the race.
Stats:
Strength: low Dexterity: very poor
Intelligence: above average Wisdom: good
Constitution: average Size: average
Other features:
They regenerate damage very slowly. They regenerate magic points very fast.
They are inferior to humans and therefore need less experience points. Even
the most difficult arcane powers can be mastered by them. They can fly above
water. They heal faster when in water. They are empathic. This race can only
be joined if you have an invitation from a member of this race.
They know the following spell automatically:
Chill touch 60%
As you can see, there is more to the race than stat modifiers.
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!
Christine Finkbeiner
David Stone <dst...@iris.dissvcs.uga.edu> wrote:
: Hi there. I am interested in finding any MUDs that do not utilize what
: I think of as stock races. How many times have you seen this:
: Choose a race: Human Elf Half-elf Hobbit Dwarf Ogre
: Annoying, isnt it? What especially sucks is that in most cases these
: races are also extremely one dimensional, for instance the ogre (or
: troll/giant depending on where you go) will basically just get a strength
: bonus and be stupid.
: What I DO want to see in a MUD that offers races:
: 1) At least 2/3rds of the races available "non-traditional", ie,
: _not_ ELVES, DWARVES, HALFINGS, OGRES, ORCS, HALF-ORCS, PIXIES, GNOMES,
: HALF-<WHATEVERS>, etc. (preferably, I would like to see none!!)
: 2) Races with special advantages/disadvantages beyond simple stat
: distribution!
: 3) Races with atmospheric or distingiushing characteristics (ie, like
: the races on BatMUD with emotes, etc.)
: 4) Races that are not geared towards a single way of life (guild,
: profession, etc.)
Has anyone seen a mud with the races from the Talislanta game? (There
are NO standard races in that game, not even humans....)
--
------------------------------------
Morg
mo...@primenet.com
Darel Finkbeiner
------------------------------------
ed wrotniewski
>What I DO want to see in a MUD that offers races:
> 1) At least 2/3rds of the races available "non-traditional", ie,
>_not_ ELVES, DWARVES, HALFINGS, OGRES, ORCS, HALF-ORCS, PIXIES, GNOMES,
>HALF-<WHATEVERS>, etc. (preferably, I would like to see none!!)
> 2) Races with special advantages/disadvantages beyond simple stat
>distribution!
> 3) Races with atmospheric or distingiushing characteristics (ie, like
>the races on BatMUD with emotes, etc.)
>4) Races that are not geared towards a single way of life (guild,
>profession, etc.)
The races on Ebon Mists:
Stock but tried and true:
Human, Elf, drow, Dwarf
The not-so-common:
Centaur, Dragatta (named diffrently on other muds), Thri_kreen (darksun
muds), Lizardman
I have seen these nowhere else:
Kenku and Alaghi
The diffrence between OUR race4s and other muds? NO roace gets a single + on
any stat. WHy? Because, we ALL KNOW that all warrior are the +str race, all
clerics the +wis, all theievs the +dex, which is dumb. Why bother with
races? The diffrentiation of the races DOES follow this though...
Human - Learn faster than any other race (bonus on exp)
Elf - Infra, perm detect magic, sneak, hide, Good with bows and longswords
Drow - Infra and detect magic. Free skillspells: Faerie Fire, Magic Missile
and Darkness. Sneak and Hide.
Dwarf - Infra, some bonus hps, regen hps faster than other races, magic
resistance.
Centaur - Bonus hps, bonus stamina, kick for free, which is MUCH more
damaging than the non-centaur kick.
Lizardman - can rbeathe water, immunity to poisons, natural ac bonus, and
can spit a vile acid which has many bad effects :)
Draagtta - Ac bonus, clawd hands, bite, and breathe fire.
Kreen - 2 extra attacks (2 extra arms :) Can leap and bite with a paralyzing
toxin.
Kenku (bird men) = Can fly, turn invisible nearly at will, bite and clawed
hands.
Alaghi (cousins to Yeti) - strong resistance to cold, massive fists that
hurt bad, bonus hps.
Our races are well rounded, and not a single racde if 'best' for a class. I
coded it that way on prpose.
Hades of Ebon Mists
ebonmists.roc.servtech.com 8888
204.181.11.243 8888
S. Findley
Yeah sure a mud can claim to have ten or twenty or however many
interesting sounding races to choose from, but how in how many muds out
there are the different races distinct or even the least bit meaningful
aside from the stats they have? Really... having races is utterly shallow
if the players cannot interact with eachother in a way with impact.
Which I suppose means pkilling, languages,hometowns for each race etc etc.
I can think of maybe 3 or 4 muds which do or attempt to do this well.
Choosing a race in most muds is more like choosing equipment or optimizing
a class. It is just shallow.
UFO
fin...@u.washington.edu (S. Findley) wrote:
Hehe, on StarMUD we have the following races.
Amazon, Android, Derrel, Gargoyle, Human, Klingon, Lionman, Mantris,
Mutant, Narn, Ogryn, Harkonnen, Predator, Psi-Mutant, Psilon, Replicant,
Rubbit, Squat, Troll, Vampire, Werewolf, Vulcan, Weft, Smurf, Sheep,
Centaur, Cyclop and lots of others. (Yes, really.)
All of these races naturally have different stat bonuses, but they also
have completely unique commands at their disposal, for instance
androids can use the 'asystem' command and reconfigure their
internal power towards shields, repair, scanners, are immune
to disease, do not eat/drink and experience other things during
death than for example a human.
Vampires take 1/3 damage from anything that is not fire, unless
a crucifix or garlic is present, and need blood to survive, there
are also special guilds joinable only be characters of a special
race, allowing for racial wars, such as Trolls who join
different clans (And not Diku clans, this is LP) like
clan Blood, clan Bone, and fight internally. (Yes PK is allowed
but optional).
Etc, Smurfs walk around and are cute and snuggly, sheeps bleat,
you name it, well worth a try.
telnet://starmud.solace.mh.se:4000
-Blackheart
Stratavarius
?
Travis S Casey
ed wrotniewski <tou...@cyber1.servtech.com> wrote:
>
>The races on Ebon Mists:
>
>Stock but tried and true:
> Human, Elf, drow, Dwarf
>
>The not-so-common:
> Centaur, Dragatta (named diffrently on other muds), Thri_kreen (darksun
> muds), Lizardman
>
>I have seen these nowhere else:
> Kenku and Alaghi
>
>The diffrence between OUR race4s and other muds? NO roace gets a single + on
>any stat. WHy? Because, we ALL KNOW that all warrior are the +str race, all
>clerics the +wis, all theievs the +dex, which is dumb. Why bother with
>races? The diffrentiation of the races DOES follow this though...
I see... so, if I'm playing a centaur, I can't carry more than other
players, since I don't have a higher strength? Even though my horse
half ought to be able to be able to carry far more than any human?
IMHO, this makes no sense.
People don't always play the race which gets a bonus for their class;
I've seen plenty of people playing humans on plenty of muds, and on
none of those muds did humans get any stat bonuses. Further, in any
real world, it would only make sense that people would tend to do the
things they're naturally suited for.
It sounds to me like you're creating a solution to a problem that
doesn't really exist... but maybe that's just me.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Manager, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-4290; Room 101C Carothers
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
ed wrotniewski
ca...@mu.cs.fsu.edu (Travis S Casey) writes:
>I see... so, if I'm playing a centaur, I can't carry more than other
>players, since I don't have a higher strength? Even though my horse
>half ought to be able to be able to carry far more than any human?
>IMHO, this makes no sense.
>People don't always play the race which gets a bonus for their class;
>I've seen plenty of people playing humans on plenty of muds, and on
>none of those muds did humans get any stat bonuses. Further, in any
>real world, it would only make sense that people would tend to do the
>things they're naturally suited for.
>It sounds to me like you're creating a solution to a problem that
>doesn't really exist... but maybe that's just me.
That problem sure as hell does exist. I'm not saying everyone in the world
does it, hell, I lvoe elves, and most muds I play I pick an elf regardless
of class, but we ALL know that most warriors are the +str races. MOST
wizards are the ones with +int. All that is is a race optimizing the class.
And... who says our centaur cant carry more gear than a human or an elf
could?
Travis S Casey
Aargh... I accidentally replied by email to Ed instead of posting,
and didn't notice because I was in a hurry. Ed, this is an expanded
version of what I wrote to you, since I wasn't rushed this time.
>>I see... so, if I'm playing a centaur, I can't carry more than other
>>players, since I don't have a higher strength? Even though my horse
>>half ought to be able to be able to carry far more than any human?
>>IMHO, this makes no sense.
>
>>People don't always play the race which gets a bonus for their class;
>>I've seen plenty of people playing humans on plenty of muds, and on
>>none of those muds did humans get any stat bonuses. Further, in any
>>real world, it would only make sense that people would tend to do the
>>things they're naturally suited for.
>
>>It sounds to me like you're creating a solution to a problem that
>>doesn't really exist... but maybe that's just me.
>
>That problem sure as hell does exist. I'm not saying everyone in the world
>does it, hell, I lvoe elves, and most muds I play I pick an elf regardless
>of class, but we ALL know that most warriors are the +str races. MOST
>wizards are the ones with +int. All that is is a race optimizing the class.
The question, though, is: Is this a problem? I don't see it as one;
it seems only natural to me that characters would be attracted to
professions that they are naturally well-suited for. Thus, if
ogres are dumb and very strong, ogres would tend to become warriors
rather than mages.
(BTW, the observant might note that Ed's changed his tune a bit...
in his original post he said:
--- begin quoted text ---
The diffrence between OUR race4s and other muds? NO roace gets a single + on
any stat. WHy? Because, we ALL KNOW that all warrior are the +str race, all
clerics the +wis, all theievs the +dex, which is dumb. Why bother with
races?
--- end quoted text ---
He's now saying "most" rather than "all", and "races" rather than
"race". Evidently he's come to the realization that there can be
more than one race with a bonus to a particular attribute. :-)
Taking the view that it is a problem for a moment, however, I don't
see that what you're doing will necessarily solve it. The different
races still have different advantages and disadvantages; maybe all
warriors will tend to be races which have extra hit points now
instead of being races which have extra strength; if so, have you
really accomplished anything?
A better solution, and IMHO, more realistic, solution, might be to
make other abilities more important to the various classes. For
example, you could set things up so that strength adds to damage
done with weapons, constitution to hit points, dexterity to both
ability to hit with a weapon and to ability to dodge, make fighting
skills go up faster for high intelligence characters, make charisma
important for leading NPC troops or intimidating monsters, etc.
This would give warriors a reason to invest in other abilities,
and, if done right, could enhance roleplaying by allowing people
to create characters such as nimble and clever swashbuckling
fighters, etc. The same sort of thing can be done for the areas
of interest to other classes as well.
Another possibility would be to give races disadvantages that work
against the class that their attribute bonuses favor. An ogre,
for example, might have great strength... but be easier to hit
due to his size and slowness, have a hard time finding armor that
will fit him and weapons sized for his grip, and might even have
problems with weapons made for those of lesser strength tending
to break when he uses them.
The point of all this is that there are a lot of other ways one can
try to make the game more balanced. It seems to me that you're
throwing out the baby with the bath water by not allowing attribute
bonuses for race.
>And... who says our centaur cant carry more gear than a human or an elf
>could?
Well, you did, indirectly. You wrote:
--- begin quoted text ---
The diffrentiation of the races DOES follow this though...
<other races cut>
Centaur - Bonus hps, bonus stamina, kick for free, which is MUCH more
damaging than the non-centaur kick.
--- end quoted text ---
I made the logical assumption that, since you didn't mention an
ability to carry more gear than other races, centaurs don't have
that ability. If they do and you didn't mention it... well, I'm
wrong in that case, but I can't be blamed for not knowing what you
didn't tell us.
Orion Henry
[stuff snipped relating to trying to make races more than just a
collection of stat bonuses, and making "the warrior race" and "the
mage race", etc]
>>>It sounds to me like you're creating a solution to a problem that
>>>doesn't really exist... but maybe that's just me.
>>
>>That problem sure as hell does exist. I'm not saying everyone in the world
>>does it, hell, I lvoe elves, and most muds I play I pick an elf regardless
>>of class, but we ALL know that most warriors are the +str races. MOST
>>wizards are the ones with +int. All that is is a race optimizing the class.
>
>The question, though, is: Is this a problem? I don't see it as one;
>it seems only natural to me that characters would be attracted to
>professions that they are naturally well-suited for. Thus, if
>ogres are dumb and very strong, ogres would tend to become warriors
>rather than mages.
Indeed, this is is called role-playing. It's certainly realstic:
guys that are 6'6", strong, and fast will tend to become basket ball
players, while a skinny little dude with an IQ of 180 will tend to
become a physics professor. I don't think it's so much that there
is a problem with this, persay, but rather that races are oftentimes
no more than a bunch of stat modifiers with occasional intrinsics
like infravision. On the first mud I played, drow were _exactly_
identical to elves, except that they got a one lower int and had to
keep a globe of darkness on when out in the sun. Why play a drow,
then? There was absolutely no reason; not even the drow in the
underdark were non-agg against their fellow drow (players). Thus no
one played drow, unless they were feeling bored or just didn't know
the mud very well.
>>The diffrence between OUR race4s and other muds? NO roace gets a single + on
>>any stat. WHy? Because, we ALL KNOW that all warrior are the +str race, all
>>clerics the +wis, all theievs the +dex, which is dumb. Why bother with
>>races?
>
>Taking the view that it is a problem for a moment, however, I don't
>see that what you're doing will necessarily solve it. The different
>races still have different advantages and disadvantages; maybe all
>warriors will tend to be races which have extra hit points now
>instead of being races which have extra strength; if so, have you
>really accomplished anything?
Having played for a (short) while on Ebon Mists, I can say that the
races there are indeed more interesting than on the vast majority of
muds out there. Although there are still a lot of bumpy spots (my
poor dragatta was always freezing to death because he couldn't wear
any cloaks or body armor, yet he was able to breathe fire), he
definitely has a point with what he's saying. There _are_ good
reasons to be warriors of the different races: besides just varying
hitpoints, they have different natural armor classes, intrinsics
like bite, claws, fire breathing, centaur kicks, thri-kreen leaps
(these do a shitload of damage), and other stuff. In addition, not
all of them can wear armor in every location. So while dragata get
a good natural AC, they can't wear any body armor. Thri-kreens
can't wear helmets, so it's hard to use the headbutt skill with
them. Et cetera. There are advantages and disavantages to the
different races beyond stat bonuses, and for once there is no
perfect race for any class. 90% of the muds I've logged onto, there
is absolutely NO reason to make anything but an ogre warrior, an
elves mage, a kender thief...etc.
>A better solution, and IMHO, more realistic, solution, might be to
>make other abilities more important to the various classes. For
>example, you could set things up so that strength adds to damage
>done with weapons, constitution to hit points, dexterity to both
>ability to hit with a weapon and to ability to dodge, make fighting
>skills go up faster for high intelligence characters, make charisma
>important for leading NPC troops or intimidating monsters, etc.
>This would give warriors a reason to invest in other abilities,
>and, if done right, could enhance roleplaying by allowing people
>to create characters such as nimble and clever swashbuckling
>fighters, etc. The same sort of thing can be done for the areas
>of interest to other classes as well.
I would very much like to see more muds where ALL the stats are
important for your character. The main thing with ogres being the
best warriors is simply that dex, int, wis, and charisma are
completely irrelevant for a warrior. Arctic has gotten around this
problem a little bit; int is a huge factor for learning your skills,
wis controls how high your skills cap out, etc. Still, this could
be taken a lot further. In the long run it rarely maters,
especially with the vast amount of +stat gear availible on most
muds. High level characters just wear +int or +wis until their
skills are up, then switch into their "real" gear.
If dex was incredibly important in combat, it might be actually
worth making that elven warrior.
>Another possibility would be to give races disadvantages that work
>against the class that their attribute bonuses favor. An ogre,
>for example, might have great strength... but be easier to hit
>due to his size and slowness, have a hard time finding armor that
>will fit him and weapons sized for his grip, and might even have
>problems with weapons made for those of lesser strength tending
>to break when he uses them.
Yes, definitely. This kind of stuff is so basic that one wonders
why there isn't more of it, other than I suppose the time and effort
it takes to code it.
>The point of all this is that there are a lot of other ways one can
>try to make the game more balanced. It seems to me that you're
>throwing out the baby with the bath water by not allowing attribute
>bonuses for race.
Well, he actually balances it out pretty well, because your starting
stats aren't really relevant. You gain bonuses to your stats
depending on what you use in the early levels. So get into a lot of
melee fighting, your strength and dex go up. As a mage, who will
try to avoid melee altogether, you'll find that they will go up far
less. As I said, it still needs a lot of polishing, but I think his
system has a lot of potential. If nothing else, it is something
_different_ rather than the same old shit we've seen a thousand
times.
>I made the logical assumption that, since you didn't mention an
>ability to carry more gear than other races, centaurs don't have
>that ability. If they do and you didn't mention it... well, I'm
>wrong in that case, but I can't be blamed for not knowing what you
>didn't tell us.
The whole inventory concept is an incredible kludge and completely
unrealistic anyways, so I can't help but to get confused whenever
anyone tries to argue "realism" related to carrying capacity. At
best, I suppose, you can envision inventory as a little cloud of
equipment which follows the player around (yet for some reason, this
cloud weighs them down, where as the equipment they are actually
wearing _doesn't_), and they grab items out of it at random to use.
I guess, then, it makes sense that centaurs should be allowed a
larger cloud of objects to follow them around...? :)
Orion Henry
>>collection of stat bonuses, and making "the warrior race" and "the
>>mage race", etc]
>I just think that stat modifiers shouldn't be thrown out simply
>because they have the potential for negative effects.
Yes.
>IMHO, a well-developed mud should have races that each have
>non-stat advantages and disadvantages unique to that race, and
>that each have a developed, documented culture and psychology.
>This doesn't necessarily have to be very deep, but it should
>be enough to give the players a feel for how this race is different
>from a human in a funny suit with extra powers.
Certainly, and here is the advantage for using races like dwarf,
elf, drow, and ogre - this stuff is already kind of "built in."
Using completely original races takes some real time to do right.
>>I would very much like to see more muds where ALL the stats are
>>important for your character. The main thing with ogres being the
>>best warriors is simply that dex, int, wis, and charisma are
[stuff snipped about D&D]
>Under the new rules, warriors with great strength still have a
>large advantage; however, it's now possible to make a warrior
>without such strength who can compete.
I haven't played a whole lot of D&D lately. To be completely honest
I've never liked their system much. It worked fine a decade and a
half ago, where the DM was a human, but I have no idea why MUDs are
still so hung up on using D&D's outdated notions of AC, hit-n-dam,
stats, levels, experience, and everything else. If you really must
be based off of a pen-and-paper RPG, choose a good one, like
Runequest. But the computer is _not_ a human DM, and pen and paper
RPGs were written with the assumption that the DM wouldn't be great
at math but could come up with original ideas. Obviously a computer
is exactly the opposite of this. So why cling to these old,
outdated systems? It boggles me, that's for sure.
>>>Another possibility would be to give races disadvantages that work
>>>against the class that their attribute bonuses favor. An ogre,
>>>for example, might have great strength... but be easier to hit
>>>due to his size and slowness, have a hard time finding armor that
>>>will fit him and weapons sized for his grip, and might even have
>>>problems with weapons made for those of lesser strength tending
>>>to break when he uses them.
>>
>>Yes, definitely. This kind of stuff is so basic that one wonders
>>why there isn't more of it, other than I suppose the time and effort
>>it takes to code it.
>
>That's definitely a problem. Most muds seem to be thrown up by
>people who have little interest in actually *improving* their
>muds, which is why so many muds simply use stock races and classes
>without any changes. Most people seem to be more interested in
>creating new areas, races, etc., rather than trying to improve
>the basis of the mud.
Well, I guess it's more flashy and therefore more appealing for a
new imp to do stuff like adding a bunch of big-damage mage spells
with names like Frosty Meteor Bombardment of Crushing Destruction
than modify skills so that you learn them with use based on your int
and wis.
But I would certainly say our MUD community could be improved upon
by several orders of magnatude by simple cutting the number of MUDs
out there in one tenth and then putting ten times as much work and
thought into the remaining MUDs. But of course it doesn't work that
way. As it is, 90% of them are crap and only worth playing to hang
around and chat with people than to actually _play_.
>>>The point of all this is that there are a lot of other ways one can
>>>try to make the game more balanced. It seems to me that you're
>>>throwing out the baby with the bath water by not allowing attribute
>>>bonuses for race.
>>
>>Well, he actually balances it out pretty well, because your starting
>>stats aren't really relevant. You gain bonuses to your stats
>>depending on what you use in the early levels. So get into a lot of
>>melee fighting, your strength and dex go up. As a mage, who will
>
>This is a very good system; indeed, I'm currently working on a mud
>where we're setting up a completely skill-based system, where both
>attributes and skills go up through use rather than through experience
>points of some kind. One of the most illogical things on most muds
>is that wizards get better at magic and thieves better at sneaking
>not by using those skills, but by killing things.
Most definitely. This goes back to the stuff we were talking about
in that thread a couple monthes ago that mostly got started because
Marian was bitching that her cleric didn't get better at her spells
by healing people or praying to her god, but by slaying x number of
bunnies.
Of course the main way around this is to either a) award experience
based on many different things, of which killing is only one or b)
ditch experience altogether, which I favor. On Arctic levels are
only interesting for some classes; with my thief, a level makes me
says, "Oh good, a few more hitpoints." But I am truely elated when
I manage to get my steal skill from "average" to "fair."
Power-leveling won't do this for you, only stealing from a number of
different people in a number of situations.
>>>I made the logical assumption that, since you didn't mention an
>>>ability to carry more gear than other races, centaurs don't have
>>>that ability. If they do and you didn't mention it... well, I'm
>>>wrong in that case, but I can't be blamed for not knowing what you
>>>didn't tell us.
>>
>>The whole inventory concept is an incredible kludge and completely
>>unrealistic anyways, so I can't help but to get confused whenever
>>anyone tries to argue "realism" related to carrying capacity. At
>>best, I suppose, you can envision inventory as a little cloud of
>>equipment which follows the player around (yet for some reason, this
>>cloud weighs them down, where as the equipment they are actually
>>wearing _doesn't_), and they grab items out of it at random to use.
>>I guess, then, it makes sense that centaurs should be allowed a
>>larger cloud of objects to follow them around...? :)
>
>The inventory concept *as its implemented on most muds* is rather
>silly; however, that doesn't mean the concept itself is bad.
I think it is. The first time someone explained to me how it worked
in D&D I could barely contain my laughter, but I accepted it as an
easy way to deal with it, since it wasn't really important. Little
did I know that every RPG I would play after that, no mater what the
format, would have some version of this.
>In theory, the inventory is supposed to represent the things that
>the character is carrying; however, on most muds, the only limit
>on carrying things is weight, which allows such ridiculous things
>as a human with a wielded sword, a lit torch, a worn suit of armor,
>another suit of armor, two or three spare weapons... and no bag,
>backpack, or other container. Given that the wielded sword and
>lit torch should be occupying both hands, one has to wonder how
>the rest is being carried.
Indeed. So why have an inventory? You've already got your hands
"slots" - if those are full, you shouldn't be able to carry any
more. Period. So where does this whole "inventory" thing come in?
>Instead of performing their real-world function of allowing someone
>to carry things without using their hands, backpacks on most muds
>reduce the weight of their contents... a concept that makes little
>sense, unless they're anti-gravity backpacks.
The fact that your equipment doesn't weigh you down but the stuff in
your inventory does is absolutely hilarious to me. Or at least, it
would be, if I weren't so tired of it being on just about every MUD
I've ever played.
>On the mud I'm currently working on, we're setting things up so that
>objects have both weight and size, and you're limited in how much
>of each you can carry. Thus, carrying a huge cardboard box which
>requires both hands will prevent you from carrying anything else,
>since your hands are full, even though you can carry a lot more
>weight. Things that are worn still count for weight, but not for
>size, since you don't have to use your hands for them. Lastly, bags,
>etc. can reduce the effective size of things, but not their weight
>(e.g., you could put several items inside the box used in the example
>before; this would increase the weight, but the box would still only
>take two hands to carry).
Sounds good - you've eliminated the concept of inventory.
>A system like this will make backpacks, etc. a necessity for
>those who want to carry a lot.
*gasp*!
>We do presume that everyone
>has normal clothes, which have pockets, but those can't hold
>much.
Pockets are a fairly modern convenience. Chainmail doesn't usually
come with pockets. Besides which, there aren't many things a
character will want to carry that can fit into a pocket.
>The next logical step would be to make the order in
>which things were put into a container important; if a potion
>is buried under a dozen other things in your backpack, you're
>not going to be able to get to it right away. However, we're
>not planning on taking things that far.
Well, don't get me wrong - I like realism, but yeah this is a little
silly. (Anyone here play Ultima 7?) The fun thing about playing an
RPG is that I get to do all the _fun_ stuff with my character, like
swing a sword and ride my horse, whereas there everyday things that
I don't care about are taken care of automatically, like lacing my
shoelaces, chewing my food, taking a shit, and so on. It wouldn't
bother me if you got a little lag for having a cluttered backpack
when you try to get something out, but you wouldn't have to manually
pull stuff out to get to other things.
Travis S Casey
>
>>IMHO, a well-developed mud should have races that each have
>>non-stat advantages and disadvantages unique to that race, and
>>that each have a developed, documented culture and psychology.
>>This doesn't necessarily have to be very deep, but it should
>>be enough to give the players a feel for how this race is different
>>from a human in a funny suit with extra powers.
>
>Certainly, and here is the advantage for using races like dwarf,
>elf, drow, and ogre - this stuff is already kind of "built in."
>Using completely original races takes some real time to do right.
That's true... however, there's a lot of leeway in even the
traditional races. Check out, for example, Tolkein's elves
vs. ElfQuest's elves.
>I haven't played a whole lot of D&D lately. To be completely honest
>I've never liked their system much. It worked fine a decade and a
>half ago, where the DM was a human, but I have no idea why MUDs are
>still so hung up on using D&D's outdated notions of AC, hit-n-dam,
>stats, levels, experience, and everything else. If you really must
>be based off of a pen-and-paper RPG, choose a good one, like
>Runequest. But the computer is _not_ a human DM, and pen and paper
>RPGs were written with the assumption that the DM wouldn't be great
>at math but could come up with original ideas. Obviously a computer
>is exactly the opposite of this. So why cling to these old,
>outdated systems? It boggles me, that's for sure.
I agree... I only used AD&D as an example because more people are
familiar with it than with any other pencil-and-paper RPG. Personally,
I'd rather have a mud resemble GURPS, TORG, or some other modern
paper RPG. Of course, adjustments should be made to the system,
because there are things that computers are better at than human
GMs (e.g., keeping track of detailed info on each character), and
there are things that computers are worse at.
>>That's definitely a problem. Most muds seem to be thrown up by
>>people who have little interest in actually *improving* their
>>muds, which is why so many muds simply use stock races and classes
>>without any changes. Most people seem to be more interested in
>>creating new areas, races, etc., rather than trying to improve
>>the basis of the mud.
>
>Well, I guess it's more flashy and therefore more appealing for a
>new imp to do stuff like adding a bunch of big-damage mage spells
>with names like Frosty Meteor Bombardment of Crushing Destruction
>than modify skills so that you learn them with use based on your int
>and wis.
It definitely is, and the imps who create new weapons, etc. get
more attention. On the muds I've worked on, I've mainly done
"background" work; improving the generic objects that the area
coders make specific objects from. I've many times had people
ask me why I never do anything. :-/
>But I would certainly say our MUD community could be improved upon
>by several orders of magnatude by simple cutting the number of MUDs
>out there in one tenth and then putting ten times as much work and
>thought into the remaining MUDs. But of course it doesn't work that
>way. As it is, 90% of them are crap and only worth playing to hang
>around and chat with people than to actually _play_.
Well, as Sturgeon said, 90% of everything is crap. The biggest
problem that I see is that most people want to start their own
mud; they don't want to work their way up as a wizard on another
mud, learning from the bottom up. Thus, there are a lot of people
out there trying to start muds who don't have the skill or knowledge
to do any major changes to the code they're working from.
>>This is a very good system; indeed, I'm currently working on a mud
>>where we're setting up a completely skill-based system, where both
>>attributes and skills go up through use rather than through experience
>>points of some kind. One of the most illogical things on most muds
>>is that wizards get better at magic and thieves better at sneaking
>>not by using those skills, but by killing things.
>
>Most definitely. This goes back to the stuff we were talking about
>in that thread a couple monthes ago that mostly got started because
>Marian was bitching that her cleric didn't get better at her spells
>by healing people or praying to her god, but by slaying x number of
>bunnies.
>Of course the main way around this is to either a) award experience
>based on many different things, of which killing is only one or b)
>ditch experience altogether, which I favor. On Arctic levels are
>only interesting for some classes; with my thief, a level makes me
>says, "Oh good, a few more hitpoints." But I am truely elated when
>I manage to get my steal skill from "average" to "fair."
>Power-leveling won't do this for you, only stealing from a number of
>different people in a number of situations.
We've done this to some extent on SWmud; characters still have levels
and classes, which determine which skills they can use, but their
chance of success with those skills is highly dependent on practice.
Our players seem to like the system; you'll hear someone yelling,
"I got xx% in yy!" fairly often. :-)
[some cut on inventories]
>>In theory, the inventory is supposed to represent the things that
>>the character is carrying; however, on most muds, the only limit
>>on carrying things is weight, which allows such ridiculous things
>>as a human with a wielded sword, a lit torch, a worn suit of armor,
>>another suit of armor, two or three spare weapons... and no bag,
>>backpack, or other container. Given that the wielded sword and
>>lit torch should be occupying both hands, one has to wonder how
>>the rest is being carried.
>
>Indeed. So why have an inventory? You've already got your hands
>"slots" - if those are full, you shouldn't be able to carry any
>more. Period. So where does this whole "inventory" thing come in?
The inventory is everything you're carrying, regardless of how
you're carrying it. It exists for a simple reason; because the
game needs a list of the things you're carrying. The problem
isn't with the inventory itself; it's with how muds limit what
you can put in your inventory.
As for "two hands, two slots", people can carry things under their arms,
in their teeth, and even tucked between their chin and chest. Not only
that, but it's possible to hold more than one item in one hand--if you're
just carrying them and not wielding them, there's no reason you
can't keep four knives in one hand. Thus, just saying, "You can
only carry one item for each hand you have" isn't realistic either. Of
course, it is *more* realistic than the standard method, and has
the advantage of being easy to implement. :-)
>>On the mud I'm currently working on, we're setting things up so that
>>objects have both weight and size, and you're limited in how much
>>of each you can carry. Thus, carrying a huge cardboard box which
>>requires both hands will prevent you from carrying anything else,
>>since your hands are full, even though you can carry a lot more
>>weight. Things that are worn still count for weight, but not for
>>size, since you don't have to use your hands for them. Lastly, bags,
>>etc. can reduce the effective size of things, but not their weight
>>(e.g., you could put several items inside the box used in the example
>>before; this would increase the weight, but the box would still only
>>take two hands to carry).
>
>Sounds good - you've eliminated the concept of inventory.
Well, we haven't eliminated the inventory... we've just changed
the method of determining what can go into a character's inventory.
>>We do presume that everyone
>>has normal clothes, which have pockets, but those can't hold
>>much.
>
>Pockets are a fairly modern convenience. Chainmail doesn't usually
>come with pockets. Besides which, there aren't many things a
>character will want to carry that can fit into a pocket.
We're building this mudlib for a mud set in 2060. Thus, most
people will have pockets, and there'll be things like identicards,
pocket phones, etc. that will fit easily in pockets, and be
useful.
>>The next logical step would be to make the order in
>>which things were put into a container important; if a potion
>>is buried under a dozen other things in your backpack, you're
>>not going to be able to get to it right away. However, we're
>>not planning on taking things that far.
>
>Well, don't get me wrong - I like realism, but yeah this is a little
>silly. (Anyone here play Ultima 7?) The fun thing about playing an
>RPG is that I get to do all the _fun_ stuff with my character, like
>swing a sword and ride my horse, whereas there everyday things that
>I don't care about are taken care of automatically, like lacing my
>shoelaces, chewing my food, taking a shit, and so on. It wouldn't
>bother me if you got a little lag for having a cluttered backpack
>when you try to get something out, but you wouldn't have to manually
>pull stuff out to get to other things.
I agree... which is another reason why I don't like "one hand,
one slot" systems. Most of those that I've seen require the
player to have a hand free in order to pick something up...
even if it's going straight into a pack. I'd rather not
make the player do something like (indented items are the
mud's responses):
get coins
You don't have a hand free.
drop dagger
Ok.
get coins
Ok.
put coins in bag
Ok.
get dagger
Ok.
Instead, I'd rather let the player simply type:
get coins into bag
Ok.
and let the mud assume that the character goes through the
proper steps to do it.
Eric Pilcher
>Indeed. So why have an inventory? You've already got your hands
>"slots" - if those are full, you shouldn't be able to carry any
>more. Period. So where does this whole "inventory" thing come in?
I once saw a mud in which you had no inventory and two hand slots.
It is my opinion that such a concept is virtually unplayable unless,
of course, you've aliased and actioned a bunch of stuff with TINTIN.
Being realistic, and encouraging TINTIN, I find very contradictory.
Anyway, take the following as an example:
The mob is dead. R.I.P.
> l in corpse
corpse (here):
some coins
a potion
> get all corpse
Your hands are full.
> sheath sword
You put away your sword.
> get all corpse
You get some coins from the corpse.
Your hands are full.
> put coins pouch
You don't see a pouch here.
> remove pouch
Your hands are full.
> drop coins
You drop some coins.
> remove pouch
You remove your beltpouch.
> get coins
Your hands are full.
> drop shield
You drop the shield.
> get coins
You get some coins.
> put coins pouch
You put some coins in a beltpouch.
etc.
Like I said. Unplayable. Unless you use tintin, in which case, it's
unnoticable. So perhaps some realism should be sacrificed in order
to gain some playability.
--
------------------------------------------+-----------------------------
Eric L. Pilcher: ra...@PEAK.ORG | http://www.PEAK.ORG/~rasta
------------------------------------------+-----------------------------
Paul Speed
: The inventory concept *as its implemented on most muds* is rather
: silly; however, that doesn't mean the concept itself is bad.
: In theory, the inventory is supposed to represent the things that
: the character is carrying; however, on most muds, the only limit
: on carrying things is weight, which allows such ridiculous things
: as a human with a wielded sword, a lit torch, a worn suit of armor,
: another suit of armor, two or three spare weapons... and no bag,
: backpack, or other container. Given that the wielded sword and
: lit torch should be occupying both hands, one has to wonder how
: the rest is being carried.
: Instead of performing their real-world function of allowing someone
: to carry things without using their hands, backpacks on most muds
: reduce the weight of their contents... a concept that makes little
: sense, unless they're anti-gravity backpacks.
: On the mud I'm currently working on, we're setting things up so that
: objects have both weight and size, and you're limited in how much
: of each you can carry. Thus, carrying a huge cardboard box which
: requires both hands will prevent you from carrying anything else,
: since your hands are full, even though you can carry a lot more
: weight. Things that are worn still count for weight, but not for
: size, since you don't have to use your hands for them. Lastly, bags,
: etc. can reduce the effective size of things, but not their weight
: (e.g., you could put several items inside the box used in the example
: before; this would increase the weight, but the box would still only
: take two hands to carry).
: A system like this will make backpacks, etc. a necessity for
: those who want to carry a lot. We do presume that everyone
: has normal clothes, which have pockets, but those can't hold
: much. The next logical step would be to make the order in
: which things were put into a container important; if a potion
: is buried under a dozen other things in your backpack, you're
: not going to be able to get to it right away. However, we're
: not planning on taking things that far.
: --
In my spare time I am coding a MUD from scratch. It is nowhere
near done. Anyway, I've coded it so that the number of items you can
carry in your inventory is based on their size and your dexterity. A
person with a high dexterity can possibly ballance things better.
Strength tells how much weight you can carry. This includes clothes and
things in your backpack, belt pouches, etc. Also, I allow things to be
attached to other things. You can put your belt pouches on your belt, a
pin on your cloak. Things like boots and gloves can also be containers so
you can hide things in them. Everything has similar size/weight
capacities. Everything in the MUD is basically an object that is either a
container or not. Rooms, exits, players, items, are all objects with
these properties. A small player can get inside of large containers.
Now if only I'd get off my butt and get the mobiles and combat
working. Oh, well.
-Keys
Orion Henry
>>elf, drow, and ogre - this stuff is already kind of "built in."
>>Using completely original races takes some real time to do right.
>
>That's true... however, there's a lot of leeway in even the
>traditional races. Check out, for example, Tolkein's elves
>vs. ElfQuest's elves.
Indeed. What I meant was, I can choose to make an elven mage and be
pretty confident that's a better combination that a half-giant mage.
[whole bunch o' shit cut out because I agree with it all, so not
much for me to say :)]
>>Indeed. So why have an inventory? You've already got your hands
>>"slots" - if those are full, you shouldn't be able to carry any
>>more. Period. So where does this whole "inventory" thing come in?
>
>The inventory is everything you're carrying, regardless of how
>you're carrying it. It exists for a simple reason; because the
>game needs a list of the things you're carrying. The problem
>isn't with the inventory itself; it's with how muds limit what
>you can put in your inventory.
Still don't quite follow you on this. The "list" of what you are
carrying consists of what you are wearing (equipment list) and what
you are carrying (hands). What's left?
>As for "two hands, two slots", people can carry things under their arms,
>in their teeth, and even tucked between their chin and chest. Not only
>that, but it's possible to hold more than one item in one hand--if you're
>just carrying them and not wielding them, there's no reason you
>can't keep four knives in one hand. Thus, just saying, "You can
>only carry one item for each hand you have" isn't realistic either. Of
>course, it is *more* realistic than the standard method, and has
>the advantage of being easy to implement. :-)
Oh yeah, I agree you should be able to carry four knives in a hand,
but that's just item stacking. As to the under the arm, in your
teeth stuff - that's pretty limited, and is more for "up in the air"
kind of juggling (ala Omega, if you've ever played it) than for
prolonged storage. What bothers me is that I go and fight perfectly
well with an armload of gear.
>>>On the mud I'm currently working on, we're setting things up so that
>>>objects have both weight and size, and you're limited in how much
>>>of each you can carry. Thus, carrying a huge cardboard box which
[snip]
>>
>>Sounds good - you've eliminated the concept of inventory.
>
>Well, we haven't eliminated the inventory... we've just changed
>the method of determining what can go into a character's inventory.
Hmmm. I guess my problem with inventory is that I imagine the
two-page lists my characters often have on a given mud, ranging from
huge boulders to two-handed swords to suits of armor to potions to
scrolls to keys. Any inventory that is only what you are actually
going to be carrying is going to be incredibly short (four or five
items at most), so is hardly even a list anymore. *shrug*
>>>We do presume that everyone
>>>has normal clothes, which have pockets, but those can't hold
>>>much.
>>
>>Pockets are a fairly modern convenience. Chainmail doesn't usually
>>come with pockets. Besides which, there aren't many things a
>>character will want to carry that can fit into a pocket.
>
>We're building this mudlib for a mud set in 2060. Thus, most
>people will have pockets, and there'll be things like identicards,
>pocket phones, etc. that will fit easily in pockets, and be
>useful.
Ah, that is a little different. Also, given the modern setting, you
will actually have items small enough to want to put them in
pockets. So I can understand that a little better. One thing I
like about the fantasy setting is that you can skip a lot of that. :)
>>>The next logical step would be to make the order in
>>>which things were put into a container important; if a potion
>>>is buried under a dozen other things in your backpack, you're
>>>not going to be able to get to it right away. However, we're
>>>not planning on taking things that far.
>>
>>bother me if you got a little lag for having a cluttered backpack
>>when you try to get something out, but you wouldn't have to manually
>>pull stuff out to get to other things.
>
>I agree... which is another reason why I don't like "one hand,
>one slot" systems. Most of those that I've seen require the
>player to have a hand free in order to pick something up...
>even if it's going straight into a pack. I'd rather not
>make the player do something like (indented items are the
>mud's responses):
[example sniped]
Oh yes, definitely. There's where the problem comes in - it's not
hard to code the "slot" thing on hands (I've never liked the
equipment "slots" on standard diku anyways), it's doing it well.
I simple coded it so that the computer figures out what it needs to
do to free up a hand or whatever you need. Messages like "you don't
have a hand free" and "you can't do that resting" and "you're
already wearing something on your head" have always bugged me.
Makes me want to say, "So free up the hand, stand up, and take
whatever's on my head off!" For my own mud I coded this, and let me
tell you it greatly cuts down on the number of error messages, since
about the only time the player gets a message like this is when they
make a typo. :)
David Stone
> Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
> >Indeed. So why have an inventory? You've already got your hands
> >"slots" - if those are full, you shouldn't be able to carry any
> >more. Period. So where does this whole "inventory" thing come in?
>
> I once saw a mud in which you had no inventory and two hand slots.
> It is my opinion that such a concept is virtually unplayable unless,
> of course, you've aliased and actioned a bunch of stuff with TINTIN.
>
> Being realistic, and encouraging TINTIN, I find very contradictory.
>
> Anyway, take the following as an example:
>
> The mob is dead. R.I.P.
> > l in corpse
> corpse (here):
> some coins
> a potion
> > get all corpse
> Your hands are full.
> > sheath sword
{Lengthy example of unwieldy inventory system -many lines deleted}
> > get coins
> You get some coins.
> > put coins pouch
> You put some coins in a beltpouch.
>
> etc.
>
> Like I said. Unplayable. Unless you use tintin, in which case, it's
> unnoticable. So perhaps some realism should be sacrificed in order
> to gain some playability.
A mud exists already with this kind of inventory system already:
Dartmud, a LPMUD. I dont have the adress handy, though I think it should
be easy to find
(try the mud connector on the web at www.absi.com/mud - this may be
incorrect as well, I dont have that adress handy either!). The system
works well, because it
allows players to select a moneybag and backpack to which they store picked
up objects/cash by default. Also, weapon sheaths are such that you can easily
store and draw weapons, etc. Very very innovative mud (though not as fun as it
should be, I think...). I'd like to see someone implement this elsewhere as
well!
--David Stone
Paul Price
A very rude question follows!!!
Any chance of posting some code so that newbies can learn from
your experiences?
Paul Price
The views expressed in this article do not necessarily represent
the views of my employer. Please address replies to Paul Price
at mw...@gil.com.au
Orion Henry
>>Indeed. So why have an inventory? You've already got your hands
>>"slots" - if those are full, you shouldn't be able to carry any
>>more. Period. So where does this whole "inventory" thing come in?
>
>It is my opinion that such a concept is virtually unplayable unless,
>of course, you've aliased and actioned a bunch of stuff with TINTIN.
Then they implemented it poorly. Obviously this is why it hasn't
caught on; implementing it well takes a little bit of effort,
whereas the whole inventory concept is extremelly easy to code and
deal with.
>Being realistic, and encouraging TINTIN, I find very contradictory.
I agree. Even though I wouldn't give up tintin for the world on
most MUDs I play, it's my oppinion that the less you need tintin for
the better the mud is. A perfect mud, IMO, would make tintin more
or less useless - not because it has "anti-client" type code (which
I've seen plenty of), but because the parser is so well done that
you don't need it. The main thing I use tintin for is to do all the
little boring stuff that I don't have time to do myself (like
recasting spells on myself, eating and drinking, substitution long
sets of commands or difficult to spell names for shorter ones). If
a MUD got rid of this crap then I wouldn't _need_ tintin.
>Anyway, take the following as an example:
Okay...
>The mob is dead. R.I.P.
>> l in corpse
>corpse (here):
>some coins
>a potion
Why are corpses containers? *sigh*
>> get all corpse
>Your hands are full.
At this point the MUD should figure out how to free up your hands
for you...
>> sheath sword
>You put away your sword.
...in this case, by sheathing your sword.
>> get all corpse
>You get some coins from the corpse.
>Your hands are full.
>> put coins pouch
>You don't see a pouch here.
Wait, I can't take stuff in and out of equipment I'm wearing? What
kind of crappy mud is this? :)
>> remove pouch
>Your hands are full.
>> drop coins
>You drop some coins.
>> remove pouch
>You remove your beltpouch.
>> get coins
>Your hands are full.
>> drop shield
>You drop the shield.
>> get coins
>You get some coins.
>> put coins pouch
>You put some coins in a beltpouch.
All of the above is irrelevant if I can put stuff straight into my
beltpouch.
>Like I said. Unplayable.
Wow, with that poor of an implementation, no kidding!
>Unless you use tintin, in which case, it's
>unnoticable. So perhaps some realism should be sacrificed in order
>to gain some playability.
Oh, definitely. Don't get me wrong; I'll sacrifice any realism it
takes in order to gain just one small bit of "fun factor" - that's
what it's about, after all. But realism makes the world more
interesting, consistant, atmospheric, and just plain *real* (hence,
"realism"...), which makes for an overall better mudding
experience.
If I was to mug someone in RL, after pummeling them into
unconsciousness I wouldn't think a real long time about the
procedure of transfering the contents of their wallet to mine.
The parser for a good mud should be like your subconscious or your
instincts, where it does little everyday stuff for you "without
thinking" - that is, you don't have to specify. If I go to open
that door, it's logical that I would sheathe my offhand weapon
first, then open it. I shouldn't have to type that. Similarly, if
I try to move a direction and the door is shut, I should open it.
Why do I have to type all this crap? Isn't it obvious?
Eric Pilcher
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
[some examples of where the mud server should take care of trivial
things for you, such as eating, drinking, opening doors, etc.]
Wow! Those were some great ideas I had not thought about. Rest
assured that I will consider their implementation at Aardvark.
>>> l in corpse
>>corpse (here):
>>some coins
>>a potion
>
>Why are corpses containers? *sigh*
I understand your *sigh* here, but I'm not sure how to better emulate
such a thing. What are your thoughts in this area?
>Oh, definitely. Don't get me wrong; I'll sacrifice any realism it
>takes in order to gain just one small bit of "fun factor" - that's
>what it's about, after all. But realism makes the world more
>interesting, consistant, atmospheric, and just plain *real* (hence,
>"realism"...), which makes for an overall better mudding
>experience.
You might like this. I hacked up my .wld structure and did the following:
1. Ditched <zone #>. This value was going unused anyway. When a room
record is built, the code pulls this out of the .zon file, not the .wld.
2. Modified <sector> such that it's less of an indication of terrain,
and more an indication of the vegitation and resources in that room.
I feel this will add enrichment to Druid and Ranger classes by varying
tracking ability, adding skills such as foraging, etc.
3. Added a <climate> field which ranges from Arctic to Tropical. I'll
add seasons and room temperatures which will give me more varied weather
effects.
4. Added a <terrain> field which ranges from Flat to Sheer. This is
primarily what will effect movement, although it will be modified
some by sector.
So now instead of just having Forest or Mountains. I can have a
Mountainous Forest in a Sub-Arctic region. Perhaps a Rocky Desert
in the Tropics. And, in fact, I can't think of a point on the globe
that I can't simulate with these three flags.
Thoughts, ideas and suggestions are welcome.
Tim Hollebeek
: >"slots" - if those are full, you shouldn't be able to carry any
: >more. Period. So where does this whole "inventory" thing come in?
: I once saw a mud in which you had no inventory and two hand slots.
: It is my opinion that such a concept is virtually unplayable unless,
Agreed.
: Being realistic, and encouraging TINTIN, I find very contradictory.
: Anyway, take the following as an example:
: The mob is dead. R.I.P.
I hate the term 'mob'
: > l in corpse
Gee, I doubt this stuff is _in_ the corpse. That's rather gross.
: corpse (here):
: some coins
: a potion
: > get all corpse
sheesh, get all FROM corpse :-) Ok, enough Diku gripes for now.
: Your hands are full.
: > sheath sword
: You put away your sword.
: > get all corpse
: You get some coins from the corpse.
: Your hands are full.
: > put coins pouch
: You don't see a pouch here.
: > remove pouch
: Your hands are full.
: > drop coins
: You drop some coins.
: > remove pouch
: You remove your beltpouch.
: > get coins
: Your hands are full.
: > drop shield
: You drop the shield.
: > get coins
: You get some coins.
: > put coins pouch
: You put some coins in a beltpouch.
If MUDs want to be that realistic, it should go like this:
X dies.
> l at corpse
On the corpse, you see:
some coins
a potion
> get all corpse
some coins:
(sheathing your sword first)
You take the coins from the corpse, and deposit them in your money pouch.
a potion:
(strapping your shield across your back first)
You take the potion.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
C'ing is Believing
>>corpse (here):
>>some coins
>>a potion
>
As opposed to what? I find it easiest from a coding perspective to
treat a corpse as a container, albeit a special one, one whose
contents are visible. Sorta like a belt; a belt can hold pouches,
but it doesn't hide them.
>>Unless you use tintin, in which case, it's
>>unnoticable. So perhaps some realism should be sacrificed in order
>>to gain some playability.
>
>Oh, definitely. Don't get me wrong; I'll sacrifice any realism it
>takes in order to gain just one small bit of "fun factor" - that's
>what it's about, after all. But realism makes the world more
>interesting, consistant, atmospheric, and just plain *real* (hence,
>"realism"...), which makes for an overall better mudding
>experience.
It sounds like you're saying realism itself is a fun factor. With
that I can agree. Most people would agree, too; the argument is
where to draw the line. :-) For instance, I don't think anybody
wants to walk from Calais to Rome in real time, but many muds have
locations this far apart, and farther. They often just say "okay,
pretend you're wearing seven-league boots while you're in the
wilderness" to preserve sanity.
In this case, it's inventory management we're discussing, not
marathon-walking, but even so, should this always be automatic?
I don't think so; I'll explain later.
>If I was to mug someone in RL, after pummeling them into
>unconsciousness I wouldn't think a real long time about the
>procedure of transfering the contents of their wallet to mine.
>The parser for a good mud should be like your subconscious or your
>instincts, where it does little everyday stuff for you "without
>thinking" - that is, you don't have to specify. If I go to open
>that door, it's logical that I would sheathe my offhand weapon
>first, then open it. I shouldn't have to type that. Similarly, if
>I try to move a direction and the door is shut, I should open it.
>Why do I have to type all this crap? Isn't it obvious?
Not to a dullard. This brings me to the main point of my post.
Many muds feature the SAOD (Six Attributes of D&D): three physical,
and three mental. Big deal, right? Warriors always max out the
first, while spell casters max out the second. But why not let
intelligence also dictate the things you describe?
Consider this example:
The skeleton falls dead to the ground.
> search corpse
The corpse is garbed in an iron breastplate, an iron skull cap, and
a leather belt. On the belt is a brown pouch. The corpse holds a
rusty sword in its left hand and a buckler in its right hand.
> loot corpse except sword
You sheathe your sword. You can't put your torch down without
putting it out, so you stick it in a nook in the wall. You take
the breastplate, cap, pouch, belt, and buckler from the corpse
and put all but the belt and buckler in the ankle-deep water.
> wear all
You wear the buckler. You take the cap and pouch and wear them.
You sense the breastplate may be cursed. You're already wearing
a belt.
> wear belt anyway
Okay...
You wear the belt above the one you have. You're now quite the
fashion statement.
> search pouch
Your pouch contains two copper coins.
> look
This a tunnel, apparently part of a sewer system. Water covers the
entire floor. Exits are north and south.
There is a skeleton corpse, an iron breastplate, and a chest here.
> loot chest
As you open the chest, you hear a "snick" as a hidden needle snaps
out and pricks your right hand.
> loot chest anyway
Okay...
You take three opals and a ruby from the chest.
> take all
You put three opals and the ruby into your pouch. You take off
your pack and put it in the ankle-deep water. You take the
breastplate and put it in your pouch. You put your pack back on.
You take your torch. The corpse and chest are too heavy to carry
easily.
> get ready
You draw your sword. Let's go!
From a programming standpoint, I feel the above is all codable by
someone of competent skill. Note that there's quite a bit more than
mere inventory/limb management at work here; there's also terrain
interaction, object recognition, an improved parser, and a safety/
override system. The hardest thing, I feel, is giving a rooms a
way to decide where to put a volatile object, like the lit torch.
I would consider the above to be the sort of thing to happen to an
above-average adventurer. A genius might automatically search the
chest for traps before opening it. An average character might not
know to put the torch (the "loot corpse" command would stop here
until the character figures out where to put it, or he could try
looting it with one hand.) A character with below-average wits
may find it unwise to "wear all", while a moronic character would
have to be told every single thing specifically. I can count a
total of 34 commands required to do what was done in 10. The parser
saved a few of these, and the safety/override took care of tons of
background stuff, but most of the actual commands were done by the
character's intelligence. I guarantee you'll see more fighters with
high intelligence walking around on a mud like this. :-)
In summary, it might not be best to give every character an expert
system to run things for them. Instead, letting it run in stride
with the intelligence attribute could add an interesting dimension
to a mud, and provide more incentive for characters to pay attention
to all attributes, rather than max out one.
Paul Brinkley
ga...@clark.net
(Sometimes I wish I had the time to write my own mud... :-) )
C'ing is Believing
Tim Hollebeek <t...@wfn-shop.princeton.edu> wrote::: Anyway, take the following as an example:
:
:: The mob is dead. R.I.P.
:
:I hate the term 'mob'
Would you prefer "beastly Fido"? ;-)
:: > l in corpse
:
:Gee, I doubt this stuff is _in_ the corpse. That's rather gross.
Assuming you still want corpses treated as containers, you could
allow there to be at least two different kinds of containers:
contents inaccessible, and contents accessible. For the former,
you can't interact with contents until you take them out. Examples
of the latter could include corpses, weapon racks, belts, Velcro
walls, and so forth.
:: corpse (here):
:: some coins
:: a potion
:: > get all corpse
:
:sheesh, get all FROM corpse :-) Ok, enough Diku gripes for now.
Heck, "loot corpse" if we must be so keystroke-economical... :-)
:: Your hands are full.
Sounds a lot like what Infocom games used to do. Maybe it was
because I was so young when I first saw those games, but I feel
like Infocom had the perfect parser and game engine, and nothing
since has topped it. You could perform actions on multiple
objects, have things like "sword sheathing" done automatically,
etc. Plus, I don't remember finding a single bug, ever; the
programmers had thought of everything.
Paul Brinkley
ga...@clark.net
atlas
WARNING: the following message is geared toward implementation
possibilities.
In article <4r6dtv$t...@kira.peak.org>, ra...@kira.peak.org says...
>>>> l in corpse
>>>corpse (here):
>>>some coins
>>>a potion
>>
>>Why are corpses containers? *sigh*
>
>I understand your *sigh* here, but I'm not sure how to better emulate
>such a thing. What are your thoughts in this area?
Perhaps one way to do it is to make it so that when something/someone dies,
instead of loading a generic corpse object in the room, load a generic
mobile in the room which will act as the corpse. Then more or less
add descriptions based on the character which died, modifiying them so
that there is do doubt that the person on the ground is dead. Like:
Keywords: corpse giant dead
Short: the corpse of a giant (or the corpse)
Long: The mutilated corpse of a giant is here.
Description: (same as long) (see below for idea on descriptions)
Then you just transfer all the equipment to the dead guy, and so when you
look at him you see:
--
<description>
The corpse of a giant is wearing:
<around neck> gold chain
<worn on body> hide vest
<worn waist waist> huge leather belt
<worn on legs> kilt
--
Also you wouldn't see his huge club, because he would have dropped it on the
ground when he died. (along with the stuff in his inventory.)
Okay, to make this dead corpse inanimate (seeing he is a mobile) just
create a flag called ACT_IS_CORPSE and edit the code so that such mobiles
just sit there, can't be attacked, won't attack, and will eventually decay.
Its a big job. There are other ways to do it. Probably some better ones,
but this is one of the more easy ones to grasp, as most of the code
is already there. In this one the hard part is editing every place in
the code that a mobile might do something that a corpse wouldn't.
This is about as far as you need to go (assuming you made it here) if you
don't care for the idea. Down below is info on making it a little more
detailed.
(BTW, in case anyone is wondering, i have no code to do this. I just made
it up.)
-Atlas
/* begin info for making detailed corpse descriptions */
A description os a bit harder,( for look at corpse ), as it is supposed to
be used to really get a feel for what this looks like. Unfortunatly, with
most diku muds and such, the mud keeps no attributes about the character.
really looks like, the best you can hope for is race and sex. If you had
different fields for hair color and eyecolor and stuff, you could make a
table of records, each containing a generic description string.
Each record for a description also would contain an array of numbers
to show the order that the eye color, race, hair color, height modifier
(big, large, very large), sex, ect. should be substituted in.
Example:
struct corpse_descs {
char *description;
int substitute_order[xx];
};
{
"You see before you the body of a %s. There is a wide gash
along its belly, and a pile of entrails off to the side. %s
cold %s eyes appear to follow your every movement.",
{ SUB_RACE, SUB_HIM_HER_IT, SUB_EYECOLOR, 0, 0, 0, 0 }
}
I'm not very good with descriptions,so it can be made alot better, assuming
someone with enough skill is interested in such details.
If you don't know C then you may not understand this. :)
/* end description info */
/* checking to make sure that we don't allow people to attack corpses */
bool check_corpse( CHAR_DATA *ch, CHAR_DATA *victim )
{
if ( IS_SET(victim->act,ACT_IS_CORPSE) )
{
send_to_char( "No need to do that, they are already dead.\n\r", ch );
return TRUE;
}
return FALSE;
}
then just go around to places in the code were a victim has been determined
and you don't want whatever is being done to be done, and put something
like:
if ( check_corpse( ch, victim ) ) return;
One of many places would be in the kill, backstab, murder, ect commands.
/* end info */
Travis S Casey
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>>Certainly, and here is the advantage for using races like dwarf,
>>>elf, drow, and ogre - this stuff is already kind of "built in."
>>>Using completely original races takes some real time to do right.
>>
>>That's true... however, there's a lot of leeway in even the
>>traditional races. Check out, for example, Tolkein's elves
>>vs. ElfQuest's elves.
>
>Indeed. What I meant was, I can choose to make an elven mage and be
>pretty confident that's a better combination that a half-giant mage.
Pretty confident, yes, but not absolutely certain. :-) If someone
decided to base a mud off of Norse mythology, then a lot of giants
would be extremely powerful magicians...
But I think we're in agreement here; there is more "built in"
for the traditional races, but there's also a great deal of
leeway in them.
>>The inventory is everything you're carrying, regardless of how
>>you're carrying it. It exists for a simple reason; because the
>>game needs a list of the things you're carrying. The problem
>>isn't with the inventory itself; it's with how muds limit what
>>you can put in your inventory.
>
>Still don't quite follow you on this. The "list" of what you are
>carrying consists of what you are wearing (equipment list) and what
>you are carrying (hands). What's left?
Nothing. My only point is that the mud has to keep track of this
list somewhere, so that it can make that stuff move around with
you.
>Oh yeah, I agree you should be able to carry four knives in a hand,
>but that's just item stacking. As to the under the arm, in your
>teeth stuff - that's pretty limited, and is more for "up in the air"
>kind of juggling (ala Omega, if you've ever played it) than for
>prolonged storage. What bothers me is that I go and fight perfectly
>well with an armload of gear.
That bothers me as well... however, people should be careful about
making encumbrance make it harder to fight without thinking it
through. For example, a friend of mine met someone on a mud who
had an interesting tactic: since weight made it harder for things
to fight well, when he was fighting a monster, he'd give it everything
he had except his armor and weapons. This reduced his load, making
him fight better, and increased the monster's load, making it fight
worse. To top off the idiocy, the mud used the "containers make
things lighter" approach, so when he'd killed the monster, he'd
pick up its corpse and use it to carry his equipment. *Sigh*.
Of course, it's sheer idiocy for monsters to take anything that
anyone gives them... especially if they happen to be fighting that
person! This is the kind of thing that can happen, though, when
some aspects of the mud are made more realistic without considering
the impact this can have on other aspects.
>>Well, we haven't eliminated the inventory... we've just changed
>>the method of determining what can go into a character's inventory.
>
>Hmmm. I guess my problem with inventory is that I imagine the
>two-page lists my characters often have on a given mud, ranging from
>huge boulders to two-handed swords to suits of armor to potions to
>scrolls to keys. Any inventory that is only what you are actually
>going to be carrying is going to be incredibly short (four or five
>items at most), so is hardly even a list anymore. *shrug*
Even a short list is still a list. :-) Heck, you can have a list
of zero items. Also, on a really realistic mud, with characters
travelling in the wilderness, the list won't be so short... indeed,
on a fully realistic mud, a character travelling in wilderness
would find it worth his/her while to buy a pack animal.
R. Michael M.
Fun over balance, balance over realism.
michael
--
Thus has the Lord of hosts spoke: Execute true
judgment and show mercy and kindness and
tender compassion, every man to his brother; And
opprses not the widow or the fatherless, the
temporary resident or the poor, and let none of
you devise or imagine or think evil against his
brother in your heart.
Zechariah 7:9,10
Travis S Casey
That's a nice principle, but you've overlooked something:
What's fun for you may not be fun for me, and vice-versa.
For instance... there are plenty of people out there who prefer
Diku's to stock 2.4.5 LP's, because they *like* having to find
food, rest, etc. However, there are also people who don't like
Diku's, because they *don't* like having to do all that.
So, what kind of setup should your mud have? Should food
be needed, or not? My personal answer to this is a simple
one:
- Build games that YOU want to play.
Chances are that if you like the game, so will someone else.
Not only that, but building the games that *you* want is
easier (and more fun!) than trying to read the minds of other
people to see what *they* want. If you try to build your
games around what other people want, what you're most likely
to wind up with is a game that's effectively designed by
committee--and we all know how well committees usually do
when it comes to designing things.
Personally, I want a *very* realistic mud. You may not;
however, if you don't like it, I'm not going to force you
to play it--just like you can design whatever mud you want,
and I don't have to play it if I don't like it.
Eric Pilcher
Well, no. Don't confuse the issue. Balance is something completely
different and hadn't really been talked about at great depth, (in this
thread at least.)
The ideal situation is a balance of realism and fun. :)
But if you're talking about balance between races or balance between
classes... well, I tend to take the Jervis Johnson (author of Blood
Bowl) approach. That is, not all races and not all classes are
meant to be equal. Some are supposed to be a cakewalk to play, while
others are downright imposible.
This is why it is often recommended that newbies play Orgrish Warriors.
Eric Pilcher
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>So, what kind of setup should your mud have? Should food
>be needed, or not? My personal answer to this is a simple
>one:
>
> - Build games that YOU want to play.
AMEN! Of course, you COULD try to appeal to everyone and have countless
toggles the player could set. Hmm, I want to be hungry, I'll just
set my NEEDSFOOD toggle. Yeah, that sounds silly, but I'm at least
concidering an AUTOEAT toggle which if set, would look for food in
your inventory and bags automatically should you get hungry.
>Chances are that if you like the game, so will someone else.
>Not only that, but building the games that *you* want is
>easier (and more fun!) than trying to read the minds of other
>people to see what *they* want. If you try to build your
>games around what other people want, what you're most likely
>to wind up with is a game that's effectively designed by
>committee--and we all know how well committees usually do
>when it comes to designing things.
The ex-Kallisti god I had the biggest falling out with subscribes
to the notion that everything should be argued to death by several
players, both mortal and immortal in forum to decide what should
be imped. I wish him and his co-creaters luck in their current
project. I just don't feel that it'll be anything I'll be interested
in. By the way, I'll even plug them. It's called RUS Mud (Realms
Under Seige) and will be comming up on monet.com later this year.
Code base is apparently DIKU++.
My own mud is currently untitled (had one picked but found out later
that particular name was in use). Will be up later this year on
digiforest.com. I'm using circle 3.0, mainly becuase I'm a recreational
coder and am basically learning C for the fun of it.
>Personally, I want a *very* realistic mud.
It's my goal to be realistic and yet still be playable (fun). I've
heard of muds out there that basically crippled players for the
sake of realism. To me that just doesn't sound very ideal.
Ari Kangas
> (lots of talk about corpses being containers, sheathing weapons before
> opening doors etc.)
This message isn't directed to *YOU* and I'm not trying to insult anyone.
If you still feel insulted, that's too bad. It wasn't my intention.
Everybody knows you can't open a door if you're holding a shield and
wielding a weapon in your other hand. What _I_ don't understand is the
need to display all that useless information to players. Do you really
have to SEE your character sheath the weapon, open the door and wield
the weapon again? Ever heard of imagination?
Same goes with container corpses. You KNOW you have killed a mob. You
know there should be a corpse, and you know the corpse should be wearing
the equipment the mob had. So, you are saying you aren't able to imagine
that when you *examine corpse* your character searches through the
monster's equipment, pouches and other containers, and just shows you a
short list of what he found, and of which you can easily select the items
you wanted?
What I DO agree about is that people shouldn't be able to carry lots of
equipment. They can have a backpack or something along with them, that
would explain the inventory quite easily, but how can a character carry
3 full sets of equipment, some potions & scrolls and still be able to
walk, not to mention fighting?
ArZka
ga...@clark.net
atlas <at...@intcomm.net> wrote:
>
>
>In article <4r6dtv$t...@kira.peak.org>, ra...@kira.peak.org says...
>>>
>>
>>I understand your *sigh* here, but I'm not sure how to better emulate
>>such a thing. What are your thoughts in this area?
>
>Perhaps one way to do it is to make it so that when something/someone dies,
>instead of loading a generic corpse object in the room, load a generic
>mobile in the room which will act as the corpse. Then more or less
>add descriptions based on the character which died, modifiying them so
>
> [snipped]
>
>Okay, to make this dead corpse inanimate (seeing he is a mobile) just
>create a flag called ACT_IS_CORPSE and edit the code so that such mobiles
>just sit there, can't be attacked, won't attack, and will eventually decay.
>Its a big job. There are other ways to do it. Probably some better ones,
>but this is one of the more easy ones to grasp, as most of the code
>is already there. In this one the hard part is editing every place in
>the code that a mobile might do something that a corpse wouldn't.
I'm afraid I kinda gave up on the idea at this point. While it
takes steps to simulate realism, I simply don't see what I would
get, from a programming perspective, by treating a corpse as a
special type of mobile rather than a special type of container.
Indeed, it seems to even detract, mainly because of all the code
on mobiles that would have to be reviewed.
Mind you, I'm not an experience mud programmer by any means; just
experienced in C programming in general. But off the top of my
head, a mobile seems to be a much more complicated object than
a container, which would mean that as a mobile, a corpse would
effectively be a large, memory-hogging, detailed version of a
mobile, only with seven-eighths of the features disconnected.
If it's so necessary to avoid such ridiculousness as "looking
in corpses", why not make a special kind of container? This is
an idea I mentioned elsewhere in this thread. Instead of making
a simpler object from a more complex one, you'd go the other way,
which to me makes more sense when trying to save memory, both on
the machine and in your head. :-)
Usually, containers (such as chests, sacks, and vials) conceal
their contents; to interact with the contents, you have to first
take them out. But why not have "containers" whose contents are
both visible and accessible, because they are being "worn" or
merely supported by the container? This could include things
like weapons racks, coat hangers, book shelves, belts (you can
belt pouches on them), or even corpses.
Coding-wise, I visualize it this way. Such a container (generically,
we could call them "racks") inherits the standard container,
retaining the ability to hold objects, have a capacity, etc.
Several functions are re-written, such as look(); you would
see the contents as well as the rack itself. The hairy part
would probably be how to handle the rack's contents, since
functionally they should be accessible as if they were in the
same environment as that of the rack. That is, if you see a
corpse wearing a helmet, you should be able to "look at helmet"
without having to first take it from the corpse.
Does anyone with more mud-coding experience see any merit to
this idea?
Paul Brinkley
ga...@clark.net
Travis S Casey
In article <4ra270$8...@clarknet.clark.net>, <ga...@clark.net> wrote:
[idea of using non-mobile mobiles for corpses]
>I'm afraid I kinda gave up on the idea at this point. While it
>takes steps to simulate realism, I simply don't see what I would
>get, from a programming perspective, by treating a corpse as a
>special type of mobile rather than a special type of container.
>Indeed, it seems to even detract, mainly because of all the code
>on mobiles that would have to be reviewed.
I have to agree; using a mobile seems to be a waste to me, since
mobiles have large amounts of code and data which will be useless
in this situation.
Actually, people don't just see merit to it... some have
already done it. Lima provides for containers with accessible
contents in the way you describe, and also allows for other
prepositions, and even objects with multiple prepositions...
thus, you can make a table that people can put things on (and
having those things be accessible), and under as well (and have
those things not be accessible).
Lima's code for all this is publically available by downloading
it... it's in LPC, since it's for an LPmud, but it shouldn't
be too hard to adapt to other things.
Timothy Kutz
In article <4r9u4q$9...@kira.peak.org>,
Eric Pilcher <ra...@kira.peak.org> wrote:
>The ex-Kallisti god I had the biggest falling out with subscribes
>to the notion that everything should be argued to death by several
>players, both mortal and immortal in forum to decide what should
>be imped. I wish him and his co-creaters luck in their current
>project. I just don't feel that it'll be anything I'll be interested
>in. By the way, I'll even plug them. It's called RUS Mud (Realms
>Under Seige) and will be comming up on monet.com later this year.
>Code base is apparently DIKU++.
Just for the record, the address is mo.net, not monet.com. But
thanks for the plug, and the luck. :)
Tim
--
****************************************************************************
* Tim Kutz * Chivalry isn't dead. It's just getting old, and *
* co...@ritz.mordor.com * has to take long naps. I make sure to wake it *
* Raistlinn@RUSMUD * every so often. *
****************************************************************************
Raelyn S. Sweebe
> In article <4ra270$8...@clarknet.clark.net>, <ga...@clark.net> wrote:
>
> [idea of using non-mobile mobiles for corpses]
>
> >I'm afraid I kinda gave up on the idea at this point. While it
> >takes steps to simulate realism, I simply don't see what I would
> >get, from a programming perspective, by treating a corpse as a
> >special type of mobile rather than a special type of container.
> >Indeed, it seems to even detract, mainly because of all the code
> >on mobiles that would have to be reviewed.
>
> I have to agree; using a mobile seems to be a waste to me, since
> mobiles have large amounts of code and data which will be useless
> in this situation.
Yes and no sure you should be able to see it's a helmet and maybe notice
the spike on top but until you take it from the corpse could you see the
inscription inside or look inside the bag the corpse has until you take it
As far as objects go usually I know what is in my backp[ack if I l in back
I see the contents and I can take them out of backpack but if a potion is
in my backpack I need to take it out before i can drink it or else have a
really long straw.
The question comes down to realism and playability. You hold a light
weapon shield holdable and your inventory ina ll rights if a mob charged
you you would drop everything trying to get in a fighting stance. It
makes little sense to make someone put their holdable inventory on the
ground dfrop their light and then fight how could you see the monster.
Destiny
eclipse of fate
eclipse.argy.com 7777
Travis S Casey
Raelyn S. Sweebe <961...@serv2.catnet.net> wrote:
[text that the poster quoted which has nothing to do with what he's
saying deleted]
>Yes and no sure you should be able to see it's a helmet and maybe notice
>the spike on top but until you take it from the corpse could you see the
>inscription inside or look inside the bag the corpse has until you take it
No one was saying that you should be able to do either of those
things--only that you should be able to see what the corpse has
without doing a "look in corpse" or something similar.
>As far as objects go usually I know what is in my backp[ack if I l in back
>I see the contents and I can take them out of backpack but if a potion is
>in my backpack I need to take it out before i can drink it or else have a
>really long straw.
And no one was saying that you shouldn't have to do that either. The
idea being discussed is to make it *possible* to make containers whose
inventories can be accessed without having to explicitly get them
from the container first. Not all containers would (or should) work
this way.
>The question comes down to realism and playability. You hold a light
>weapon shield holdable and your inventory ina ll rights if a mob charged
>you you would drop everything trying to get in a fighting stance. It
>makes little sense to make someone put their holdable inventory on the
>ground dfrop their light and then fight how could you see the monster.
Again, no one was suggesting this. All that was being suggested
is that how much characters can carry around should be limited
by the size and number of things they are carrying as well as
by weight.
On your point about the light, however, I must ask... how *can't*
you see the monster? Your light doesn't mysteriously stop lighting
the room just because you put it down...
As for realism vs. playability: remember, there is no perfect
balance of these. Some people enjoy playing games where they have
to remember such details as "put down your torch before you get
in a fight, or you may set yourself on fire"; some don't. If you
don't like it, no one's going to force you to play it... you're
free to play any of the many muds that don't bother with such
details.
ga...@clark.net
Ari Kangas <ar...@news.lut.fi> wrote:
>
>Everybody knows you can't open a door if you're holding a shield and
>wielding a weapon in your other hand. What _I_ don't understand is the
>need to display all that useless information to players. Do you really
>have to SEE your character sheath the weapon, open the door and wield
>the weapon again? Ever heard of imagination?
Imagination can (and should) only go so far. Indeed, if we all were
content with filling the gaps of a mud with our imaginations, we could
all just sit at home, fantasize about adventuring, and save money on
the internet provider bills. :-)
It comes back to the same thing: where to draw the line when
simulating reality. In the case you describe, there are issues to
consider: what do we tell the player if there isn't an easy way to
open that door? What do we tell the player if there's an easy way
to open it, but it involves a lot of equipment shuffling (sheathe
sword, switch torch hands to access keys in the left belt pouch,
rifle through them, unlock the door, etc...)? And how much of this
should the mud do automatically; at what point should the player be
required to rearrange his equipment? And what if doing something
results in side effects, such as the stacking order of gear in his
pack having changed? Should we tell him, and if so, how?
>Same goes with container corpses. You KNOW you have killed a mob. You
>know there should be a corpse, and you know the corpse should be wearing
>the equipment the mob had. So, you are saying you aren't able to imagine
>that when you *examine corpse* your character searches through the
>monster's equipment, pouches and other containers, and just shows you a
>short list of what he found, and of which you can easily select the items
>you wanted?
As long as it's all routine, it's fairly easy to say "imagine".
But what if all this automatic stuff makes a difference in
game play? For instance, what if the player is in combat, but
would at least like to make a visual search of the corpse,
rather than a full search through its pockets for loose change?
At that time, it may behoove the programmer to code detailed
behavior for containers, corpses, etc., to heighten the sense
of reality.
>What I DO agree about is that people shouldn't be able to carry lots of
>equipment. They can have a backpack or something along with them, that
>would explain the inventory quite easily, but how can a character carry
>3 full sets of equipment, some potions & scrolls and still be able to
>walk, not to mention fighting?
No argument there.
Paul Brinkley
ga...@clark.net
>ArZka
Travis S Casey
In article <4r8qq3$l...@lut.fi>, Ari Kangas <ar...@news.lut.fi> wrote:
>> (lots of talk about corpses being containers, sheathing weapons before
>> opening doors etc.)
>
>This message isn't directed to *YOU* and I'm not trying to insult anyone.
>If you still feel insulted, that's too bad. It wasn't my intention.
>
>wielding a weapon in your other hand. What _I_ don't understand is the
>need to display all that useless information to players. Do you really
>have to SEE your character sheath the weapon, open the door and wield
>the weapon again? Ever heard of imagination?
I agree with you completely. I believe that the mud should figure
out how the character should do something (possibly within limits
bounded by the character's intelligence, as someone else pointed
out), and just let you do it without telling you in detail how
you do it.
That is, if both of a character's hands are full and he/she tries to pick
something up, I want to show the player something like:
: get thingamabob
You pick up the thingamabob.
And not something like:
: get thingamabob
You sheathe your sword, pick up the thingamabob, put it in your left
hand with the bag you're holding there, and then draw your sword
again.
The second version seems to me to be providing too much detail;
they don't really tell the player anything useful, but still consume
CPU time to put together and bandwidth to send out... especially if
you send out a similar message to everything in the room.
Raelyn S. Sweebe
One thing that has always irritated me is the inability to get water
anywhere on a mud. I mean I continually traverse rivers lakes streams etc
yet I type fill barrel river and it won't let me. realism is such a weird
word we argue about inventory and such yet we do nto think twice when the
only place for water is midgaard or maybe 2 other zones and rarely do i
find food in other zones. What does the elven village do for food.
Des
Eric Pilcher
<ga...@clark.net> wrote:
>I'm afraid I kinda gave up on the idea at this point. While it
>takes steps to simulate realism, I simply don't see what I would
>get, from a programming perspective, by treating a corpse as a
>special type of mobile rather than a special type of container.
>Indeed, it seems to even detract, mainly because of all the code
>on mobiles that would have to be reviewed.
>
>experienced in C programming in general. But off the top of my
>head, a mobile seems to be a much more complicated object than
>a container, which would mean that as a mobile, a corpse would
>effectively be a large, memory-hogging, detailed version of a
>mobile, only with seven-eighths of the features disconnected.
What I'm about to say applies mainly to the Diku muds out there. I'm
not sure how the mobiles are set up in LP, Teeny or other formats.
In a Diku, when a mob dies, the following things happen:
1. A temporary object gets created... the mobs corpse.
2. A "rot" timer gets set on the object.
3. All the stuff the mob has is transfered to the corpse item.
4. The mob gets extracted.
5. Later, when the "rot" timer reaches 0, the corpse is extracted.
This sequence is all triggered when the mob reaches POSITION_DEAD.
Wouldn't it make more sense to just stick a rot timer on the mob when
the mob reaches POSITION_DEAD? It's not like you have to modify things
like movement, aggressions, etc. All those routines already check to
see if the mob is POSITION_STANDING first.
If you're concerend about mobs taking up more memory than objects, you
could set their bitvectors to 0 upon death, remove any spec procs they
have, etc. Something tells me that that's got to be more memory
conservative than creating a non-protyped object, transfering everything
to it, and purging out the mob.
Then again. I'm a Civil Engineer, not a Computer Scientist.
If you go with this system, about the only other thing you'd need to
modify would be "get/take", allowing you to take things from mobs
which are DEAD. Or, of course, you could add a loot command.
>If it's so necessary to avoid such ridiculousness as "looking
>in corpses", why not make a special kind of container? This is
>an idea I mentioned elsewhere in this thread. Instead of making
>a simpler object from a more complex one, you'd go the other way,
>which to me makes more sense when trying to save memory, both on
>the machine and in your head. :-)
Wait, let me get this straight. Instead of making a simpler object
from a more complex one.... you could go the other way and make
a complex object from a simpler one. How would this save you
memory? It seems to me that the more complex an object (and by object,
I mean anything: item, mob, room), the more memory it would use.
Kinda funny. Before I started this post, I had planned on leaving the
mob container thing alone. Now I've pretty much talked myself into
hacking that up.
SOCIETY OF PHYSICS
Oh, I agree with your point entirely. I do feel, however, that when
"realistic" features are implemented in a good manner, it adds a lot
to the game.
-Eric
> Hmm, realism vs playability. It is quite simple. Realism should NEVER
> detract from fun or playability. If the player wants the problems and
> worries of real life, he would just log out, you have better graphics
> and sound in real life that you get with a mud.
> X-Newsreader: TIN [version 1.2 PL2]
>
> Realism perhaps shouldn't even be considered. What is real to a mud,
> just whatever the creator defines as real. There is one mud that tried
> to make his mud so realistic that he would never have a successfull mud
> if he payed people to play it. It was called Auterien Dynasty, aka
> Newworld. Created by Owen Emlen (orin).
>
> Basically the mud consisted of extremely long journeys, long periods of
> time where the player is expected to sit at his/her terminal and do
> NOTHING, just wait.
>
> First of all, the mud was extremely problematic for weight and movement
> points. For someone to have a full set of LIGHT gear on, they would be
> able to move like 10 rooms and then they would have to sleep. But WAIT,
> if it was cold out, you couldn't sleep without lots of wool gear on, and
> in the summer you couldn't sleep if you had lots of wool gear on. As
> for
> gear, all the gear in the game consists of wool, leather, thin metal,
> and
> thick metal, thats it, so the most interesting piece of gear in the
> game is, well ok, there isn't one. Everyone has the same gear.
>
> During battle, all interesting commands are unusable, like you cannot
> see your score, or inventory or anything else. So you can just watch
> what is happening in battle, gee, how interesting. And players cannot
> ever tell what they are actually at anyhow, mana is powerful, hmm, hp
> is at bad, hmm, well who knows what the hell that means.
>
> You had to collect travel points in addition to experience points to
> level, fear that, as travel points were randomly distributed to rooms
> throughout the mud, and you need thousands of them to get large levels.
>
> It is commonplace to have -MaxInt exp to level, and every exp point you
> earn is wasted until you get your travel points needed to level. Nice
> huh. If the god seen anyone having fun with something, he quickly took
> it out. That also sounds like real life.
>
> It seems that the god's goal on the mud was to see how many pissed off
> players would ACTUALLY stay.....laugh. Challenging? No just stupid.
> Sorry, we give the mud the thumbs down. He thought only about realism,
> not playability.
>
> BASICALLY MY ANSWER TO THE ARGUMENT -> REALISM SHOULD ONLY BE USED WHEN
> IT ENHANCES PLAY(ABILITY). GET
> RID OF THE REST.
>
> Remember muds are for the players, used by the players, and judged by
> the players. Thus they should be coded by the players, and you'll
> notice
> that all good muds are.
>
>
>
>
Paul McInnes
> >"slots" - if those are full, you shouldn't be able to carry any
> >more. Period. So where does this whole "inventory" thing come in?
>
> I once saw a mud in which you had no inventory and two hand slots.
> It is my opinion that such a concept is virtually unplayable unless,
long middle bit ommited
> Like I said. Unplayable. Unless you use tintin, in which case, it's
> unnoticable. So perhaps some realism should be sacrificed in order
> to gain some playability.
To be quite honest, the interesting issues have little to do with how
equipment is stored, and more to do with the type of universe that is
simulated by the MUD. Realism is about providing the code and system
design (e.g. combat system) to support a world in which common-sense can
provide a guide to action. This means doing away with classes, dozens of
exotic races, super-power characters and providing something more
interesting and meaningful than killing for xp. What kind of world is it
where some inhabitants relentlessly slaughter to grow strong, and where
being strong is the sole purpose of existing? Sounds like sociopathic
vampires gone mad. The funny thing is that the other (hopefully more
sane) inhabitants don't even notice.
I've got nothing against the D&D hack'n'slay stuff, in fact I love it,
but the potential for realism in MUDs goes far beyond trivial details
about handling equipment and looting.
Paul
Orion Henry
>>Why are corpses containers? *sigh*
>
>As opposed to what?
Er...as opposed to being corpses.
>I find it easiest from a coding perspective to
>treat a corpse as a container, albeit a special one, one whose
>contents are visible. Sorta like a belt; a belt can hold pouches,
>but it doesn't hide them.
It was a good hack years ago, but I think we can come up with
something better in this day and age.
>>Oh, definitely. Don't get me wrong; I'll sacrifice any realism it
>>takes in order to gain just one small bit of "fun factor" - that's
>>what it's about, after all. But realism makes the world more
>>interesting, consistant, atmospheric, and just plain *real* (hence,
>>"realism"...), which makes for an overall better mudding
>>experience.
>
>It sounds like you're saying realism itself is a fun factor. With
>that I can agree. Most people would agree, too; the argument is
>where to draw the line. :-) For instance, I don't think anybody
>wants to walk from Calais to Rome in real time, but many muds have
>locations this far apart, and farther. They often just say "okay,
>pretend you're wearing seven-league boots while you're in the
>wilderness" to preserve sanity.
No, I don't think of realism as a fun factor. It's something else.
"Fun" is a little more difficult to pin down, but I think it mostly
comes (at least in MUDs) from accomplishing things and possibly
exploring/experiencing new stuff. Realism only sets a mood, defines
the game; important, certainly, but this is different from fun.
I consider AnotherMUD to be the _funnest_ MUD I've ever played,
simply because I found that I truely enjoyed 99% of the time I spent
there. On the other hand, it is COMPLETELY unrealistic, has
absoltely no atmosphere, generally abysmally written zones (including
all the stock ones), etc. Compare this to a MUD like Arctic, which
I consider far superior in every way, but perhaps less "fun" in the
long run. On a MUD like Arctic there are a lot of ups and downs; I
experience more excitement and passion there, but also frustation
and bitterness at times.
This is kind of hard to explain, I guess, but realism != fun.
Realism sets a tone, and defines a world; fun is what you do with
that world.
>In this case, it's inventory management we're discussing, not
>marathon-walking, but even so, should this always be automatic?
>I don't think so; I'll explain later.
Well, the distance thing you mention is interesting. Continuing
what I was saying about Arctic: there, walking between towns is a
bit of a chore. If you buy something on auction and they are in
Solace, while I'm in the Flying Citadel, I say "Okay, I'll be down
there in about 30 mins RL." Mages and druids get around better, of
course, but there is a real sense of space to the world, just
because travelling is so time consuming. You've got to deal with
horses, thieves and bandits on the road, and ornery gateguards at
the towns you pass. If you try to shortcut through the desert or
the mountains you can get into ever more trouble unless you know
what you're doing. Is this fun? I think so, but it has to be done
right. Arctic has managed a balance after being up for four years.
Most MUDs fall flat on their face when they try to do this sort of
thing.
>Consider this example:
[really nice example snipped]
>From a programming standpoint, I feel the above is all codable by
>someone of competent skill. Note that there's quite a bit more than
>mere inventory/limb management at work here; there's also terrain
>interaction, object recognition, an improved parser, and a safety/
>override system. The hardest thing, I feel, is giving a rooms a
>way to decide where to put a volatile object, like the lit torch.
Yeah. Rooms are way too mushy as it stands: they have no sense of
spaciality, or even a simple way to tell the difference between a
huge underground cavern and a tower made of granite.
>In summary, it might not be best to give every character an expert
>system to run things for them. Instead, letting it run in stride
>with the intelligence attribute could add an interesting dimension
>to a mud, and provide more incentive for characters to pay attention
>to all attributes, rather than max out one.
An interesting idea. Personally I think your parser was a little
_too_ nice, though certainly codeable. It reminds me a little of
the old Infocom games. There, the player was everything - it was
only processing one person's input, and could afford to dote on them
that way. Also, the "buddy buddy" kind of interface bugs me a
little sometimes. I tend to go for the real cut and dry kind of
interface, in order to feel like I'm really in my character's shoes
rather than just controlling him through third party.
The example you outlined is a vast improvement though, and a lot
like what I would have suggested.
Orion Henry
>Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>[some examples of where the mud server should take care of trivial
>things for you, such as eating, drinking, opening doors, etc.]
>
>Wow! Those were some great ideas I had not thought about. Rest
>assured that I will consider their implementation at Aardvark.
*smile*
>>>> l in corpse
>>>corpse (here):
>>>some coins
>>>a potion
>>
>>Why are corpses containers? *sigh*
>
>I understand your *sigh* here, but I'm not sure how to better emulate
>such a thing. What are your thoughts in this area?
Here's a thought; why do we extract_char() the character that's
dieing and replace it with a half-as detailed object, then fill said
object with the characters inventory? Isn't this rather a lot of
work to do for nothing? Hell, POS_DEAD already exists in stock
diku, but is mostly unused. A dead character is still a character,
why do we have to change them into an object? (Other than the
processor/memory saving issues, which I think are quickly becoming
moot considering the trend in processor power and cheap memory.)
>>Oh, definitely. Don't get me wrong; I'll sacrifice any realism it
>>takes in order to gain just one small bit of "fun factor" - that's
>>what it's about, after all. But realism makes the world more
>>interesting, consistant, atmospheric, and just plain *real* (hence,
>>"realism"...), which makes for an overall better mudding
>>experience.
>
>You might like this. I hacked up my .wld structure and did the following:
[some descent stuff deleted]
>So now instead of just having Forest or Mountains. I can have a
>Mountainous Forest in a Sub-Arctic region. Perhaps a Rocky Desert
>in the Tropics. And, in fact, I can't think of a point on the globe
>that I can't simulate with these three flags.
Certainly all good; it's the kind of thing where one has to say,
"Why wasn't this done three years ago?" I suppose the only
reasonable answer to this is that once you start making changes like
this, it tends to start to get the balling rolling rather quickly
and you find yourself making sweeping changes that take no small
amount of effort to change (yes, I do speak from experience here).
But isn't that what we need, instead of yet another [Circle/Merc/Diku
/ROM/Envy/Whatever] MUD?
kper...@garnet.acns.fsu.edu
On 2 Jul 1996 22:17:50 GMT ga...@clark.net wrote:
: It comes back to the same thing: where to draw the line when
: simulating reality. In the case you describe, there are issues to
: consider: what do we tell the player if there isn't an easy way to
: open that door? What do we tell the player if there's an easy way
: to open it, but it involves a lot of equipment shuffling (sheathe
: sword, switch torch hands to access keys in the left belt pouch,
: rifle through them, unlock the door, etc...)? And how much of this
: should the mud do automatically; at what point should the player be
: required to rearrange his equipment?
If there is an obvious way to do something, one which anyone
who dared to consider him/herself an adventurer would know, such
as that you need a free hand to open a door, there seems no need
to bother with it at all. If it is something that even an adventurer
would need to figure out, those are the things that should not be
done automatically. Those after a bit more realism might consider
a character's intelligence and experience in determining which tasks
fall into which category.
Ho-Sheng Hsiao
Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
: In article <4r8qq3$l...@lut.fi>, Ari Kangas <ar...@news.lut.fi> wrote:
: The second version seems to me to be providing too much detail;
: they don't really tell the player anything useful, but still consume
: CPU time to put together and bandwidth to send out... especially if
: you send out a similar message to everything in the room.
Just a minor thought, perhaps trivial: what if not everyone is aware of
that amount of detail, except the person doing the action?
--
---hhh (Qaexl)
The truth shall set you free only to be fettered again; grin and bear it [G]
"Everything is real unless declared an integer." --- Modified saying from
Rick Cook's Wizardry Compiled
Travis S Casey
><ga...@clark.net> wrote:
>What I'm about to say applies mainly to the Diku muds out there. I'm
>not sure how the mobiles are set up in LP, Teeny or other formats.
>
>In a Diku, when a mob dies, the following things happen:
>1. A temporary object gets created... the mobs corpse.
>2. A "rot" timer gets set on the object.
>3. All the stuff the mob has is transfered to the corpse item.
>4. The mob gets extracted.
>5. Later, when the "rot" timer reaches 0, the corpse is extracted.
>
>This sequence is all triggered when the mob reaches POSITION_DEAD.
>
>Wouldn't it make more sense to just stick a rot timer on the mob when
>the mob reaches POSITION_DEAD? It's not like you have to modify things
>like movement, aggressions, etc. All those routines already check to
>see if the mob is POSITION_STANDING first.
>
>If you're concerend about mobs taking up more memory than objects, you
>could set their bitvectors to 0 upon death, remove any spec procs they
>have, etc. Something tells me that that's got to be more memory
>conservative than creating a non-protyped object, transfering everything
>to it, and purging out the mob.
Well, I'm not a Diku programmer, but I do have a lot of LP experience.
:-) The sequence you describe is the same on most LP's. However,
on LP's, each object has its own copy of all the variables for that
kind of object. Thus, each monster has its own copy of the variables
that monsters use. Now, since monsters have far more options than
almost anything else but players, there are a lot of variables
associated with monsters. Even when these variables are all set to
zero, they still take up memory.
A simple container, on the other hand, has relatively few variables;
mainly its short and long descriptions and how much weight it's
currently carrying. Thus, using a container will save a good
deal of memory... on an LP, at least.
Also, if one does remove all those settings from the monster, on
an LP, that's going to require a good deal of code to set each
of those variables to zero. This code will require time to run,
and will take up some memory (admittedly not much). Depending on
how many variables need to be reset, it may be faster to simply
destroy the object and create a new container object.
>Then again. I'm a Civil Engineer, not a Computer Scientist.
>
>If you go with this system, about the only other thing you'd need to
>modify would be "get/take", allowing you to take things from mobs
>which are DEAD. Or, of course, you could add a loot command.
>
>>If it's so necessary to avoid such ridiculousness as "looking
>>in corpses", why not make a special kind of container? This is
>>an idea I mentioned elsewhere in this thread. Instead of making
>>a simpler object from a more complex one, you'd go the other way,
>>which to me makes more sense when trying to save memory, both on
>>the machine and in your head. :-)
>
>Wait, let me get this straight. Instead of making a simpler object
>from a more complex one.... you could go the other way and make
>a complex object from a simpler one. How would this save you
>memory? It seems to me that the more complex an object (and by object,
>I mean anything: item, mob, room), the more memory it would use.
The question, then, is this: which is going to ultimately be more
complex: a monster, or a corpse object? IMHO, unless you're adding
a *ton* of functionality to your corpses, they're going to be less
complex than a monster.
To put this another way, let's say we measure complexity with numbers.
If a container is complexity three and a mob is complexity ten, then
it's quite possible that making something more complex than a standard
container can still give you something simpler than the less complex
mob would be.
>Kinda funny. Before I started this post, I had planned on leaving the
>mob container thing alone. Now I've pretty much talked myself into
>hacking that up.
Well, to each his own...
Oh, a quick thought... one case where it might make sense to leave
the mobile there as a corpse is on a mud which allow necromancy to
be used to make zombies, etc. from corpses. The corpse could
retain all its stat info, so that if someone made a zombie from it,
the zombie could have stats based on those the mobile had in life.
However, I think that if you're not going to be saving the stat
info, a container should be able to do the job with much less
memory use.
Travis S Casey
You're right... however, you have to start somewhere, and, as the
old saying goes, "the devil is in the details." :-)
There are discussions going on right now in other threads and in
other mud groups about other aspects of making realistic muds;
we're not ignoring the broader issues... it just seems that for
some reason, inventory handling and looting seem to draw flak
from a lot of people.
Travis S Casey
Ho-Sheng Hsiao <hsh...@freenet.columbus.oh.us> wrote:
>Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
>: In article <4r8qq3$l...@lut.fi>, Ari Kangas <ar...@news.lut.fi> wrote:
>: The second version seems to me to be providing too much detail;
>: they don't really tell the player anything useful, but still consume
>: CPU time to put together and bandwidth to send out... especially if
>: you send out a similar message to everything in the room.
>
>Just a minor thought, perhaps trivial: what if not everyone is aware of
>that amount of detail, except the person doing the action?
Erm... I said "especially if...". That means that statement applies
to it regardless of whether or not you send out messages to everyone;
it just applies even more if you do.
Jettero Heller
kper...@garnet.acns.fsu.edu wrote:
Yes, but needing a free hand to open a door may have many other
consequences. Once you have a free hand to open the door while
holding the torch in your other hand what do you do if you are
immediately attacked? You should have to switch torch hands, draw
your sword and then attack.
** Heller
--
This is .signature file was randomly generated.
http://www.nacs.net/~heller/
Don't look back, the lemmings are gaining on you.
We do precision guesswork
Eric Pilcher
This is why I hacked up rooms for my code. I have a flag which
controls climate, a flag which controls terrain, and a third which
controls vegetation.
I'll be adding commands such as 'forage' to take advantage of these
flags. Such a thing will have varied results. Obviously you have
a better time of finding food if your in a Tropical Forest than you
would in an Arctic Plain. And... it's not without it's hazards. What
you forage might very well be poisonous.
Outdoor types such as Rangers and Druids will, naturally, get better
results.
ga...@clark.net
Eric Pilcher <ra...@kira.peak.org> wrote:
><ga...@clark.net> wrote:
>>
>>Mind you, I'm not an experience mud programmer by any means; just
>>experienced in C programming in general. But off the top of my
>>head, a mobile seems to be a much more complicated object than
>>a container, which would mean that as a mobile, a corpse would
>>effectively be a large, memory-hogging, detailed version of a
>>mobile, only with seven-eighths of the features disconnected.
>
>
>If you're concerend about mobs taking up more memory than objects, you
>could set their bitvectors to 0 upon death, remove any spec procs they
>have, etc. Something tells me that that's got to be more memory
>conservative than creating a non-protyped object, transfering everything
>to it, and purging out the mob.
(If by bitvectors you mean what I think you mean, namely, pointers,
you'll need mark the memory they point to as free. If that's not
what bitvectors are, then disregard.)
Like I said before, mobiles strike me as inherently larger and more
complex objects than modified containers. Mobiles would have more
attributes (hit points, alignment, equipment, etc.), not to mention
chat functions, attack functions, and so on. Even if you set all
those functions to nil, the pointers are still there. True, in my
case you'd have one more standard class (the container), but if it's
so much smaller and simpler than a mobile, how can memory not be
saved?
>Then again. I'm a Civil Engineer, not a Computer Scientist.
Don't fret it; a MUD programmer's basically a cross between the
two anyway. :^)
>If you go with this system, about the only other thing you'd need to
>modify would be "get/take", allowing you to take things from mobs
>which are DEAD. Or, of course, you could add a loot command.
If I don't miss my guess, you'd still also have to painstakingly
go through all the code, making sure that a corpse is treated
correctly by other classes, even though it's a mobile. (You don't
want players to be able to attack it, for example. Or maybe you
do. <shrug>)
>>If it's so necessary to avoid such ridiculousness as "looking
>>in corpses", why not make a special kind of container? This is
>>an idea I mentioned elsewhere in this thread. Instead of making
>>a simpler object from a more complex one, you'd go the other way,
>>which to me makes more sense when trying to save memory, both on
>>the machine and in your head. :-)
>
>Wait, let me get this straight. Instead of making a simpler object
>from a more complex one.... you could go the other way and make
>a complex object from a simpler one. How would this save you
>memory? It seems to me that the more complex an object (and by object,
>I mean anything: item, mob, room), the more memory it would use.
Of course. But part of my point is that my modified container
would take less memory than a mobile, even a dead one, and thus
be more memory-efficient.
Say a container takes 1K memory, my modified version takes 2K, and
a mobile takes 3K. The modified version will be the 1K object
plus some additions, making it 2K, whereas the corpse would still
be 3K, only with up to 1K of its code just sitting there, disabled.
Paul Brinkley
ga...@clark.net
Tim Hollebeek
Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
: I agree with you completely. I believe that the mud should figure
: out how the character should do something (possibly within limits
: bounded by the character's intelligence, as someone else pointed
: out), and just let you do it without telling you in detail how
: you do it.
: That is, if both of a character's hands are full and he/she tries to pick
: something up, I want to show the player something like:
: : get thingamabob
: You pick up the thingamabob.
: And not something like:
: : get thingamabob
: You sheathe your sword, pick up the thingamabob, put it in your left
: hand with the bag you're holding there, and then draw your sword
: again.
What you are really arguing here is that you don't want a game to
worry about this level of detail. IMO if the game _is_ this detailed,
it should tell you. And, of course, there is the possibility that
something happens because of an implicit action. E.g. if the
thingamabob paralyzes you when you pick it up, your sword should be in
your sheath. An overly simple implementation would leave it in your
hand, assuming it was going to be drawn again later.
Of course, I might be the only one in the thread who isn't just
blueskying; the Lima lib actually supports this (but not down to the
hand level; IMO that's obnoxious):
----Transcript from Lima Bean (lima.imaginary.com 7878)----
> look
Grand Hall [exits: northwest, up, down, north, west, south, east]
The Grand Hall, the meeting place for Lima Wizards, is a large room with
polished wooden floorboards, and rough hewn beams overhead. A narrow flight of
stairs lead upwards, their top splashed by flickering blue light, while an
equally narrow flight leads downwards into the gloom. Two rocky passages leave
the room. The northwest one is warm and sulfurous, while the south passage
smells faintly malodorous, as though something had died in the recent past.
A low doorway in the east wall allows access to the example room, a glowing
portal in the north wall leads to the mortal start area, and to the west is
the quiet room. Its door is currently open.
A magic torch lies here, abandoned.
A large stone lies off to the side of the room.
Deeply embedded in the stone is:
a sword
Rassilon, the Timelord [idle 7 hours]
> wield sword
(Taking the sword from the stone first)
The sword slides easily out of the stone.
Taken.
You wield a sword.
----End Transcript----
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
ga...@clark.net
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>>Why are corpses containers? *sigh*
>>
>>As opposed to what?
>
>Er...as opposed to being corpses.
>
>>I find it easiest from a coding perspective to
>>treat a corpse as a container, albeit a special one, one whose
>>contents are visible. Sorta like a belt; a belt can hold pouches,
>>but it doesn't hide them.
>
>It was a good hack years ago, but I think we can come up with
>something better in this day and age.
What would be better? If we make a new class, called "corpse",
which has exactly the same functionality as an already-present
class in the mudlib, what have we gained? One thing I learned
from lurking around muds: if a rose by any other name is still
a rose, then by gawd either give it new features, or it's simply
not worth the disk space it's taking up. Did you have something
in mind for a corpse class, with added functionality?
>[realism as a fun factor discussion omitted]
This seems pretty much like tomayto-tomahto to me; our definitions
of "fun" and "reality" are set differently. (Now there's something
that sounds weird out of context...)
>Well, the distance thing you mention is interesting. Continuing
>what I was saying about Arctic: there, walking between towns is a
>bit of a chore. If you buy something on auction and they are in
>Solace, while I'm in the Flying Citadel, I say "Okay, I'll be down
>there in about 30 mins RL."
Yeesh. Well, at least it's not too terribly boring of a trip.
Does it still take 30 minutes if you don't meet anyone along the
way?
>>Consider this example:
>[really nice example snipped]
>>From a programming standpoint, I feel the above is all codable by
>>someone of competent skill. Note that there's quite a bit more than
>>mere inventory/limb management at work here; there's also terrain
>>interaction, object recognition, an improved parser, and a safety/
>>override system. The hardest thing, I feel, is giving a rooms a
>>way to decide where to put a volatile object, like the lit torch.
>
>An interesting idea. Personally I think your parser was a little
>_too_ nice, though certainly codeable. It reminds me a little of
>the old Infocom games. There, the player was everything - it was
>only processing one person's input, and could afford to dote on them
>that way. Also, the "buddy buddy" kind of interface bugs me a
>little sometimes. I tend to go for the real cut and dry kind of
>interface, in order to feel like I'm really in my character's shoes
>rather than just controlling him through third party.
I kinda smiled at this. The parser wasn't really all -that- improved;
in my example I saw only two extra features that I haven't seen already
done on a mud. "loot", of course, is a common command; and I don't
know of a single mud that doesn't allow getting "all" objects from
a room or container.
The "except" preposition is fairly self-explanatory, and I feel
it's fairly easy to add to any mud. Helpful if you want to put
on all the armor in your inventory, EXCEPT that one cursed item,
without dropping it.
The "anyway" modifier operates on the assumption that my safety/
override system is in effect. The safety part lets a character
go through life without doing abnormally stupid things due to a
typo, mistyped command, and so on. But it also does a bit more.
For instance, in my example, the player wished to "wear all" armor
in his inventory and on the ground; safety kept him from wearing
a second belt, and also from putting on an item which he knew to
be cursed, due to a personal ability to detect cursed items. (I
decided, but didn't specify, that he had this unique skill.) If
there was a piece of armor available which was much too heavy to
wear, safety would have kept him from even picking it up.
"anyway" is the override. It keeps the safety system from
railroading the character; if he -really- wants to put on that
cursed breastplate, he can, but he has to deliberately say so.
It has the added bonus of usually making sense to the player;
I say "usually" because as I'd visualized it, the player could
have said "wear all anyway" without first saying "wear all",
thus throwing caution to the wind.
This has wandered off the topic of inventory management, but not
too far, I trust. I started with the idea of an AI engine that
would figure out what goal the player wanted, and shuffled the
inventory around until the goal was accomplished. As a result,
it seemed necessary to me to be able to control the shuffling a
bit; after all, a player isn't going to want an automatic system
like this if it will get his character into unexpected trouble.
Thus, the safety/override system and parser extensions became
necessary.
Paul Brinkley
ga...@clark.net
Aran Zontine
In article <4rfih8$m...@clarknet.clark.net>, <ga...@clark.net> wrote:
>Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
[ stuff about corpse containers snipped ]
>>Well, the distance thing you mention is interesting. Continuing
>>what I was saying about Arctic: there, walking between towns is a
>>bit of a chore. If you buy something on auction and they are in
>>Solace, while I'm in the Flying Citadel, I say "Okay, I'll be down
>>there in about 30 mins RL."
>
>Yeesh. Well, at least it's not too terribly boring of a trip.
>Does it still take 30 minutes if you don't meet anyone along the
>way?
That's assuming you don't meet anybody on the way, are riding a
horse (not flying or walking), don't have refresh (pretty easy not
to have it), and don't meet anybody. With fly and refresh (one
reason druids are fun) you can go pretty much wherever you want in
a matter of minutes. A couple years back when you could summon
horses the trip could end up taking much more time, mostly because
of Saji summoning every horse on the mud to the druid compound in
Tarsis (always seemed to get Troy's while he was in the desert :)
The distance on Arctic really does make you appreciate world size,
as opposed to AnotherMUD(tm) with a couple hundred mvs and refreshing
spells, along with a basic assurance of flying, world size isn't even
a factor you consider. Considering one of the most common paths I
walked to go to the entrance to the zone with Ogre Gauntlets was:
7n16e8wns12e;#70 northeast;10n
Trips of about 150-200 mvs are pretty common there and take all of 30
seconds to complete (that's at 1mv a step).
[ snip ]
>Paul Brinkley
>ga...@clark.net
_____
Miles
Abigail
[ rgmm removed - it's already being posted in *lp and *diku ]
Travis S Casey (ca...@upsilon.cs.fsu.edu) wrote:
: ><ga...@clark.net> wrote:
:
: >If you're concerend about mobs taking up more memory than objects, you
: >could set their bitvectors to 0 upon death, remove any spec procs they
: >have, etc. Something tells me that that's got to be more memory
: >conservative than creating a non-protyped object, transfering everything
: >to it, and purging out the mob.
:
: Well, I'm not a Diku programmer, but I do have a lot of LP experience.
: :-) The sequence you describe is the same on most LP's. However,
: on LP's, each object has its own copy of all the variables for that
: kind of object. Thus, each monster has its own copy of the variables
: that monsters use. Now, since monsters have far more options than
: almost anything else but players, there are a lot of variables
: associated with monsters. Even when these variables are all set to
: zero, they still take up memory.
:
: A simple container, on the other hand, has relatively few variables;
: mainly its short and long descriptions and how much weight it's
: currently carrying. Thus, using a container will save a good
: deal of memory... on an LP, at least.
:
: Also, if one does remove all those settings from the monster, on
: an LP, that's going to require a good deal of code to set each
: of those variables to zero. This code will require time to run,
: and will take up some memory (admittedly not much). Depending on
: how many variables need to be reset, it may be faster to simply
: destroy the object and create a new container object.
I don't think it's that simple. First of all, the memory gain isn't
much. Sure, there are a lot of variables, but compared to the number
of monsters out there, there are only a few corpses; which don't tend
to exist long anyway. Secondly, there is no need to set the variables
of the monster to zero. Who cares if the corpse has dex == 15? Third,
the cost of creating a new object and transfering the equipment from
one object to another probably outweights any other gains, considering
all the init()s, exit()s, encounter()s and whatever else is triggered
by moving objects around.
I think the main reason to use a different corpse program is to make
the programming easy. A thing is either a monster or a corpse.
You do not have to put a lot of if (i_am_a_corpse) in your code.
:
: >Then again. I'm a Civil Engineer, not a Computer Scientist.
: >
: >If you go with this system, about the only other thing you'd need to
: >modify would be "get/take", allowing you to take things from mobs
: >which are DEAD. Or, of course, you could add a loot command.
: >
: >>If it's so necessary to avoid such ridiculousness as "looking
: >>in corpses", why not make a special kind of container? This is
: >>an idea I mentioned elsewhere in this thread. Instead of making
: >>a simpler object from a more complex one, you'd go the other way,
: >>which to me makes more sense when trying to save memory, both on
: >>the machine and in your head. :-)
: >
: >Wait, let me get this straight. Instead of making a simpler object
: >from a more complex one.... you could go the other way and make
: >a complex object from a simpler one. How would this save you
: >memory? It seems to me that the more complex an object (and by object,
: >I mean anything: item, mob, room), the more memory it would use.
That's true, but is that a bad thing? The more complex objects are,
the more interesting they are. And in my opinion, that still is the
goal of muds, provide an interesting environment; leave the memory
management to the driver guys.
: The question, then, is this: which is going to ultimately be more
: complex: a monster, or a corpse object? IMHO, unless you're adding
: a *ton* of functionality to your corpses, they're going to be less
: complex than a monster.
That is not the point. The point is that a combined program is more
complex than the two programs together. [I rather use the term program
here; I use the term object for an instance (clone/blueprint) of a
program.]
BTW, I do think the concept of corpsses being a container sucks.
If I kill a monster, I expect to find the corpse inside the armour;
not the other way around. And the only sword which would stick inside
it would be mine, not his.
Abigail
Jodi L. Pilcher
<ga...@clark.net> wrote:
>
>What would be better? If we make a new class, called "corpse",
>which has exactly the same functionality as an already-present
>class in the mudlib, what have we gained? One thing I learned
>from lurking around muds: if a rose by any other name is still
>a rose, then by gawd either give it new features, or it's simply
>not worth the disk space it's taking up. Did you have something
>in mind for a corpse class, with added functionality?
Animate dead? Would work much better if the corpse were indeed
a corpse than if it were just a container, wouldn't it?
Jodi
--
~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jodi Lynn Pilcher kit...@digiforest.com http://www.peak.org/~kitten
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Abigail
Jettero Heller (hel...@nacs.net) wrote:
: Yes, but needing a free hand to open a door may have many other
: consequences. Once you have a free hand to open the door while
: holding the torch in your other hand what do you do if you are
: immediately attacked? You should have to switch torch hands, draw
: your sword and then attack.
I am more concerned with the other way around. I find it highly
unrealistic that one can have drinks or a snack in combat.
Abigail
Abigail
ga...@clark.net wrote:
: Eric Pilcher <ra...@kira.peak.org> wrote:
: >If you're concerend about mobs taking up more memory than objects, you
: >could set their bitvectors to 0 upon death, remove any spec procs they
: >have, etc. Something tells me that that's got to be more memory
: >conservative than creating a non-protyped object, transfering everything
: >to it, and purging out the mob.
:
: (If by bitvectors you mean what I think you mean, namely, pointers,
: you'll need mark the memory they point to as free. If that's not
: what bitvectors are, then disregard.)
:
: Like I said before, mobiles strike me as inherently larger and more
: complex objects than modified containers. Mobiles would have more
: attributes (hit points, alignment, equipment, etc.), not to mention
: chat functions, attack functions, and so on. Even if you set all
: those functions to nil, the pointers are still there. True, in my
: case you'd have one more standard class (the container), but if it's
: so much smaller and simpler than a mobile, how can memory not be
: saved?
But the code for those functions is shared between all monsters
anyway. It doesn't really matter what the difference in complexity is.
Unless you have one monster, and only use the blueprint, the code
for the chat functions etc doesn't go away after desting the object.
All you do is save the memory for a few variables.
: Say a container takes 1K memory, my modified version takes 2K, and
: a mobile takes 3K. The modified version will be the 1K object
: plus some additions, making it 2K, whereas the corpse would still
: be 3K, only with up to 1K of its code just sitting there, disabled.
Cool. Now take a reasonable sized mud, taking up 20Mb. On average
there will be, say 2 corpses in the mud? Then you have saved 0.1%
of your memory usuage. Not a big deal.
Abigail
Abigail
ga...@clark.net wrote:
: Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
: >>>Why are corpses containers? *sigh*
: >>
: >>As opposed to what?
: >
: >Er...as opposed to being corpses.
: >
: >>I find it easiest from a coding perspective to
: >>treat a corpse as a container, albeit a special one, one whose
: >>contents are visible. Sorta like a belt; a belt can hold pouches,
: >>but it doesn't hide them.
: >
: >It was a good hack years ago, but I think we can come up with
: >something better in this day and age.
:
: What would be better? If we make a new class, called "corpse",
: which has exactly the same functionality as an already-present
: class in the mudlib, what have we gained? One thing I learned
: from lurking around muds: if a rose by any other name is still
: a rose, then by gawd either give it new features, or it's simply
: not worth the disk space it's taking up. Did you have something
: in mind for a corpse class, with added functionality?
But it still can be a good idea to have two classes with the
same functionality. Suppose you have "corpse" and "container"
and they are the same. You decide to remove "corpse" and everyone
happily uses "container". Then , after a year, you decide to
add some functionality to corpses. But that will be a bit of a problem,
since noone made a difference between corpses and containers.
However, if you had 2 classes, this wouldn't have been a problem.
Abigail
Eric Pilcher
Abigail <abi...@ny.fnx.com> wrote:
>I don't think it's that simple. First of all, the memory gain isn't
>much. Sure, there are a lot of variables, but compared to the number
>of monsters out there, there are only a few corpses; which don't tend
>to exist long anyway. Secondly, there is no need to set the variables
>of the monster to zero. Who cares if the corpse has dex == 15?
Well, no that's not what I meant. Setting something like dex to 0
from 15 doesn't save you any memory. The variable is still in use,
just with a different number.
However, setting a bitvector to 0 might save quite a bit, as you're
stripping off several flags. Besides, why have a mob flagged
with SPEC_PROC, AGGRESSIVE, STAY_ZONE and/or SANCTUARY, DETECT_INVIS,
DODGE when it's dead.
>I think the main reason to use a different corpse program is to make
>the programming easy. A thing is either a monster or a corpse.
>You do not have to put a lot of if (i_am_a_corpse) in your code.
Grep your code for IS_CORPSE (diku). You'll see it used quite a bit
anyway. Unless, of course, your coder was a fool and didn't take
advantage of utils.h macros.
Abigail
Eric Pilcher (ra...@kira.peak.org) wrote:
: Abigail <abi...@ny.fnx.com> wrote:
: >I don't think it's that simple. First of all, the memory gain isn't
: >much. Sure, there are a lot of variables, but compared to the number
: >of monsters out there, there are only a few corpses; which don't tend
: >to exist long anyway. Secondly, there is no need to set the variables
: >of the monster to zero. Who cares if the corpse has dex == 15?
: Well, no that's not what I meant. Setting something like dex to 0
: from 15 doesn't save you any memory. The variable is still in use,
: just with a different number.
:
: However, setting a bitvector to 0 might save quite a bit, as you're
: stripping off several flags. Besides, why have a mob flagged
: with SPEC_PROC, AGGRESSIVE, STAY_ZONE and/or SANCTUARY, DETECT_INVIS,
: DODGE when it's dead.
Well, I can pack all those flags in a single int, so why bother?
Depending on how many corpses you have on average and the number
of flags, the code to remove those flags might even take more
memory that the saved memory for the variables. In any case, I
think the save is real peanuts, and not worth the trouble.
: >I think the main reason to use a different corpse program is to make
: >the programming easy. A thing is either a monster or a corpse.
: >You do not have to put a lot of if (i_am_a_corpse) in your code.
:
: Grep your code for IS_CORPSE (diku). You'll see it used quite a bit
: anyway. Unless, of course, your coder was a fool and didn't take
: advantage of utils.h macros.
Well, I don't do dikus. :) However, I doubt the reasoning for lpmuds
differs much for dikus in this case. Whether it's in utils.h or not,
comparisons have to be made somewhere. I believe that for the average
mud, death is such a milestone and rare event in the life of a
monster (not to mention one-way) a seperate corpse object is justified.
Abigail
Raz
Maids milked, drummers drummed and lords leapt, when Tim Hollebeek wrote:
> it should tell you. And, of course, there is the possibility that
> something happens because of an implicit action. E.g. if the
> thingamabob paralyzes you when you pick it up, your sword should be in
> your sheath. An overly simple implementation would leave it in your
> hand, assuming it was going to be drawn again later.
True, but I would think that a system which kept the procedure simple from
the *player's* point of view (ie, no reams of messages after every command)
could still use the detailed methodology in the background; then, should
something go wrong along the way, it would tell you - something like:
Successful version:
>take chest
Ok
Unsuccessful version:
>take chest
Sheathing your sword, you pick up the chest but a hidden trap paralyses
you!
...or something along those lines.
[from the transcript]
> > wield sword
> (Taking the sword from the stone first)
> The sword slides easily out of the stone.
> Taken.
> You wield a sword.
It would be nicer if a system could put its messages into proper english as
much as possible. In the example above, the transcript could read:
>wield sword
You take the sword, which slides easily from the stone, and wield it.
It doesn't jar as much, and helps maintain the illusion that you *are* your
character, not merely typing on a keyboard somewhere =)
Raz
Raz
Maids milked, drummers drummed and lords leapt, when Orion Henry wrote:
> why do we have to change them into an object? (Other than the
> processor/memory saving issues, which I think are quickly becoming
> moot considering the trend in processor power and cheap memory.)
True, but most mud creators seem to be tied to finding sites to house their
game for them - and the less resources your game needs, the more willing the
admin will be to hand over the space.
Raz
Travis S Casey
Tim Hollebeek <t...@wfn-shop.princeton.edu> wrote:
>Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
>
>: That is, if both of a character's hands are full and he/she tries to pick
>: something up, I want to show the player something like:
>
>: : get thingamabob
>: You pick up the thingamabob.
>
>: And not something like:
>
>: : get thingamabob
>: You sheathe your sword, pick up the thingamabob, put it in your left
>: hand with the bag you're holding there, and then draw your sword
>: again.
>
>What you are really arguing here is that you don't want a game to
>worry about this level of detail. IMO if the game _is_ this detailed,
>something happens because of an implicit action. E.g. if the
>thingamabob paralyzes you when you pick it up, your sword should be in
>your sheath. An overly simple implementation would leave it in your
>hand, assuming it was going to be drawn again later.
No... I'm saying that I want the game to worry about that level
of detail, but that that doesn't mean that we have to tell
the *players* everything at that level of detail.
For example, in combat, most muds tend to give messages like this:
> kill troll
You graze the troll in the leg.
The troll misses you by a mile.
etc...
This message may be summarizing the results of a much more complex
process, along these lines:
- check whether there's an object named "troll" here
- check whether it can be attacked
- mark the character as fighting the troll
- mark the troll as fighting the character
- check the character's sword skill vs. the troll's dodge
ability to see if the blow connected
- determine damage
- check to see if the damage overcame the troll's natural
armor
- apply damage to the troll
and so on...
Now, the mud could reflect this by giving a whole series of
messages...
> kill troll
You set your sights on the troll and begin attacking it.
The troll begins attacking you.
You swing your sword at the troll.
Your blow hits the troll in the leg with great force.
The troll's rubbery leg is only slightly damaged.
etc.
The point here is that muds give a much higher-level description
of combat than most of them actually use internally. What I'm
proposing is that, in most cases, a high-level description of
such actions as picking something up can also be taken. In odd
cases (such as the paralyzing sword you mention), the messages
can give a different level of detail.
>Of course, I might be the only one in the thread who isn't just
>blueskying; the Lima lib actually supports this (but not down to the
>hand level; IMO that's obnoxious):
I'm only partially blueskying. :-) I've written code to support
some of this, but don't have it completed yet.
[parts of transcript cut]
>A large stone lies off to the side of the room.
>Deeply embedded in the stone is:
> a sword
>
>> wield sword
>(Taking the sword from the stone first)
>The sword slides easily out of the stone.
>Taken.
>You wield a sword.
This is a good example. These four messages could easily be
condensed down to:
> wield sword
The sword slides easily out of the stone.
You wield the sword.
Hopefully, we can rely on the player to realize that the sword
is now in his/her character's inventory, without having to have
the "Taken." message. The (taking the sword from the stone first)
message is completely redundant; the message about the sword
sliding out of the stone, combined with the ordering of the messages,
should make it clear to the player that the sword was taken out
of the stone first.
Now, redundancy isn't necessarily a bad thing, and the first version
of wielding the sword could be useful, especially for inexperienced
players. However, it seems to me to be a waste of bandwidth to
*always* give that level of detail. Perhaps a user-selectable
level of detail would be the best solution?
Travis S Casey
Abigail <abi...@ny.fnx.com> wrote:
>Travis S Casey (ca...@upsilon.cs.fsu.edu) wrote:
>: ><ga...@clark.net> wrote:
[mobile or container for corpses?]
>: A simple container, on the other hand, has relatively few variables;
>: mainly its short and long descriptions and how much weight it's
>: currently carrying. Thus, using a container will save a good
>: deal of memory... on an LP, at least.
>:
>: Also, if one does remove all those settings from the monster, on
>: an LP, that's going to require a good deal of code to set each
>: of those variables to zero. This code will require time to run,
>: and will take up some memory (admittedly not much). Depending on
>: how many variables need to be reset, it may be faster to simply
>: destroy the object and create a new container object.
>
>I don't think it's that simple. First of all, the memory gain isn't
>much. Sure, there are a lot of variables, but compared to the number
>of monsters out there, there are only a few corpses; which don't tend
>to exist long anyway. Secondly, there is no need to set the variables
>of the monster to zero. Who cares if the corpse has dex == 15? Third,
>the cost of creating a new object and transfering the equipment from
>one object to another probably outweights any other gains, considering
>all the init()s, exit()s, encounter()s and whatever else is triggered
>by moving objects around.
How great the memory gain is depends on the relative number of
variables, and their type, between the monster and container
objects. On some muds, this may only be a few 10's of bytes;
on others, it may be thousands.
I mentioned zeroing variables in the monster not because I think
it's necessary, but because the original poster had suggested that
this could be done to save memory (obviously, this would only work
for some types of variables).
The best way to resolve this, really, is to try it both ways on
the specific mud you're planning on implementing one of these on
and seeing what the results are as far as memory and CPU usage
go. It could go either way.
>I think the main reason to use a different corpse program is to make
>the programming easy. A thing is either a monster or a corpse.
>You do not have to put a lot of if (i_am_a_corpse) in your code.
That's another good reason. :-)
>: >Wait, let me get this straight. Instead of making a simpler object
>: >from a more complex one.... you could go the other way and make
>: >a complex object from a simpler one. How would this save you
>: >memory? It seems to me that the more complex an object (and by object,
>: >I mean anything: item, mob, room), the more memory it would use.
>
>That's true, but is that a bad thing? The more complex objects are,
>the more interesting they are. And in my opinion, that still is the
>goal of muds, provide an interesting environment; leave the memory
>management to the driver guys.
I'd say that you're oversimplifying. Adding complexity simply for
complexity's sake doesn't necessarily make the mud (or anything else,
for that matter) better. It *can* make it better, but that's another
story.
As for memory management... depending on the kind of mud you're
using, this may *be* part of the driver. On an LP, it's probably
going to be part of the mudlib... the optimization of which is
also important if you want to have a mud with reasonable memory
usage.
IMHO, this is like saying, "leave optimization to the compiler".
I can do that, but I've yet to see a compiler that can make a bubble
sort be faster than a shell sort.
>: The question, then, is this: which is going to ultimately be more
>: complex: a monster, or a corpse object? IMHO, unless you're adding
>: a *ton* of functionality to your corpses, they're going to be less
>: complex than a monster.
>
>That is not the point. The point is that a combined program is more
>complex than the two programs together. [I rather use the term program
>here; I use the term object for an instance (clone/blueprint) of a
>program.]
I can accept that a combined program is more complex than its
component programs; however, how does that apply here? Are you
saying that corpses should be a completely separate type of object,
and not be derived from either monsters or containers? Or that
it's better to leave a monster there, rather than switch it with
a container? If the latter, note that you're not truly combining
the two... you're swapping one for the other. That swapping
does add some complexity, yes... but the ultimate result may
still be more efficient than leaving the monster there.
To use an analogy, for me to drive to a ski resort, then put
on skis and use them to get around adds the complexity of
changing from one to the other... however, I think it's
definitely still better than trying to ski from Florida to
the nearest ski resort, or than trying to navigate ski slopes
in my car.
>BTW, I do think the concept of corpsses being a container sucks.
>If I kill a monster, I expect to find the corpse inside the armour;
>not the other way around. And the only sword which would stick inside
>it would be mine, not his.
You're assuming that the container can only implement the "in"
relation. What about a container which things can be "on"?
(Granted, "container" is probably no longer the proper word
at this point, but I can't think of a good one off-hand).
Travis S Casey
Abigail <abi...@ny.fnx.com> wrote:
>ga...@clark.net wrote:
>: Say a container takes 1K memory, my modified version takes 2K, and
>: a mobile takes 3K. The modified version will be the 1K object
>: plus some additions, making it 2K, whereas the corpse would still
>: be 3K, only with up to 1K of its code just sitting there, disabled.
>
>Cool. Now take a reasonable sized mud, taking up 20Mb. On average
>there will be, say 2 corpses in the mud? Then you have saved 0.1%
>of your memory usuage. Not a big deal.
As the old saying goes, waste not, want not. Granted, it's a
small thing, and it's certainly not the first thing that most
muds should worry about when trying to optimize memory, but once
you've optimized the bigger things, why not do the smaller ones
as well?
ObThought: If programs expand to fit the memory available, then
by 2050, the average text editor is going to take about a
terabyte of memory. :-)
Raz
Maids milked, drummers drummed and lords leapt, when Raelyn S. Sweebe wrote:
> One thing that has always irritated me is the inability to get water
> anywhere on a mud. I mean I continually traverse rivers lakes streams etc
> yet I type fill barrel river and it won't let me.
A shame, cos its so easy in DIKU and derivatives (probably others) to put an
object into the river/lake rooms of type ITEM_FOUNTAIN. Problem solved.
Raz
Nick
In article <961003-0207...@152.160.113.153>,>In article <4ra5fs$3...@news.fsu.edu>, ca...@nu.cs.fsu.edu wrote:
>
>> I have to agree; using a mobile seems to be a waste to me, since
>> mobiles have large amounts of code and data which will be useless
>> in this situation.
>
>Yes and no sure you should be able to see it's a helmet and maybe notice
>the spike on top but until you take it from the corpse could you see the
>inscription inside
This depends on the level of object detail. It isn't difficult to flag
certain text to show only when the item is IN_HAND and not when ON_CORPSE,
should someone wish to use this more realistic approach. This does not
speak to memory constraints, but with skillful writing (and perhaps a
text-blocking routine to merge indirectly related text blocks into a
single paragraph or blocked output so things don't look suspicious or
inappropriately obvious), it is a rather simple coding procedure.
> or look inside the bag the corpse has until you take it
Why not? What is there to prevent someone from flicking open a bag
(presuming there is no preventive closure in the way) with the tip of
their sword or the point of their boots, etc. and having a peek inside?
In fact, being able to examine items without having to manually manipulate
them is an underused option. Especially if one is on a MUD which is
liberal with goofy things like no-drop cursed items and such.
>As far as objects go usually I know what is in my backp[ack if I l in back
>I see the contents and I can take them out of backpack but if a potion is
>in my backpack I need to take it out before i can drink it or else have a
>really long straw.
I'm not sure I follow this particular thought. Also, on at least one MUD
I've visited, you could not even wear the backpack that you started with
as a newbie. And on another, you could get and remove items from your
backpack without even removing it - and PCs didn't have triple jointed
arms or prehensile appendages to justify it. These are rather silly and
simple to fix.
> >The question comes down to realism and playability. You hold a light
>weapon shield holdable and your inventory ina ll rights if a mob charged
>you you would drop everything trying to get in a fighting stance. It
>makes little sense to make someone put their holdable inventory on the
>ground dfrop their light and then fight how could you see the monster.
Well, as noted in another message by Orion Henry, the entire concept of
inventory is somewhat silly, but has been taken as a staple in virtually
all MUDs. I believe it is a holdover from games like Zork and such.
Gemstone III which was (or maybe still is) run on the GEnie system was the
first MUD I ever played, before I knew about free ones. It not only did
not have an inventory system, but it also made use of a nice thing I call
'real hands' - you grabbed coins in handfuls, for example. This was some
five years ago now. It is NOT a question of difficulty or lack of
concept, it is a situation of lack of motivation or perceived worth.
As for the dropped torch/light - lighting conditions is one of the most
universally sloppily handled things on MUDs. But that is really food for
an entire thread.
-Nick
Nick
In article <4rcjcm$8...@kira.peak.org>, Eric Pilcher <ra...@kira.peak.org> wrote:
>If you go with this system, about the only other thing you'd need to
>modify would be "get/take", allowing you to take things from mobs
>which are DEAD. Or, of course, you could add a loot command.
I'm not sure why it should be unusual to remove equipment worn by a living
creature (assuming it was willing or unable to react), much less a dead
one.
For example, it would be rather convenient to remove the breastplate of a
paralyzed victim rather than having to kill them first. Something like
this is useful when you don't want to kill the wearer for some particular
reason. It is also logical and wouldn't be a monumental amount of work.
Also, if for example, you have a command which allows you to push or pull
another player or mob that is unable to move, to some safer area,
but you (the dragger) are somewhat weak, you should be able to remove some
of that creature's eq to make the intended process possible.
There are plenty of reasons why this sort of modification could lend a
nice bit of tactical play to a game, while adding realism.
-Nick
Nick
In article <4rbshj$6...@news.fsu.edu>,
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>
>I agree with you completely. I believe that the mud should figure
>out how the character should do something (possibly within limits
>bounded by the character's intelligence, as someone else pointed
>out), and just let you do it without telling you in detail how
>you do it.
>
>something up, I want to show the player something like:
>
>: get thingamabob
>You pick up the thingamabob.
>
>And not something like:
>
>: get thingamabob
>You sheathe your sword, pick up the thingamabob, put it in your left
>hand with the bag you're holding there, and then draw your sword
>again.
I don't agree completely here. I think:
: get thingamabob
You sheathe your sword and pick up the thingamabob.
Is plenty, and still gives you the info that is pertinent. Also, in
practice, one may tend to forget just where the object that was in hand
was put (it's not always going to be a weapon...what happens if it is a
held stone and you need to put it in your bag, and that bag is full, and
the system is smart enough to put it in your other bag instead...but
you're not told this...etc... (ok, a stone is small, but it is just an
example)).
Of course, in a system like this, there may need to be a selectable detail
level like the old Zork games and their VERBOSE/BRIEF/SUPERBRIEF (though
those terms were not used for this sort of thing, but for room descs),
since it is obvious that not everyone will like either extreme.
I, for one, would like to know exactly what the automated system is doing
with my junk. It's my junk after all. :)
-Nick
Nick
In article <961003-0207...@152.160.113.152>,
>anywhere on a mud. I mean I continually traverse rivers lakes streams etc
>yet I type fill barrel river and it won't let me.
Typical laziness. Most zone writers don't seem to care much for fleshing
things out, unless perhaps it's the stats on some nifty weapon.
On most MUDs, fountain objects are available and could easily be placed in
any appropriate room, and in fact opens up some interesting side options.
First, water sources 'out in the field' will not always be safe to drink.
Therefore spells or field skills would then actually be useful to
determine if water from a certain source is safe. It may also then make
useful spells such as purify water.
Water from rivers, streams, wells, seepages, etc. may be contaminated with
parasites, dangerous metals or minerals, etc. And this sort of thing
makes utilitarian spells worth having. I don't think I've ever had
occasion to use the ubiquitous 'detect poison' (which would be analogous
to something like 'detect purity') spell on any of the MUDs I've been to
(and all have had it). It isn't of any use because the gameworld and/or
code precludes it's usefulness.
If there are no hooks, there's no use in having it.
To most MUDders, I think this sort of thief in the night approach (i.e.
unexpected problems) is not something they'd want to deal with. But, most
MUDders are not overly concerned with anything but eq and levels. So you
shoot for a different audience and hope that audience grows when it sees
how interesting playing in a game WORLD can be.
-Nick
ga...@clark.net
]: Like I said before, mobiles strike me as inherently larger and more
]: complex objects than modified containers. Mobiles would have more
]: attributes (hit points, alignment, equipment, etc.), not to mention
]: chat functions, attack functions, and so on. Even if you set all
]: those functions to nil, the pointers are still there. True, in my
]: case you'd have one more standard class (the container), but if it's
]: so much smaller and simpler than a mobile, how can memory not be
]: saved?
]
]But the code for those functions is shared between all monsters
]anyway. It doesn't really matter what the difference in complexity is.
]Unless you have one monster, and only use the blueprint, the code
]for the chat functions etc doesn't go away after desting the object.
]All you do is save the memory for a few variables.
Well, yes, that's true; most functions are shared. (I neglected
to take that into account.) So you're right; all I save is the
memory of variables. But I don't think it's "few". Some monsters
have -tons- of data unique to themselves, which can't be shared;
so-called NPCs are potential examples of this. They tend to have
all sorts of features, from preferred weapons to a detailed chat
function based on what people have said to it before. Of course,
the ratio of such unique creatures' corpses to regular corpses is
very small on the average, so this may not be too great a problem.
But even if it is only a few variables saved, it's better than
nothing, right? Are you saying it's simply not worth the trouble
to have corpses be close descendants of containers, because of
the bit of shifting when a creature dies?
]: Say a container takes 1K memory, my modified version takes 2K, and
]: a mobile takes 3K. The modified version will be the 1K object
]: plus some additions, making it 2K, whereas the corpse would still
]: be 3K, only with up to 1K of its code just sitting there, disabled.
]
]Cool. Now take a reasonable sized mud, taking up 20Mb. On average
]there will be, say 2 corpses in the mud? Then you have saved 0.1%
]of your memory usuage. Not a big deal.
On the average, I'd say muds don't take up that much memory, either.
Much of the time they could be supporting 3-5 players, and be
relatively tiny. If memory is an issue, I think it makes sense to
study it during peak hours, when there's around 50 players and a
heckuva lot more corpses lying around.
Furthermore, this isn't just about saving RAM; it's also about
good design. In my mind, a corpse resembles a container in function
much, much more than it resembles a mobile; thus, corpses should
be based on containers in the code. And having several instantiations
of a class be 50-70% disabled, even if it only means 50 extra bytes
of unused RAM per object, strikes me as really silly.
If anything, I'd prefer mobiles to inherit corpses. It's somewhat
humorous to regard people as dead bodies with "a little something
extra"...
Paul Brinkley
ga...@clark.net
Nick
In article <4r6p46$l...@clarknet.clark.net>,>It sounds like you're saying realism itself is a fun factor. With
>that I can agree. Most people would agree, too; the argument is
>where to draw the line. :-) For instance, I don't think anybody
>wants to walk from Calais to Rome in real time, but many muds have
>locations this far apart, and farther. They often just say "okay,
>pretend you're wearing seven-league boots while you're in the
>wilderness" to preserve sanity.
What's wrong with using transport systems such as mounts, carriages, trade
convoys, etc.? Sure, you can't type /50e2n20e30n to get there in fifteen
seconds, but you should be able to get there without infinite difficulty.
Mounts are AMAZINGLY unimportant in most MUDs, but it seems as though it
could be made to be a very interesting aspect.
I don't see what's wrong with expecting someone to have to consider a trip
across the continent as something more than one line of tintin speedwalk.
There could also be magical means of long-distance travel, commensurate in
their risk and cost, with the type of world one wants to emulate.
>>first, then open it. I shouldn't have to type that. Similarly, if
>>I try to move a direction and the door is shut, I should open it.
>>Why do I have to type all this crap? Isn't it obvious?
>
>In this case, it's inventory management we're discussing, not
>marathon-walking, but even so, should this always be automatic?
>I don't think so; I'll explain later.
>Not to a dullard.
Hehe, but a character with so little appreciation of his own surroundings
would be mincemeat long before he made it anywhere. Because even
intelligent people, when not paying attention, can kiss a door, this sort
of assumption of (in)competence really shouldn't be a PC option. A PC
should always have functional intelligence.
>But why not let intelligence also dictate the things you describe?
This is something I had considered while MUD coding, but never implemented
due to having stopped coding there.
Such things as "You see a wall with dark letters inscribed. You have no
clue what they say" - may be replaced with a detailed translation for a
viewer who wields proper linguistic skills. This sort of thing can be
taken to a long distance with a great deal of interesting baggage.
This of course is applicable to intelligence, past experience, known
skills, etc. as well as expected racial knowledge and so forth.
>Consider this example:
>
>The skeleton falls dead to the ground.
If you want proper detail, your example should read something like, "The
skeleton clatters to a heap of bones" or somesuch, as skeletons are
usually taken to already be dead. (I'm half-joking on the seriousness
here - it's just amusing that this sort of referencing to already dead
mobs (zombies, etc.) is so often made.)
>The corpse is garbed in an iron breastplate, an iron skull cap, and
>a leather belt. On the belt is a brown pouch. The corpse holds a
>rusty sword in its left hand and a buckler in its right hand.
Of course, it would no longer be holding the sword, though it could have
the buckler strapped to it's skeletal forearm. (Still nitpicking for
fun.) In fact, the sword may well have disappeared under the (presumably)
murky water and be forgotten by the player, thus the weapon could now be
considered concealed (another conceptual thing that should be made
common), and outside the scope of that command.
>I would consider the above to be the sort of thing to happen to an
>above-average adventurer. A genius might automatically search the
>chest for traps before opening it. An average character might not
>know to put the torch
This is reasonable, however, you then begin to infringe upon the
intelligence of the player by devoting the character's actions to the
character's intelligence instead. This sort of thing will tend, when
taken in more important contexts, to bolster weak -players- as if they
were being followed around by some sort of advice counselor.
In essence, I don't like the idea of intelligence as an active stat in the
sense you describe. If intelligence is needed for such things as
determining what sort of spells or skills a particular character should be
able to learn and how well they can learn those things, that's acceptable
because it does not encroach on the player's own skills. But automation
beyond more than one would expect of a reasonably intelligent person
begins to distance the player from his in-game persona.
-Nick
Nick
In article <4r8qg3$3...@news.icon.net>,
R. Michael M. <mmo...@genius.icon.net> wrote:
>Fun over balance, balance over realism.
>
Bah! You can have all in fine balance if you work at it. You don't
necessarily have to give them priorities. If dont right you can have it
all.
(Removing rose-colored spectacles.)
Yikes! This is gonna be work!
-Nick
Nick
In article <4r6eql$a...@cnn.Princeton.EDU>,
Tim Hollebeek <t...@wfn-shop.princeton.edu> wrote:>: >Indeed. So why have an inventory? You've already got your hands
>: >"slots" - if those are full, you shouldn't be able to carry any
>: >more. Period. So where does this whole "inventory" thing come in?
>
>: I once saw a mud in which you had no inventory and two hand slots.
>: It is my opinion that such a concept is virtually unplayable unless,
>
>Agreed.
It isn't unplayable since the concept is not nonexistant. For one,
there is a game called Island of Kesmai, which although being simple
graphic based, is more or less MUD-like. It had (when it was state of the
art years ago), upwards of 80 players online at a time, day and night,
24/7 for the first four of five years I played it.
NO inventory as such (you only had a bag in your 'inventory'). You had to
have one hand free to grab something or move it from worn to bag or vice
versa, etc. It felt natural and worked fine for thousands of players.
Inventory is just an expected convenience, engendered by MUD
coders, nothing more.
>: The mob is dead. R.I.P.
>
>I hate the term 'mob'
:) I won't ask why.
>sheesh, get all FROM corpse :-) Ok, enough Diku gripes for now.
It's just typer's shorthand. However it is a cause for immediate
disconnection when I visit a MUD that lames out when I try to 'get bread
from basket' by saying it doesn't see a from basket here. Zork did better
15 years ago.
>If MUDs want to be that realistic, it should go like this:
>
>X dies.
>> l at corpse
>On the corpse, you see:
> some coins
> a potion
>> get all corpse
>some coins:
>(sheathing your sword first)
>You take the coins from the corpse, and deposit them in your money pouch.
>a potion:
>(strapping your shield across your back first)
>You take the potion.
Hmm, why would you need to remove your shield when you've already freed up
a hand by sheathing your sword? Perhaps it was a jeroboam of cure light.
-Nick
Nick
In article <31DAC3...@student.uq.edu.au>,
Paul McInnes <s10...@student.uq.edu.au> wrote:
>Eric Pilcher wrote:
>
>> Like I said. Unplayable. Unless you use tintin, in which case, it's
>> unnoticable. So perhaps some realism should be sacrificed in order
>> to gain some playability.
>
>To be quite honest, the interesting issues have little to do with how
>equipment is stored, and more to do with the type of universe that is
>simulated by the MUD. Realism is about providing the code and system
>design (e.g. combat system) to support a world in which common-sense can
>provide a guide to action.
Perfect.
>This means doing away with classes, dozens of
>exotic races, super-power characters and providing something more
>interesting and meaningful than killing for xp.
First big step.
>being strong is the sole purpose of existing? Sounds like sociopathic
>vampires gone mad.
Hey, you stole my future MUD's name. Damn, I hope people forget, because
an ASCII spam ad for SOCIOPATHIC VAMPIRES GONE MAD would be killer. ;)
>I've got nothing against the D&D hack'n'slay stuff, in fact I love it,
>but the potential for realism in MUDs goes far beyond trivial details
>about handling equipment and looting.
This is my take on the situation as well. I admit to the hack & slash
desires, but I also like heavy detail and heavy realism as well. It just
makes it all the more interesting. So the two can easily coincide in the
desires of those with wider vision. Which sounds a lot more thick and
arrogant than intended.
-Nick
Abigail
Nick (gr...@hondo.cyberverse.com) wrote:
: In article <961003-0207...@152.160.113.153>,
: >
: >> I have to agree; using a mobile seems to be a waste to me, since
: >> mobiles have large amounts of code and data which will be useless
: >> in this situation.
: >
: >the spike on top but until you take it from the corpse could you see the
: >inscription inside
:
: This depends on the level of object detail. It isn't difficult to flag
: certain text to show only when the item is IN_HAND and not when ON_CORPSE,
: should someone wish to use this more realistic approach. This does not
: speak to memory constraints, but with skillful writing (and perhaps a
: text-blocking routine to merge indirectly related text blocks into a
: single paragraph or blocked output so things don't look suspicious or
: inappropriately obvious), it is a rather simple coding procedure.
Yes, but it would be tiresome for the people coding the areas.
It's usually already a troublesome process to come up with good
descriptions; now you need 2 descriptions. And why stop at 2?
A helmet surely looks different while being worn than carried.
(In fact, if it's worn you can "examine" it and get a message
how it feels, but only "look at" using a mirror). And rooms should
have different descriptions depending which direction you are facing.
That all sounds cool and realistic, but it takes a lot of - boring -
work. I don't mind if examining something implicitely includes
turning the thing around and upside down, look into different directions,
listen, smell, etc. (Though checks if the examiner is deaf/blind etc
ought to be taken...)
: > or look inside the bag the corpse has until you take it
:
: Why not? What is there to prevent someone from flicking open a bag
: (presuming there is no preventive closure in the way) with the tip of
: their sword or the point of their boots, etc. and having a peek inside?
:
: In fact, being able to examine items without having to manually manipulate
: them is an underused option. Especially if one is on a MUD which is
: liberal with goofy things like no-drop cursed items and such.
*agree* One also has to take `playability' into account. I rather not
have to type: remove backpack, drop backpack, open backpack, take bottle,
put bottle in backpack, close backpack, take backpack, wear backpack;
when I could do with take bottle in stead, and have the rest done implicitely.
On the other hand, I don't think you should be able to do that while
wielding a sword... Of course, you could implicitely unwield/wield the
sword - but that should take more time.
[ Snip ]
: As for the dropped torch/light - lighting conditions is one of the most
: universally sloppily handled things on MUDs. But that is really food for
: an entire thread.
I agree on the light. Another thing which always bothers me is timing.
On most muds, a command takes as long as it needs you to type it (plus
some net/driver delay); the faster you type, the more you can do.
And it doesn't matter if it is blinking your eye, or climb a 100 metre
rock. If you are fast (or use a client), you can have 5 drinks and
3 meals between swings in combat. *Yuck*
Abigail
Abigail
ga...@clark.net wrote:
: Abigail <abi...@ny.fnx.com> wrote:
: ]ga...@clark.net wrote:
: ]
: ]: Like I said before, mobiles strike me as inherently larger and more
: ]: complex objects than modified containers. Mobiles would have more
: ]: attributes (hit points, alignment, equipment, etc.), not to mention
: ]: chat functions, attack functions, and so on. Even if you set all
: ]: those functions to nil, the pointers are still there. True, in my
: ]: case you'd have one more standard class (the container), but if it's
: ]: so much smaller and simpler than a mobile, how can memory not be
: ]: saved?
: ]
: ]But the code for those functions is shared between all monsters
: ]anyway. It doesn't really matter what the difference in complexity is.
: ]Unless you have one monster, and only use the blueprint, the code
: ]for the chat functions etc doesn't go away after desting the object.
: ]All you do is save the memory for a few variables.
:
: Well, yes, that's true; most functions are shared. (I neglected
: to take that into account.) So you're right; all I save is the
: memory of variables. But I don't think it's "few". Some monsters
: have -tons- of data unique to themselves, which can't be shared;
: so-called NPCs are potential examples of this. They tend to have
: all sorts of features, from preferred weapons to a detailed chat
: function based on what people have said to it before. Of course,
: the ratio of such unique creatures' corpses to regular corpses is
: very small on the average, so this may not be too great a problem.
Not only that, but the lifetime of the corpse often is much smaller
than that of the monster creating it. I've yet to see the mud where
most guilds didn't have a free spell to destroy corpses. If a corpse
decays in 2 minutes or less, while monsters can exist for hours, and
you have 500 times more monsters than corpses on average, what gains
are we talking about?
: But even if it is only a few variables saved, it's better than
: nothing, right? Are you saying it's simply not worth the trouble
: to have corpses be close descendants of containers, because of
: the bit of shifting when a creature dies?
I say the gain is so small, that it shouldn't matter when deciding
whether to use corpses or monsters flagged as being dead.
: ]: Say a container takes 1K memory, my modified version takes 2K, and
: ]: a mobile takes 3K. The modified version will be the 1K object
: ]: plus some additions, making it 2K, whereas the corpse would still
: ]: be 3K, only with up to 1K of its code just sitting there, disabled.
: ]
: ]Cool. Now take a reasonable sized mud, taking up 20Mb. On average
: ]there will be, say 2 corpses in the mud? Then you have saved 0.1%
: ]of your memory usuage. Not a big deal.
:
: On the average, I'd say muds don't take up that much memory, either.
: Much of the time they could be supporting 3-5 players, and be
: relatively tiny. If memory is an issue, I think it makes sense to
: study it during peak hours, when there's around 50 players and a
: heckuva lot more corpses lying around.
And have a lot of monsters as well. You probably want to trim down the
number of variables in often used objects as rooms and monsters. The
gain will be much bigger since there are more of them, and exist longer.
: Furthermore, this isn't just about saving RAM; it's also about
: good design. In my mind, a corpse resembles a container in function
: much, much more than it resembles a mobile; thus, corpses should
: be based on containers in the code. And having several instantiations
: of a class be 50-70% disabled, even if it only means 50 extra bytes
: of unused RAM per object, strikes me as really silly.
I agree on the good design, and (as I have said in another posting)
I am not against using corpses. Not at all. But all that mumble-jumble
about memory strikes me as silly. I'd be very surprised your mudlib
is that efficient that the best gains you can get is by the savings on
this issue.
Abigail
Abigail
Travis S Casey (ca...@xi.cs.fsu.edu) wrote:
: Abigail <abi...@ny.fnx.com> wrote:
: >Travis S Casey (ca...@upsilon.cs.fsu.edu) wrote:
: >: ><ga...@clark.net> wrote:
:
: [mobile or container for corpses?]
:
: >much. Sure, there are a lot of variables, but compared to the number
: >of monsters out there, there are only a few corpses; which don't tend
: >to exist long anyway. Secondly, there is no need to set the variables
: >of the monster to zero. Who cares if the corpse has dex == 15? Third,
: >the cost of creating a new object and transfering the equipment from
: >one object to another probably outweights any other gains, considering
: >all the init()s, exit()s, encounter()s and whatever else is triggered
: >by moving objects around.
:
: How great the memory gain is depends on the relative number of
: variables, and their type, between the monster and container
: objects. On some muds, this may only be a few 10's of bytes;
: on others, it may be thousands.
:
: I mentioned zeroing variables in the monster not because I think
: it's necessary, but because the original poster had suggested that
: this could be done to save memory (obviously, this would only work
: for some types of variables).
:
: The best way to resolve this, really, is to try it both ways on
: the specific mud you're planning on implementing one of these on
: and seeing what the results are as far as memory and CPU usage
: go. It could go either way.
Yes, but I very much doubt the gain is significant. Which mud has
many corpses all lasting relatively long all the time? Since the
lifespan of a corpse is short, and there are relatively few corpses
compared to the number of monsters running lose, the gain is
insignificant. I don't think corpses are bad - I just can't take
the memory argument seriously.
: >: >Wait, let me get this straight. Instead of making a simpler object
: >: >from a more complex one.... you could go the other way and make
: >: >a complex object from a simpler one. How would this save you
: >: >memory? It seems to me that the more complex an object (and by object,
: >: >I mean anything: item, mob, room), the more memory it would use.
: >
: >That's true, but is that a bad thing? The more complex objects are,
: >the more interesting they are. And in my opinion, that still is the
: >goal of muds, provide an interesting environment; leave the memory
: >management to the driver guys.
:
: I'd say that you're oversimplifying. Adding complexity simply for
: complexity's sake doesn't necessarily make the mud (or anything else,
: for that matter) better. It *can* make it better, but that's another
: story.
I was assuming reasonable coders who only add complexity if it makes the
game better (for whatever better suits you). I didn't know you weren't
such a coder. ;)
: As for memory management... depending on the kind of mud you're
: using, this may *be* part of the driver. On an LP, it's probably
: going to be part of the mudlib... the optimization of which is
: also important if you want to have a mud with reasonable memory
: usage.
:
: IMHO, this is like saying, "leave optimization to the compiler".
: I can do that, but I've yet to see a compiler that can make a bubble
: sort be faster than a shell sort.
Yeah, but wouldn't it be great if we can just say 'sort', and let
the compiler use heapsort? (Which beats bubble sort and Shellsort.
(FYI: Shellsort needs to be capitalized, it's named after mister Shell))
: >: The question, then, is this: which is going to ultimately be more
: >: complex: a monster, or a corpse object? IMHO, unless you're adding
: >: a *ton* of functionality to your corpses, they're going to be less
: >: complex than a monster.
: >
: >That is not the point. The point is that a combined program is more
: >complex than the two programs together. [I rather use the term program
: >here; I use the term object for an instance (clone/blueprint) of a
: >program.]
:
: I can accept that a combined program is more complex than its
: component programs; however, how does that apply here? Are you
: saying that corpses should be a completely separate type of object,
: and not be derived from either monsters or containers? Or that
: it's better to leave a monster there, rather than switch it with
: a container? If the latter, note that you're not truly combining
: the two... you're swapping one for the other. That swapping
: does add some complexity, yes... but the ultimate result may
: still be more efficient than leaving the monster there.
I say that *if* you swap a corpse object for the container object,
you end up with less complex code. You need of course somewhere
some code to switch to objects, but for the rest you don't have to
make a difference for being in "living mode" and "dead mode", if you
understand what I mean. Sure, you might end up with more code, but
more code doesn't always mean the code is more complex.
: To use an analogy, for me to drive to a ski resort, then put
: on skis and use them to get around adds the complexity of
: changing from one to the other... however, I think it's
: definitely still better than trying to ski from Florida to
: the nearest ski resort, or than trying to navigate ski slopes
: in my car.
Yes, and in my opinion it is *less* complex. Otherwise, while being
in Florida, you continously have to check whether you wear skies
or not.
if (!wear_skies) {enter_highway ();}
else {huff_and_puff (on_the_side_walk);}
And while navigating the slopes, you are still checking.
if (wear_skies) {make_sharp_turn ();}
else {lose_grip ();
crash ();}
Abigail
Travis S Casey
Abigail <abi...@ny.fnx.com> wrote:
>Travis S Casey (ca...@xi.cs.fsu.edu) wrote:
>
>Yes, but I very much doubt the gain is significant. Which mud has
>many corpses all lasting relatively long all the time? Since the
>lifespan of a corpse is short, and there are relatively few corpses
>compared to the number of monsters running lose, the gain is
>insignificant. I don't think corpses are bad - I just can't take
>the memory argument seriously.
I never said that it was a huge gain... I simply pointed out
that it does save some memory. Every little bit helps, if you'll
pardon the pun. :-)
>: >That's true, but is that a bad thing? The more complex objects are,
>: >the more interesting they are. And in my opinion, that still is the
>: >goal of muds, provide an interesting environment; leave the memory
>: >management to the driver guys.
>:
>: I'd say that you're oversimplifying. Adding complexity simply for
>: complexity's sake doesn't necessarily make the mud (or anything else,
>: for that matter) better. It *can* make it better, but that's another
>: story.
>
>I was assuming reasonable coders who only add complexity if it makes the
>game better (for whatever better suits you). I didn't know you weren't
>such a coder. ;)
I was assuming a reasonable writer who tries to avoid making too
many assumptions about the audience. :-) Seriously, though, it
looks like we're in agreement about this--along with both thinking
that corpse containers are a reasonable way to go. :-)
>: As for memory management... depending on the kind of mud you're
>: using, this may *be* part of the driver. On an LP, it's probably
>: going to be part of the mudlib... the optimization of which is
>: also important if you want to have a mud with reasonable memory
>: usage.
>:
>: IMHO, this is like saying, "leave optimization to the compiler".
>: I can do that, but I've yet to see a compiler that can make a bubble
>: sort be faster than a shell sort.
>
>Yeah, but wouldn't it be great if we can just say 'sort', and let
>the compiler use heapsort? (Which beats bubble sort and Shellsort.
>(FYI: Shellsort needs to be capitalized, it's named after mister Shell))
It would be great... however, until someone invents the Psychic
Compiler, I'm still going to do some optimization of my own. :-)
After all, I may know things about the data to be sorted that the
compiler doesn't, such as whether it's likely to be nearly sorted
to begin with, which could guide me to pick a sort algorithm that
offers good performance in the common case.
>: I can accept that a combined program is more complex than its
>: component programs; however, how does that apply here? Are you
>: saying that corpses should be a completely separate type of object,
>: and not be derived from either monsters or containers? Or that
>: it's better to leave a monster there, rather than switch it with
>: a container? If the latter, note that you're not truly combining
>: the two... you're swapping one for the other. That swapping
>: does add some complexity, yes... but the ultimate result may
>: still be more efficient than leaving the monster there.
>
>I say that *if* you swap a corpse object for the container object,
>you end up with less complex code. You need of course somewhere
>some code to switch to objects, but for the rest you don't have to
>make a difference for being in "living mode" and "dead mode", if you
>understand what I mean. Sure, you might end up with more code, but
>more code doesn't always mean the code is more complex.
You may not necessarily end up with less complex code, however.
What if it turns out that the corpse needs all the functionality
that the basic container on your mud applies? If that's the case,
then you've just duplicated a lot of functionality pointlessly.
(I'm thinking of the code from the coder's point of view here;
from the driver's point of view, it's still more complex, since
connections have to be made between the corpse code and the
container code that it inherits.)
It can also reduce the learning curve; if a coder sees that the
corpse inherits container, and he/she already knows how containers
work, then that tells him/her a good bit about corpses. If the
corpse instead contains its own version of much of the container
code, then the coder is left to figure that out on his/her own.
One of the main points of setting up a mud in an object-oriented
fashion is that functionality can be inherited, instead of
duplicated. Since a corpse needs to do many things that
containers do, it makes sense to me to have corpses inherit
the container code. OTOH, monsters do many things that corpses
do... but they also do a lot more. Thus, it makes less sense
to me from a design standpoint to have corpses be monster objects.
Now, it may make more sense from an efficiency standpoint...
but that's dependent on what types of optimization are important
to you, and on how the mud you're working with works.
Orion Henry
>: [mobile or container for corpses?]
>Yes, but I very much doubt the gain is significant. Which mud has
>many corpses all lasting relatively long all the time? Since the
>lifespan of a corpse is short, and there are relatively few corpses
>compared to the number of monsters running lose, the gain is
>insignificant. I don't think corpses are bad - I just can't take
>the memory argument seriously.
Agreed on that count. I think the main hesitance of just "leaving"
a mob as a corpse rather than converting it to a container object is
the same hesitance as there is in removing exp, getting away from
AC, hitndam, classes, inventory, and every other D&D or Dikuism that
we're so used to that it's like second nature. "Don't fix what
ain't broke" seems to be most people's line of thought on this, but
in my opinion it's not broke, it just needs a serious tuneup. And
there is a point at which you have to just buy a whole new engine,
when the old one just won't keep up anymore. It doesn't mean we
don't like, or appreciate the old one - just that it's time to move
on.
>I say that *if* you swap a corpse object for the container object,
>you end up with less complex code. You need of course somewhere
>some code to switch to objects, but for the rest you don't have to
>make a difference for being in "living mode" and "dead mode", if you
>understand what I mean. Sure, you might end up with more code, but
>more code doesn't always mean the code is more complex.
Hmmm. I'm not sure I follow you here - more code pretty much
always means more complex. Although I suppose it depends what you
mean by "complex." I consider simple to always be better, when it
comes to programming. I'd rather see a simple, well-thought out,
straightfoward underlying system which is robust in all respects.
The "complexity" of the MUD emerges from the interaction of these
simple units; because of their robustness, they will perform as
expected in all situations and combinations, without having extra
code. Thus the _code_ itself is simple: the resulting MUD is
complex.
To get more specific, here's my argument on the corpse thing. I can
either code:
"awake" characters (regular mode)
unconscious characters (paralyzed, asleep, tied up, dead)
If I make both of these work, then when I go to code the paralyze
spell, the stone spell, code to tie people up with ropes or chains,
dead bodies, sleep (voluntarily and by a sleep spell), or a
thousand other things, all I have to do is put the body into
"unconscious mode" and be completely secure that it will behave as
expected - ie player won't be able to do any sort of physical
commands, people can just walk up and take pieces of equipment off
the character, when attacking the character you auto-hit, and so on.
Most MUD coders would rather code all of these seperately, which
makes you end up with a huge pile of code, most of it doing much the
same thing, and with gaping holes. On most muds you can cast hold
person (or an equivilent spell on someone), yet I go to steal
something or take a piece of their gear and it won't let me. Why
not? Because they haven't coded it. If you code it the way I
outlined above, you needn't _bother_ coding it - it's there from the
start, a part of being in "unconscious" mode.
One MUD I played (Tera) I would walk up to a human mob like Iuro,
cast paralyze on him, then attempt to kill him. Now, I was getting
like seven attacks a round, had a 30 damroll (pretty good for that
mud), tons of offensive spells, a big fucking axe (2d10+4+4), PLUS
being paralyzed made me do double damage against the mob. It still
took me like ten real-life minutes (at two seconds a combat round)
to kill him. I have trouble envisioning this: if a human is
paralyzed, shouldn't I just be able to walk up to him, pull off his
neck armor, and slit his throat?
>: To use an analogy, for me to drive to a ski resort, then put
>: on skis and use them to get around adds the complexity of
>: changing from one to the other... however, I think it's
>: definitely still better than trying to ski from Florida to
>: the nearest ski resort, or than trying to navigate ski slopes
>: in my car.
>
>Yes, and in my opinion it is *less* complex. Otherwise, while being
>in Florida, you continously have to check whether you wear skies
>or not.
>if (!wear_skies) {enter_highway ();}
>else {huff_and_puff (on_the_side_walk);}
>And while navigating the slopes, you are still checking.
>if (wear_skies) {make_sharp_turn ();}
>else {lose_grip ();
> crash ();}
Here lies the problem with most MUD coding. I realize this was just
a quick example, and a whimsical one at that. Still, I see this
sort of thing a lot. You should be doing:
perform_move(blah, blah, blah);
and
perform_turn(blah, blah, blah);
If you've coded your ski-wearing state and driving state well, this
will work in every situation. And, you can easily add the biking
state, the walking state, the flying state, and so on, without
having to change the code in a thousand places. Really a rather
fundamental part of programming any sort of large scale project,
_especially_ something like a MUD where there are always new things
being added.
Psychochild
There seems to be an issue of "realism", etc rearing it's ugly head
here.
Lemme put in my two cents.
I think "realistic" MUDs are boring and silly. Yes, there has to be
some kind of "reality" so that players can relate to the MUD, but making
things like encumberance in battle, etc too realistic makes it boring.
You have to have a bit of assumption. If I'm carrying a box full of
stuff, I'd probably drop it right at my feet to fight a monster.
If someone tried to pick up my box, they might get a swing/kick/spell
from me to stop that. However, on a MUD, there's no way to "put
something at your feet" so you can watch it. You just drop it in the
room. Hence, anyone can walk in and take your item.
Now, that's silly, yes? How can you "work around" this? Don't make
encumberance so ugly in battle. Allow for a little assumption. Assume
I'd drop the box at my feet, but allow me to keep it in my inventory.
That way, a thief could come and "steal it" from me when I was busy, but
someone untrained in the arts of stealth would have less luck. Really,
if I wanted to worry about how to do things when my hands are full, I'd
just stick here in real life.
I think a lot of designers go too far into the realm of "realistic" and
ignore the realm of "fun".
Just my ideas. Comments more than welcomed. I'm interested in some
discussion of this idea.
--
"And I now wait / to shake the hand of fate...." -"Defender", Manowar
Brian Green, pch...@iastate.edu aka Psychochild
|\ _,,,---,,_ *=* Morpheus, my kitten, says "Hi!" *=*
ZZzz /,`.-'`' -. ;-;;,_ "If you two are so evil, then why don't
|,4- ) )-,_..;\ ( `'-' you just...EAT THIS KITTEN!"
'---''(_/--' `-'\_) - "The Tick", Saturday morning cartoon.
Check out: http://www.public.iastate.edu/~pchild to find out more 'bout me!
Matthew R. Sheahan
Abigail (abi...@ny.fnx.com) wrote:
> I am more concerned with the other way around. I find it highly
> unrealistic that one can have drinks or a snack in combat.
we handle this via a centralized activity tracking system. doing much
anything has an activity cost, and if you stop to do all but very basic
actions in combat it's probably going to cost you your attacks for that
heartbeat.
chiaroscuro
Matthew R. Sheahan
Abigail (abi...@ny.fnx.com) wrote:
> I agree on the light. Another thing which always bothers me is timing.
> On most muds, a command takes as long as it needs you to type it (plus
> some net/driver delay); the faster you type, the more you can do.
> And it doesn't matter if it is blinking your eye, or climb a 100 metre
> rock. If you are fast (or use a client), you can have 5 drinks and
> 3 meals between swings in combat. *Yuck*
since this seems to particularly bother you, let me go into a little more
detail about the local solution used on Lost Souls (lostsouls.org 3000).
each heartbeat, a living has reset_activity() called. this allocates the
living an amount of activity based on their speed/haste level (the normal
speed level gives you 20, haste 1 = 40, slow 1 = 10, and so on), and clears
the flag which indicates whether they've incurred any activity cost yet
this heartbeat. for slowed characters, activity points can accumulate up
to a maximum of 20 over several heartbeats.
whenever someone wants an event to incur an activity cost, they use a
bit of code that looks like the following example for a "drink potion"
command:
if(!this_player()->check_activity(5, "drink potion"))
return 0;
check_activity() for the following failure conditions: less than 5
activity points available, living is stunned, living is held. (locally
implemented conditions.) a special condition applies to the first
check_activity() received after a reset_activity(): it is permitted
even if inadequate activity points are available. upon failure, it
sets notify_fail() to an appropriate message, and if the second argument
(command line, optional) was specified, adds the command to a queue
which gets processed each heartbeat and will attempt to perform the
command automatically, and returns 0. upon success it decrements the
activity available by the amount specified and returns 1.
performing a round of attacks in combat costs 18 activity points, so
an unhasted living can use 2 activity points while in battle without
losing its attacks. the actual presence of the 18 points is checked
for, so that the "first action" exception doesn't skew the behavior of
slowed characters in combat.
this also prevents instantaneous transcontinental walks, allows different
movement speeds to be implemented (flying is fast, walking is middling,
swimming is slow, hobbling or crawling when you're missing feet or legs
is very slow), and so on.
chiaroscuro
Douglas Kilpatrick
ga...@clark.net wrote:
> Say a container takes 1K memory, my modified version takes 2K, and
> a mobile takes 3K. The modified version will be the 1K object
> plus some additions, making it 2K, whereas the corpse would still
> be 3K, only with up to 1K of its code just sitting there, disabled.
Maybe other code bases don't do this, but in the Rom2.3 code I maintain,
the death of a mob does NOT remove it from memory. The mob structure
is placed on the "Free memory" list...of the program. The program still
ownes all that memory ...
No real memory savings are possible. Speed savings might be though.
Hawke (bohr.sos.clarkson.edu 9000)
-- kilp...@erols.com -----------+-------------------------------------------
ShadowHawke @ too many places | Brain, n.:
Doug in RL (or what passes here)| The apparatus with which we think that we
What?!? I _have_ an opinion??? | think. -Ambrose Bierce, Devil's Dictionary
Douglas Kilpatrick
atlas wrote:
>
> WARNING: the following message is geared toward implementation
> possibilities.
>
> Perhaps one way to do it is to make it so that when something/someone dies,
> instead of loading a generic corpse object in the room, load a generic
> mobile in the room which will act as the corpse.
Ug. I think it would be less work all in all to just make corpses "special"
containers. Eg, the wear_loc attribute on an object in a corpse still means
something. (functions to hack, one. Do_look)
> Then more or less
> add descriptions based on the character which died, modifiying them so
> that there is do doubt that the person on the ground is dead. Like:
> <description>
> The corpse of a giant is wearing:
>
> <around neck> gold chain
> <worn on body> hide vest
> <worn waist waist> huge leather belt
> <worn on legs> kilt
> Also you wouldn't see his huge club, because he would have dropped it on the
> ground when he died. (along with the stuff in his inventory.)
I like this idea....Easy to impliment, kinda cool. Gonna hafta do it.
> Okay, to make this dead corpse inanimate (seeing he is a mobile) just
> create a flag called ACT_IS_CORPSE and edit the code so that such mobiles
> just sit there, can't be attacked, won't attack, and will eventually decay.
Ugly. As the command structure of Diku/Rom code stands, you would have to
add a stupid check to EVERY function. This sorta of thing would force me to
re-write commands until they looked a lot like spells currently (Have a defined
target) Then again, I really should have started from scratch in C++ anyway.
If I delay long enough, maybe I'll learn Java...
> if ( check_corpse( ch, victim ) ) return;
> One of many places would be in the kill, backstab, murder, ect commands.
> /* end info */
Much easier to put a single check into is_safe();
if (check_corpse(ch, victim)) {
send_to_char("It's dead Jim.\n\r",ch);
return TRUE;
Orion Henry
>>> I have to agree; using a mobile seems to be a waste to me, since
>>> mobiles have large amounts of code and data which will be useless
>>> in this situation.
>>
>>Yes and no sure you should be able to see it's a helmet and maybe notice
>>the spike on top but until you take it from the corpse could you see the
>>inscription inside
>
>This depends on the level of object detail. It isn't difficult to flag
>certain text to show only when the item is IN_HAND and not when ON_CORPSE,
>should someone wish to use this more realistic approach. This does not
>speak to memory constraints, but with skillful writing (and perhaps a
>text-blocking routine to merge indirectly related text blocks into a
>single paragraph or blocked output so things don't look suspicious or
>inappropriately obvious), it is a rather simple coding procedure.
I can't think of a single thing about something being in my hand
that makes it easier for me to discern details about an item. If I
have no hands, does that mean I can't look at any extra descs?
*boggle*
>In fact, being able to examine items without having to manually manipulate
>them is an underused option. Especially if one is on a MUD which is
>liberal with goofy things like no-drop cursed items and such.
Certainly. Of course, my reaction when I first found out what
"cursed" items were (oh-so-long ago) was, "Er...that's stupid." My
opinion hasn't changed, and the advent of MUDs has actually
strengthened it. On MUDs you usually get rid of nodrop items by
quitting, reentering the game and getting everything but that item.
This is role-playing?
>>As far as objects go usually I know what is in my backp[ack if I l in back
>>I see the contents and I can take them out of backpack but if a potion is
>>in my backpack I need to take it out before i can drink it or else have a
>>really long straw.
>
>I'm not sure I follow this particular thought. Also, on at least one MUD
>I've visited, you could not even wear the backpack that you started with
>as a newbie. And on another, you could get and remove items from your
>backpack without even removing it - and PCs didn't have triple jointed
>arms or prehensile appendages to justify it. These are rather silly and
>simple to fix.
Er, I get and remove things from my backpack all the time without
removing it, and as near as I can tell my joints are pretty normal.
Perhaps you'd feel better if it were named "satchel"?
>Well, as noted in another message by Orion Henry, the entire concept of
>inventory is somewhat silly, but has been taken as a staple in virtually
>all MUDs. I believe it is a holdover from games like Zork and such.
Yep.
>Gemstone III which was (or maybe still is) run on the GEnie system was the
>first MUD I ever played, before I knew about free ones. It not only did
>not have an inventory system, but it also made use of a nice thing I call
>'real hands' - you grabbed coins in handfuls, for example. This was some
>five years ago now. It is NOT a question of difficulty or lack of
>concept, it is a situation of lack of motivation or perceived worth.
Definitely. Of course, Gemstone has the advantage of being coded by
paid, professional programmers with a real agenda and likely no
hang-ups about sticking to any particular conventions.
>As for the dropped torch/light - lighting conditions is one of the most
>universally sloppily handled things on MUDs. But that is really food for
>an entire thread.
Don't even get me started on this. Various light levels, _real_
infravision, scaning into dark rooms from lit rooms and vice versa,
and so on and so on.
One thing that has always bothered me is that lanterns/other light
sources only light the room when you're holding them. Is there some
reason I can't set them on the ground and have them light things, or
for that matter leave them in my inventory since my inventory are
"carried" items?
Another good change most dikus could make is to display only the
room name (but not the exits or the room desc) when your character
is in the dark. Even if I had my eyes surgically removed I can
still tell when I'm in a cave as opposed to a forest as opposed to
the open plains.
Orion Henry
>]: Like I said before, mobiles strike me as inherently larger and more
>]: complex objects than modified containers. Mobiles would have more
>]: attributes (hit points, alignment, equipment, etc.), not to mention
>]: chat functions, attack functions, and so on. Even if you set all
>]But the code for those functions is shared between all monsters
>]anyway. It doesn't really matter what the difference in complexity is.
>]Unless you have one monster, and only use the blueprint, the code
>]for the chat functions etc doesn't go away after desting the object.
>]All you do is save the memory for a few variables.
>
>Well, yes, that's true; most functions are shared. (I neglected
>to take that into account.) So you're right; all I save is the
>memory of variables. But I don't think it's "few". Some monsters
>have -tons- of data unique to themselves, which can't be shared;
>so-called NPCs are potential examples of this. They tend to have
>all sorts of features, from preferred weapons to a detailed chat
Hmmm. You mean to say that you normally store a seperate instance
of all this crap for _each_ mob, rather than having them all point
back to the mob prototype? If so I can tell you where you can get a
major memory savings right now.
As for things which are specific to each mob, like mob memory, this
would obviously be freed upon death, rather than extracting the
character completely from the world.
>function based on what people have said to it before. Of course,
>the ratio of such unique creatures' corpses to regular corpses is
>very small on the average, so this may not be too great a problem.
That, too.
>But even if it is only a few variables saved, it's better than
>nothing, right? Are you saying it's simply not worth the trouble
>to have corpses be close descendants of containers, because of
>the bit of shifting when a creature dies?
Listen to what you're saying here. How about if I phrase it this
way:
"Are you saying it's simply not worth the trouble to have apples be
close descendants of torque wrenches, simply because a bit of
shifting when the the apple gets eaten?"
Corpses are nothing like containers, which is my point in the first
place. They are dead characters - nothing less, and nothing more.
Why should container objects even come into this, aside from
MUD-based biases of having used this system for so long?
[code savings on mob vs. corpse]
>On the average, I'd say muds don't take up that much memory, either.
>Much of the time they could be supporting 3-5 players, and be
>relatively tiny. If memory is an issue, I think it makes sense to
>study it during peak hours, when there's around 50 players and a
>heckuva lot more corpses lying around.
Of course this stuff should always be tested in a real situation.
Still, I have an extremelly hard time imagining that this is going
to be an issue at all. Since corpses don't last for long, imagine
it this way: what if all the players killed the mobs they are going
to kill <corpse decay time> ticks later? I mean, by leaving the mob
how it is, you're just "extending" its life a couple of ticks. It's
not like you're adding a new mob.
>Furthermore, this isn't just about saving RAM; it's also about
>good design.
I'd phrase it the other way around. It's *everything* about good
design, with RAM limitations as a consideration. I can give you a
MUD that will run on a TSR-80 in 100 bytes of memory, but I don't
think you'd really want to play it.
>In my mind, a corpse resembles a container in function
>much, much more than it resembles a mobile;
Fuck, you are one SICK dude. :)
(Nothing personal, of course. Just sounds a tad on the morbid side
to me.)
Actually, I think this reflects your diku upbringings. Now, I'm one
to talk...I've likely played, at least briefly, just about every
diku MUD on the net. And no one knows the diku mindset better than
I, which is why I can understand the above statement about corpses,
absurd as it sounds to any non-MUD person. Let's cut right to the
chase: on diku MUDs, _mobiles_ resemble containers more than they do
characters. They hold gear we want, and it's just a matter of how
hard it is to "open" said container to get at the stuff we want. So
why not make all the mobiles just be containers with hitpoints and
damage dice, that wander?
>thus, corpses should
>be based on containers in the code. And having several instantiations
>of a class be 50-70% disabled, even if it only means 50 extra bytes
>of unused RAM per object, strikes me as really silly.
The 50 extra bytes is pretty irrelevant. The functionality of
corpses is everything. By leaving corpses as mobs, there are a
thousand things you can do. With the current code all you can do is
get it or get from it.
>If anything, I'd prefer mobiles to inherit corpses. It's somewhat
>humorous to regard people as dead bodies with "a little something
>extra"...
Inherit? What do you mean by that?
And I completely believe I am simply a corpse inhabited by life and
spirit and soul. I'd hardly call these things "a _little_ something
extra", but take away those things and all that's left is my body.
Aran Zontine
In article <4rkju8$3...@puzzle.palace.net>,
Matthew R. Sheahan <ch...@crystal.palace.net> wrote:
>Abigail (abi...@ny.fnx.com) wrote:
>> I agree on the light. Another thing which always bothers me is timing.
>> On most muds, a command takes as long as it needs you to type it (plus
>> some net/driver delay); the faster you type, the more you can do.
>> And it doesn't matter if it is blinking your eye, or climb a 100 metre
>> rock. If you are fast (or use a client), you can have 5 drinks and
>> 3 meals between swings in combat. *Yuck*
>
>since this seems to particularly bother you, let me go into a little more
>detail about the local solution used on Lost Souls (lostsouls.org 3000).
>
[ description of activity counters snipped ]
I used to play on Lost Souls before the change and I loved the mud. It's
small, things are close together, good quests and ideas. After the change
to the activity per heartbeat system though I left, it is a good idea but
I don't think it was implemented as well as it could have been. I'd head
out to go somewhere and type 12w2n (yeah I used tintin++ on an LP :) and
after 4 steps I'd get something that looked like this:
"You are not fast enough to do that many actions this quickly! Your command
has been added to the list."
Eight times too cause 8 extra commands went in, made for lots of spam and
I found it to be way more annoying than enriching.
Something I believe would have been a better way to implement the delay
is to have a small waitstate added on to each activity, obviously not a huge
amount but if you're making an 80 step trip you'll notice that you don't make
it there in 2.5 seconds anymore. LegendMUD has a tiny waitstate on movement,
enough so that you notice a slight pause, but not enough that it feels like
you're crawling. With the way the activity counters would add up after a
heartbeat it felt like I was playing through a lousy link because I'd run
5 steps, pause, run 3 more, pause, run 4 more pause, run 3 more, pause, etc.
> chiaroscuro
_____
Miles
Justin Conrad Dynda
In <4r9srd$e...@urvile.msus.edu> msu...@news.msus.edu (SOCIETY OF
PHYSICS) writes:
>
>Oh, I agree with your point entirely. I do feel, however, that when
>"realistic" features are implemented in a good manner, it adds a lot
>to the game.
>
>-Eric
>
>> Hmm, realism vs playability. It is quite simple. Realism should
NEVER
>> detract from fun or playability. If the player wants the problems
and
>> worries of real life, he would just log out, you have better
graphics
>> and sound in real life that you get with a mud.
>> X-Newsreader: TIN [version 1.2 PL2]
>>
>> There is one mud that tried to make his mud so realistic that he
would never have a successfull mud
>> if he payed people to play it. It was called Auterien Dynasty, aka
>> Newworld. Created by Owen Emlen (orin).
*COUGH* You probably mean Arturion Dynasty
>>
>> Basically the mud consisted of extremely long journeys, long periods
of
>> time where the player is expected to sit at his/her terminal and do
>> NOTHING, just wait.
*Boggle, I never experienced such things, or maybe your
exaggerating, sure you do have to sleep to regen. Wait, lets make a
mud where you never have to regen!!!
>>
>> First of all, the mud was extremely problematic for weight and
movement
>> points. For someone to have a full set of LIGHT gear on, they would
be
>> able to move like 10 rooms and then they would have to sleep. But
WAIT,
>> if it was cold out, you couldn't sleep without lots of wool gear on,
and
>> in the summer you couldn't sleep if you had lots of wool gear on.
As
>> for
>> gear, all the gear in the game consists of wool, leather, thin
metal,
>> and
>> thick metal, thats it, so the most interesting piece of gear in the
>> game is, well ok, there isn't one.
You forgot chain armor :P and it's more like 30 rooms with
light armor, unless your travelling in mountainous terrain. You see,
on that mud MVS were more important than AC, which was one of Owen's
intriguing concepts, my character could have probably moved 200x w/o
sleep. And whats wrong with having to have decent clothes on to sleep
in cold weather? Seems fine with me. Perhaps Owen should have put in
Mithril eq and other eq, but nothing like: Tooma's Diamond Scepter of
Might or crap like that, except for quest items.
Everyone has the same gear.
>>
>> During battle, all interesting commands are unusable, like you
cannot
>> see your score, or inventory or anything else. So you can just
watch
>> what is happening in battle, gee, how interesting. And players
cannot
>> ever tell what they are actually at anyhow, mana is powerful, hmm,
hp
>> is at bad, hmm, well who knows what the hell that means.
>>
During battle you obviously would not have time to check what
your status exactly was. You were Fine, Good, Hurt, Bad, Awful, or
dead. Also during battle lowlevel warriors didn't just bash, they
could flurry, tackle into groundfight, or flee. So you didn't have
time to do anything else but concentrate on battle if your going to
fight effectively.
>> You had to collect travel points in addition to experience points to
>> level, fear that, as travel points were randomly distributed to
rooms
>> throughout the mud, and you need thousands of them to get large
levels.
>>
>> It is commonplace to have -MaxInt exp to level, and every exp point
you
>> earn is wasted until you get your travel points needed to level.
Nice
>> huh. If the god seen anyone having fun with something, he quickly
took
>> it out. That also sounds like real life.
If you were smart, then you would know where to get tons of tps
(travel points). Well it's not even a secret. EXPLORE. If you don't
like not able being able to sit in one spot and just kill a mob for xp
go play some other Stock Diku mud. The travel point system wasn't
perfect, nothing is, but it was still quite an improvement.
>>
>> It seems that the god's goal on the mud was to see how many pissed
off
>> players would ACTUALLY stay.....laugh. Challenging? No just
stupid.
>> Sorry, we give the mud the thumbs down.
*We? who is we? Oh those wussy players that can't face
different challenges. Go play Jellybean Mud.
>>
>> BASICALLY MY ANSWER TO THE ARGUMENT -> REALISM SHOULD ONLY BE USED
WHEN
>> IT ENHANCES PLAY(ABILITY). GET
>> RID OF THE REST.
>>
>> Remember muds are for the players, used by the players, and judged
by
>> the players. Thus they should be coded by the players, and you'll
>> notice
>> that all good muds are.
>>
>>
>>
Nod players hated it so much there were at least 20 people on
most of the time. It did Enhance Play but i just wish PK was as
encouraged as before.
MogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMogMog
Mog the fat Cow-Moogle
>>
>
Eric Pilcher
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>Someone wrote:
>>Well, yes, that's true; most functions are shared. (I neglected
>>to take that into account.) So you're right; all I save is the
>>memory of variables. But I don't think it's "few". Some monsters
>>have -tons- of data unique to themselves, which can't be shared;
>>so-called NPCs are potential examples of this. They tend to have
>>all sorts of features, from preferred weapons to a detailed chat
On a DIKU, this unique data typically is listed in a bitvector.
I argue that setting all these bitvectors, such as the ACTION bit
(which includes flags for MEMORY, SPEC_PROC, WIMPY, etc.), to 0,
you effectively nullify all those sorts of feature from preferred
weapons to a detailed chat function.
>>In my mind, a corpse resembles a container in function
>>much, much more than it resembles a mobile;
>
>F***, you are one SICK dude. :)
>(Nothing personal, of course. Just sounds a tad on the morbid side
>to me.)
[ This poster had some good points, but at this point he switches debate
tactics to flamage and starts losing credibility. I agree with a lot
of what he said, but not this. ]
>Actually, I think this reflects your diku upbringings. Now, I'm one
>to talk...I've likely played, at least briefly, just about every
>diku MUD on the net. And no one knows the diku mindset better than
>I, which is why I can understand the above statement about corpses,
>absurd as it sounds to any non-MUD person. Let's cut right to the
>chase: on diku MUDs, _mobiles_ resemble containers more than they do
>characters. They hold gear we want, and it's just a matter of how
>hard it is to "open" said container to get at the stuff we want. So
>why not make all the mobiles just be containers with hitpoints and
>damage dice, that wander?
Please do not stereotype DIKU muds in this manner. Yes, I realize
that a lot of DIKUs out there are basically redundant hack and slashes
with little or no point or real atmosphere. I plan to do much much
better. I chose DIKU base code due to familiarity, mainly. But if I
felt that making something more progressive from it was a hopeless
cause, I obviously wouldn't be wasting my time.
--
------------------------------------------+-----------------------------
Eric L. Pilcher: ra...@PEAK.ORG | http://www.PEAK.ORG/~rasta
------------------------------------------+-----------------------------
oemlen
I'd like to defend my mud for a sec, since you probably came from a much
easier mud, or caught Aturion Dynasty in the early stages.
>> to make his mud so realistic that he would never have a successfull mud
>> if he payed people to play it. It was called Auterien Dynasty, aka
>> Newworld. Created by Owen Emlen (orin).
>>
>> Basically the mud consisted of extremely long journeys, long periods of
>> time where the player is expected to sit at his/her terminal and do
>> NOTHING, just wait.
First of all, the time you have to rest is very *short*. However, it may
seem long because instead of regenerating all of your hit points at a
'tick' point, every 50 seconds or so, you get an update every 8-10 seconds.
I've played or watched friends play Valhalla, MUME, and Thunderdome, and
I can truthfully say that their regen is about 5 times slower, and in
fact, Aturion Dynasty regen is one of the faster-regn'ing muds out there.
>> First of all, the mud was extremely problematic for weight and movement
>> points. For someone to have a full set of LIGHT gear on, they would be
>> able to move like 10 rooms and then they would have to sleep. But WAIT,
This is not true. First of all, you must have picked a weak character if
you had *any* problems wearing light gear. As for movement, you can move
over 60 squares... *but*, only about 25 if you truck straight through the
dense forest. I don't think anyone caught on, since they were so used to
just being able to go anywhere they wanted, not paying attention to the
road. For a good example where people *do* pay attention, visit MUME.
>> if it was cold out, you couldn't sleep without lots of wool gear on, and
>> in the summer you couldn't sleep if you had lots of wool gear on. As
This is incorrect as well. During the coldest winter days, you have to
find somewhere inside to sleep, or you have to load up on the wool
clothing. During the summer, if you are hot, you simply lose 1-2 extra
movement points, and even that can be remedied by taking off your shirt :)
>> gear, all the gear in the game consists of wool, leather, thin metal,
>> and
>> thick metal, thats it, so the most interesting piece of gear in the
>> game is, well ok, there isn't one. Everyone has the same gear.
Again, not true. You just have to realize that armor is rare. Ever got
an Aturion Hunting suit? Or actually worn a thin metal breastplate? You
just have to adjust to the fact that the armor may be rare, even if it
sounds like the crap armor on most other muds. It sure as hell isn't my
fault that you came from muds where you got 'Magical spirit armor
(glowing) (humming) (sanct)', or whatnot. :)
>> During battle, all interesting commands are unusable, like you cannot
>> see your score, or inventory or anything else. So you can just watch
Untrue again. Score was the only command not useable, and that has been
changed.
>> You had to collect travel points in addition to experience points to
>> level, fear that, as travel points were randomly distributed to rooms
>> throughout the mud, and you need thousands of them to get large levels.
Levels are extremely easy to get, and travel points slow down higher
levels (like MUME). You can gain 3 levels ahead of your current level
before you start not getting exp for kills.
Anyway, sounds like you've been playing valhalla or some stock mud where
you can get anywhere by walking 10 steps, and movement means nothing...
shrug. It wasn't too difficult, and it was being made less difficult at
the end (still is). Anyway, I have nothing against valhalla, btw... it's
a great mud, but just a bit different from the muds like MUME and
Thunderdome I played for so long.
Owen
Eric Pilcher
Abigail <abi...@ny.fnx.com> wrote:
>Yes, but I very much doubt the gain is significant. Which mud has
>many corpses all lasting relatively long all the time? Since the
>lifespan of a corpse is short, and there are relatively few corpses
>compared to the number of monsters running lose, the gain is
>insignificant. I don't think corpses are bad - I just can't take
>the memory argument seriously.
And, I just thought of something else which was previously unmentioned.
How many times has this happened to you?
You just finish killing a mob and start to loot the corpse.
The zone your are in "repops".
Suddenly, there is a living version of the mob you just killed
right there in the room with you and it's own corpse!
It might not happen much on an LP, but it happens all the time on Dikus.
A better zone reset function (or better building) can subvert this problem,
however, the code could have it's own failsafes.
Here's what has happened: (on a DIKU)
1. When the mob died, it was extracted and replaced with a container item.
2. The zone reset counter went off, bringing up the command line to
load the mobile.
3. The mud checked to see if the mobiles max_exist is less than the
number of that mobs in the game who share that vnum.
4. Finding this to be the case, the mob was reloaded.
Now... had the mob not been extracted, the mob would have still
been in the room, albiet dead. The mob would have been counted
during the max_exist check, and assuming you have good solid
building, not have repoped. A unique living mob would never
co-exist with it's own corpse during normal game play.
Naturally, this whole arguement is moot if you are loading large
ammounts of the same mob haphazzardly. Something which I
concider crappy building.
At any rate, the number of living mobs + corpses in the game
would never be more than the maximum number of living mobs in
the game. The way it is set up now, it is concievably possible
to have the maximum number of living mobs + some corpses. Which,
no matter how much memory was saved on each corpse, is still more
memory used NET, than what I suggest.
Raz
Maids milked, drummers drummed and lords leapt, when Orion Henry wrote:
> Don't even get me started on this. Various light levels, _real_
> infravision, scaning into dark rooms from lit rooms and vice versa,
> and so on and so on.
Aw dammit... and I actually hoped I was the only one who'd thought of
that... ;)
Well, this is gonna be in a least *one* new mud engine - oh, two, counting
yours! =)
Raz
Raz
Maids milked, drummers drummed and lords leapt, when Psychochild wrote:
> I think a lot of designers go too far into the realm of "realistic" and
> ignore the realm of "fun".
All too true - but the thing being discussed in here is an attempt to add
reality to a Mud *without* detrimenting playability and the 'fun factor'.
If this happens, then the design is wrong; simple as that =)
Raz
Lars Duening
In article <4ri9vb$l...@rodelo.cyberverse.com> gr...@hondo.cyberverse.com (Nick) writes:
[... something mostly unrelated...]
>As for the dropped torch/light - lighting conditions is one of the most
>universally sloppily handled things on MUDs. But that is really food for
>an entire thread.
Ok, I bite: what do you mean?
I ask because I implemented an advanced lighting scheme for Nightfall,
overcoming the shortcomings of the driver's lighting.
--
Lars Duening; due...@ibr.cs.tu-bs.de
Tim Hollebeek
Raz (r...@mushroom.demon.co.uk) wrote:
: Well, this is gonna be in a least *one* new mud engine - oh, two, counting
: yours! =)
Don't worry. Neither of them [*] will have an significant effect on
existing MUDs, since all the ideas expressed in the referenced posts
have obvious parallels in posts made over five years ago.
[*] Speaking probablistically, of course. Your MUD server may be
revolutionary and cause the basic assumptions of MUD server
development to be reconsidered. However, I doubt it.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
Nick
In article <83651470...@mushroom.demon.co.uk>,
Raz <r...@mushroom.demon.co.uk> wrote:
>Maids milked, drummers drummed and lords leapt, when Tim Hollebeek wrote:
>
> [from the transcript]
>> > wield sword
>> (Taking the sword from the stone first)
>> The sword slides easily out of the stone.
>> Taken.
>> You wield a sword.
>
>It would be nicer if a system could put its messages into proper english as
>much as possible. In the example above, the transcript could read:
>
> >wield sword
> You take the sword, which slides easily from the stone, and wield it.
>
>It doesn't jar as much, and helps maintain the illusion that you *are* your
>character, not merely typing on a keyboard somewhere =)
>
Good point, and it is something I tried to do whenever possible on the MUD
I coded at. It isn't always simplistic, but with a little work you can
merge all sorts of even possibly unrelated text blocks together to form
coherent paragraphs.
I think the general MUD output shorthand is just laziness, since it is
acceptable for the player to want to type shortcuts (commands skipping
certain propositions, for example), but the computer can easily spit out
full sentences without a lot of trouble - it just boils down to the effort
of the coder.
Now back to the topic at hand...
-Nick
Aran Zontine
In article <4rm4dm$e...@kira.peak.org>,
Eric Pilcher <ra...@kira.peak.org> wrote:
>
>And, I just thought of something else which was previously unmentioned.
>How many times has this happened to you?
>You just finish killing a mob and start to loot the corpse.
>The zone your are in "repops".
>Suddenly, there is a living version of the mob you just killed
>right there in the room with you and it's own corpse!
>
>It might not happen much on an LP, but it happens all the time on Dikus.
>A better zone reset function (or better building) can subvert this problem,
>however, the code could have it's own failsafes.
[ stuff about mob's corpse counting as a mob for repop purposes snipped ]
On Arctic most of the high power zones are all pop ifempty, which is a
real good idea for a number of reasons. First of all you won't have the
situation you described occuring. Second a group of pc's can't beat the
zone and then just sit at an end mob waiting for the zone to pop so they can
get the one item they wanted again. This way each time you get an item you
have to go through all the work again.
AnotherMUD(tm) on the otherhand, has some zones with repop timers as fast
as 15 minutes. Put this together with the scav2 flag (monsters loot gear from
any corpse and try to wear it, if they decide for any reason not to wear it
they might junk it, really a pain in the ass :) and a mob like the Stone
Warlord who explodes upon death doing around 400 or so to everything in the
room. Many times have I killed him only to have him repop within a minute.
Sometimes many pc's would have died and the corpse of the warlord would still
be there and he'd happily start looting it all and junking some of it.
>--
>------------------------------------------+-----------------------------
> Eric L. Pilcher: ra...@PEAK.ORG | http://www.PEAK.ORG/~rasta
>------------------------------------------+-----------------------------
_____
Miless
Nick
In article <Du2HB...@news2.new-york.net>, Abigail <abi...@ny.fnx.com> wrote:
>Nick (gr...@hondo.cyberverse.com) wrote:
>:
>: This depends on the level of object detail. It isn't difficult to flag
>: certain text to show only when the item is IN_HAND and not when ON_CORPSE,
>: should someone wish to use this more realistic approach. This does not
>: speak to memory constraints, but with skillful writing (and perhaps a
>: text-blocking routine to merge indirectly related text blocks into a
>: single paragraph or blocked output so things don't look suspicious or
>: inappropriately obvious), it is a rather simple coding procedure.
>
>It's usually already a troublesome process to come up with good
>descriptions; now you need 2 descriptions. And why stop at 2?
>A helmet surely looks different while being worn than carried.
A small misunderstanding worked its way in here. What I meant by blocking
various bits of text into one paragraph was that you could provide various
bits of info that can only be 'reached' by the player depending on certain
things.
For instance, you might have a general external description of the helmet
in question as your basic description, then have another sentence or few
regarding the inside of the helmet if it were useful. Then, when the
object is on the corpse, you would run a quick check when the description
is going to be shown, and block out the relevent (or irrelevant, in this
case) text. When the item is on the ground or in the hands of the PC,
then you would merge the two discrete blocks of text, format it into a
single paragraph so it looks natural, and show the whole block.
So...
> l at corpse's helmet
It has been fashioned from overlayed copper plates, each join held
together by small steel studs.
And when in hand or perhaps on the ground...
> l at helmet
It has been fashioned from overlayed copper plates, each join held
together by small steel studs. The inner lining is a brighter color
than the copper, a more golden shade, and bears various sigils
stamped directly into the metal.
Ok, so you would have the obj file entry something like...
<general external desc>
<some delimiter>
<flag group to indicate when the following text is to be shown>
<specific text>
<etc>
Of coures, this does call for the builder to work more deeply, but...
well...that's hardly a bad thing. And something like this example
wouldn't even be necessary for most things, only for specific
circumstances. It also tends to open up more options for the builder to
be sneaky and more imaginative.
>(In fact, if it's worn you can "examine" it and get a message
>how it feels, but only "look at" using a mirror).
Sure, it could be an optional bit that the builder can use if they choose
to.
And yes, you really shouldn't be able to examine your helmet while it's on
your head. Very minor, but also probably a one line code job, so why not?
:)
>And rooms should
>have different descriptions depending which direction you are facing.
Well, room descriptions can be written from a non-specific viewpoint if
care is taken to reference objects in a non-relative fashion. However,
here again, if it were an option for the builder, they could use it in
some cases to make things a bit more interesting.
Perhaps a room where if you enter from the north you can see a series of
spear tips just barely sticking out of the walls, obscured on the south
side by a stack of crates. Someone entering from the south wouldn't see
this (unless you allow them to search), and may well attempt to proceed
out through the north exit and get skewered. The person entering from the
north, assuming they notice the spears (perhaps high perception or a
search needed for anyone entering from the south, but only average
perception needed for someone entering from the north, to notice), would
then be able to try to disarm the trap or just avoid heading south.
Here again, it isn't required in most circumstances, but, when present and
when used, it can add another dimension to the playing experience.
>I agree on the light. Another thing which always bothers me is timing.
>On most muds, a command takes as long as it needs you to type it (plus
>some net/driver delay); the faster you type, the more you can do.
>And it doesn't matter if it is blinking your eye, or climb a 100 metre
>rock. If you are fast (or use a client), you can have 5 drinks and
>3 meals between swings in combat. *Yuck*
This has to be done carefully, because for every extra second a player has
to wait for something, it is perceived as a lifetime. I do agree,
however, that there should be some sense of time taken. In fact, I don't
even like the get all command on most MUDs, since you are allowed to make
sometimes thirty or forty 'moves' in an instant. If there were other
people (possible mob scavengers) there with you, they should be able to
snatch a few items from that corpse too.
Similarly, I've visited a test MUD that had built in delays when you
walked/ran/whatever...
> n
You begin moving north along the dock...
(couple seconds went by)
<room description here>
At first this seemed nifty enough, but I wonder about it when even I get
ansy about every little bit of net-lag. :) Perhaps the effect is less of
a problem when you expect it...I know I don't have too much trouble
waiting for a bash/kick port delay to go through. Shrug...dunno, I
haven't thought about it in a while.
-Nick