[MUD-Dev] Something complete different

Brandon J. Rickman ashes at pc4.zennet.com
Thu Sep 18 15:34:28 CEST 1997


On Wed, 17 Sep 1997 Marian Griffith <gryphon at iaehv.nl> wrote:
>On Tue 16 Sep, Brandon J. Rickman wrote:
>I would hazard that in any situation remotely resembling reality a corpse
>would not stay around very long. Scanvengers would soon finish the bigger
>parts of it,  then worms and insects  would remove the remaining  eadible
>stuff.  By that time things are already so small that they are subject to
>being moved around by small animals  and even by wind.  Unless the corpse
>was very large, e.g. human sized or bigger, it is unrecognisable within a
>matter of days.
>Another problem here is,  of course,  where all those fluffy bunnies come
>from. They ought to be either extinct, or evolve into killer bunnies that
>hunt newbie characters.
 
I really shouldn't have used corpses as a test case, but while I'm
already off the thread:

A newbie area is almost always some specially protected area where larger
predators (carnivores, big monsters) are not allowed, and they
generally encourage overpopulation (so there is something for newbies to
kill).  Given the typically wholesale slaughter that takes place in
most newbie areas, there should in fact be *lots* of uneaten and
unscavenged corpses lying around, because the scavengers are well fed!
But to make the claim that newbie areas are "unnatural" is hardly worth
saying.

Situations resembling reality: scavengers are certainly not the solution
for _every_ situation.  Corpses would freeze in the arctic.  They would
rot very slowly in an attic.  Or they might become Undead and seek 
revenge.  Reality?  Bah!

>> While this would make a mud quite novel it probably wouldn't be too
>> appealing to a large number of players, and the type of mud where such
>> a situation would be most likely to actually occur would probably 
>> want to have more than a few players.
>
>Truth be told is that the vast majority of players has descriptions set
>to brief and won't notice the room full of corpses anyway.

Ah, one point I was trying to make was that, in many situations, the
players _don't_ care about the details, so you might as well fake them.

>> So should we dismiss corpses as being relatively uninteresting details
>> (aside from special corpse-related activities (hey!) like looting and
>> sac'ing)?  I guess it depends on the situation.
>
>There is use for corpses if it is going to act as 1) food source for
>(invisible) scavengers   and 2) as a gruesome kind of fertiliser for
>the soil.
>After a war the population of crows and vultures ought to prosper :)
>and grass should grow more abundantly on the former battlefield.

People sure do like grass on this list.

>> (Somehow I have gotten obsessed with the specific case of corpses as
>> opposed to the more general case of decaying the effects of players 
>> upon the world.  But perhaps the answer is hidden in the details?)
>
>Things decay unless repaired. Living creatures repair themselves
>continuously until they stop being living.  Metals and rocks are
>very resilient against decay so they stay around longer. Nothing
>mysterious about it in my opinion. Of course I am not the person
>who has to code this :)

I might not have made a clear enough distinction between /objects/
that decay and /details/ that decay.  Decaying details means
finding a way to reduce a large or varied amount of
seemingly useless information about the
universe.  But these details may eventually be of use, such as the
way rotting corpses have an effect on the local enviroment, cause weird
smells, etc.  Instead of corpses, think about pools of ichor.  How can
you pretend the ichor is there when the ichor is gone?

>[snip]
>
>??? Does this mean something or can I safely ignore it?

Only relative to the rather esoteric subject I was trying to discuss.  
Be thankful I avoid reading (or understanding) postmodern philosophy.

- Brandon Rickman - ashes at zennet.com -
While I have never previously found a need for a .sig, this
may be considered one for the purposes of this list




More information about the mud-dev-archive mailing list