[MUD-Dev] Hard Sci-fi muds was Character evolution

[Brandon J. Rickman]

On Tue, 16 Sep 1997, Nathan Yospe <yospe at hawaii.edu> wrote:
>On Mon, 15 Sep 1997, Brandon J. Rickman wrote:
>:[blah blah blah]
>
>I've been playing with the same, and trying to find ways to compress things.
>I figure a pile of junk is a pile of junk. If its all bones, the compression
>schemes have no problem. Or all gems or treasure or armor. It can find enough
>common, and the placement of components is unimportant. But, say there is a
>pile of random stuff from a player's home that was dragged out by a thief.
>How to represent this (or even in the home, to tell the truth?) in such a way
>that sentimental objects don't get denatured, without exhausting resources?

This is the gray area between a truly persistent world and an approximated
world which provides the illusion of persistence.  A pile of random stuff
stolen from a player's home is full of important objects that shouldn't be
forgotten and will continue to take up resources in the known future.  The
trick is to figure out when we can safely convert this not-so-random pile
of junk into a non-persistent-and-just-a-little-random pile of junk.

If someone were to nuke the entire neighborhood (in an attempt to kill all
the peace-loving non-pkers that lived there) this would be a good time to
junk the junk.  Destruction is a good way to defeat persistence.

If the thief steals from several houses and disposes of the items you
can junk most of the junk.  Because no one will ever be able to determine
what happened to each individual item.  Even an item of sentimental value
can (and should) be lost.  Large scale actions (collecting hundreds of
similar objects) help to defeat persistence.  Mass destruction is a
large scale action.

But if the thief makes a pile of junk and someone continues to pay
attention to it then the objects should stay intact.  This may lead to
bloating, but the objects causing the bloating are the very things that
the players of the game are interested in.  And if your players (entities,
whatever) are concentrating on a very specific set of things, they must
not be paying much attention to the rest of the world, so you might as well
scrap it/compress it.  Because no one will ever notice.

I'm trying to do some tricky things with this.  Say, for example, there
was once a famous hero named Argh.  Argh had a +1/+1 magic sword.  Argh
was killed in a duel by an evil knight who took the sword.  The evil knight
was eventually destroyed by a daring hero who reclaimed the sword, etc.
Eventually the sword was lost (due to a player purge).  Now if someone
were to go on a quest for the lost Sword of Argh they would never find it,
because it is no longer persistent in the game world.  But since the game
doesn't know where the Sword is, it doesn't _care_ where the Sword is.
Wherever a hero looks, there is a slim chance that it might just be there.
One day, Bubba comes across a rusty sword while walking through the swamp.
By golly, it must be the Sword of Argh!

So we could have tracked the Sword even through the player purge, and we
could have left it in the swamp for Bubba to eventually discover.  But
we didn't, it was just an illusion.

(There was no real need for me to justify how the sword was lost in
the first place, as such a thing could also be an illusion.)

In my opinion, accurate persistence is only useful for continuity between
the near future and near past.  On a larger scale, persistence becomes a
technical problem and is decreasingly useful (a subjective opinion).

>I
>have thought a lot about allowing the client to remember the details of such
>as this, and simply compare it with the regeneration of the compressed data,
>such that (like a jpeg scheme, notice?) the compression of the client's data
>_matches_ the current. If the compression matches, we let the client's
>version become instantiated and forget the regenerated version...

The current state of client tech is quite vulnerable to duping and the
like (yes, even with all the big encryption keys).  You can only trust
clients with pointless details.  But you could make a very nice and
robust system with this.

>:Happy Forestland
>:You stand in a clearing in the middle of Happy Forestland.  The sun is
>:shining on the happy green trees.
>:Your movement is slightly hampered by the rotting corpses of several
>:thousand dead bunnies.
>:A fluffy bunny is here.
>
>Yuck. I like it. Of course, it would help if you had a complete ecology with
>no bunny resets, and if bunnies ran away when they saw you coming...

I intentionally avoided talking about resets and ecology.  Having
an ecology assumes a specific case, I'm after something more general.

>And the intent... the rest of this doesn't interest me much, as I have
>already concluded that resources must be maintained and redistributed
>according to events... the bunny bones would be there, no question... but
>the bunnies themselves would not, unless they had learned to run.

Fortunately machines have gotten faster and cheaper so projects can afford
to keep track of lots of event-controlled details.  I haven't seen many
interesting results from this approach, but I'm keeping an open mind.

- 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