[MUD-Dev] Re: Room descriptions

[Travis S. Casey]

On Wed, 30 Sep 1998, S. Patrick Gallaty wrote:

> The basic failure of simulations is that the player will generally interact
> with only the superficial.  So you have 100% effort going into only the 15% 
> that the player sees.  That's not a great payoff unless you are culling some
> experimental data from the great experiment.

Of course, that depends on what you decide to simulate, and to what
extent.  For example, for monster generation, you could decide to simulate
things in a concrete way:

 Monsters wander around.  When two monsters meet, we check to see if
 they're of the same species and the opposite sex.  If they are, there's a
 chance that they will mate.  If they do, there's a chance that offspring
 will be produced, and there's a length of time before the offspring is
 born, and another length of time before it grows up.  During those times
 we make the mother pregnant, then make the baby monsters live in the
 lair while the mother (and possibly the father and other monsters as
 well, depending on the type) bring them back food.

Or, you could simulate it in a more abstract way:

 We keep track of monster species populations for different areas.  When a 
 species' mating season arrives, we figure out the population density of
 that species in the area, then use that to decide who many pregnancies 
 there will be.  We keep track of monster attrition for the gestational
 period, then create an adjusted number of baby monsters -- that is, we 
 record their existence.  They're only created when needed (when someone
 enters a lair).  Each year, we also advance a certain percentage of the
 baby monsters to adult status.

Now, the second method loses a good bit of realism that the first
simulation has, but it provides a reasonable model which can create ups
and downs in the monster population.  The second method is probably easier
to establish, since we don't have to program such things as bringing back
food to the baby monsters, pregnant monsters, etc., and because it's
generally easier to program a series of formulas than to establish actual
behaviors.

The first will probably require more resources when running, since
individual monsters have to be modeled.  In return, it allows more for the
vagaries of chance.

Both of these are simulations -- one's just more detailed than the other.
IMHO, the trick in simulating things is to decide where to stop:  don't
spend too much time on the background things.

> What benefit is massive simulation if we can shorthand all that with clever
> emulation?  The player can't see the man behind the curtains in either
> case.

Perhaps your "clever emulation" is the kind of simulation that I'm talking
about in the second example... IMHO, though, it's still a simulation, just
a more abstract one.