[MUD-Dev] Random plotlines

clawrenc at cup.hp.com clawrenc at cup.hp.com
Mon May 12 09:45:38 CEST 1997


In <199705101528.KAA18601 at dfw-ix1.ix.netcom.com>, on 05/10/97 
   at 12:39 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said: >
From: clawrenc at cup.hp.com
>> In <Pine.SOL.3.95.970507222009.27044A-100000 at sun-cc203>, on 05/07/97 
>>    at 08:22 PM, Ling <K.L.Lo-94 at student.lut.ac.uk> said:
>> 
>> >Anyone considering implementing pseudo-random plotlines in their mud?
>> 
>> Yup, tho not exactly as random plots, but by implementing systems
>> which generate plots as side-effects of their normal operation.

>I'd never been very impressed with direct random generation as a
>means to generate quests/plotlines.

>I  have the entire collection of "Sim" games and find them quite
>fascinating.  While changes at the micro level have effects that can 
>be easily determinable, the changes on the macro level are much less
>readily perceived (for the average human that is ).

Yup, especially as many of the balances in the Sim games are actively
unstable if not positive feed-back loops.  It makes for a continual
battle just to try and keep the register at the desired level.

I like this sort of instability for my (I dunno what to call them)
"active systems"(?).  In the orc/cave/breeder/drone/fighter/etc case
the system is geared to being actively unstable so that the
populations positive feedback into huge explosions that have the Orcs
marauding about the landscape in huge armies and dieing like flies
(remember, all objects have a limited life, so Orcs die of old age),
followed by all the Orcs dissappearing as the population dies and only
the breeders are left producing the next great wave. Lemming-like they
boom-crash while allowing players to interced to accellerate the cycle
or try and intercept the king making process to become king themselves
and thereby guide the cycle to being slower or faster, or
concentrating more on setting up new Orc warrens etc.

>I have no idea how easily programmable these simulations are.  I have
>my suspicions that they are not that complicated for each machine.
>What really impresses me is the level of game balance that is
>achieved with net sum of the hundreds of these machines changing the
>state of the system.  

Having written a few of the old text versions of these games (and dug
thru the source of other's games in the genre), the main trick is to
make the "desired state" unstable.  Don't make it unobtainable, but
make it a moving target.  Simple examples are to move the point of
inflexion as other variables change (eg population).  Thus the player
is constantly tweaking trying to keep on the sweet spot as the system
develops.  Another trick is to make the inflexion point a null spot
(ie once there it will tend to stay there if nothing else changes),
but to then make the various components of the inflexion turn into
feedback loops as soon as they leave the sweet spot.

>> What I like to try and do is to come up with a system which is self
>> animating, and inherently non-deterministic, but which also allows
>> players to interject themselves into to attempt to modify the
>> operation.  The classic case which I've posted on here before is that
>> of the Orc breeders/fighters/nobles/king etc.  Unfortunately I don't
>> seem to have a good copy of it to cut'n'paste in here, so here goes
>> from rough memory:
>> 

>The orc/warrior  scenario reminds me very much of the plot of the
>red/black scenario in SimAnt.

Excellant!  (I'll have to have a look at that game some time)

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list