[MUD-Dev] MUD universe

clawrenc at cup.hp.com clawrenc at cup.hp.com
Fri Sep 5 17:18:53 CEST 1997


In <199709042256.AAA11535 at xs1.simplex.nl>, on 09/04/97 
   at 09:40 PM, "Felix A. Croes" <felix at xs1.simplex.nl> said:

>clawrenc at cup.hp.com wrote:

>> Not quite.  You can also have quests created by systems, which create
>> a desired state where the purpose of the quest is to restore a state. 
>> The key is to make the incidental specifics of the state indeterminate
>> (who kidnapped, where held, why, what obstacles need to be overcome,
>> etc), and only have the defining points predictable (ie princess is
>> missing, get her back).
>>
>> The kidnapped princess scenario as discussed here a few months ago was
>> a good case in point.  There any of a dozen different compeating,
>> cross-affecting and unpredictable systems could result in the princess
>> being kidnapped.  The same systmes continued after the kidnap to
>> shuffle the princess about and change her
>> what-needs-to-be-done-to-recover state frequently and unpredictably. 
>> The princess could wander away from her kidnappers, get lostm be lost,
>> be multiply kidnapped (from other kidnappers), never get kidnapped in
>> the first place but just be wandering, etc.  

>Apologies if I am repeating obvious conclusions: the system would
>have to be <very> dynamic to avoid visible repetitiveness to a
>player.  If the princess is first kidnapped by red-headed orcs, and
>in the next quest the prince is kidnapped by blue-elbowed trolls, it
>won't take users long to discern a pattern, even if the individual
>components do not reappear.

No.  You need to think of side-effects, and non-linear routes to
desired states.  Consider:

  The princess is prone to wandering.

  The Orcs have periodic population explosions (see 
    breeder/fighter/noble model scenario).

  Population explosions result in various Orish warrens being 
    established.

  Wandering parties of Orcs tend to be attracted to buildings.

  Should an Orc find the Princess she will be taken prisoner 
    and conveyed back to Orcish HQ.

  Parties of Orcs from different warrens will fight to the death 
    on meeting.

  Players have no way to distinguish between Orcs of different 
    warrens.

  Players have no way to locate the Princess directly (eg they 
    can't do a "She's in that direction,", or "She's in the 
    warrens by the Gilcurdle mountains.")

  There is a chance the Princess will wonder off in such a fight.

  Every time the princess has been captured, and remains captured 
    for some trigger length of time, a new quest has been created.

  Add various other Orc-killing or Orc-interfering species who 
    collect Princesses as a side effect of their normal operation.
    eg Shapeshifers who use a different (from the Orcs) resource 
    based periodic population explosion model, and who collect 
    Princesses as a side-effect of their other normal operations.
    You can then have the ShapeShifters then all clone the Princess 
    and wander off with a hope to successfully infiltrating the
Princess'
    home town/castle.

Yes, you know that the Princess has been captured.  No, you don't know
where (which warren) she has been taken to.  You don't know if she has
even readhed a warren yet, or if she has wandered off from her captors
and is not ranging the countryside.  You also don't know if any one of
the Princesses you meet really is the Princess, or a shapeshifter.

>I have the same problem with automatically generated room
>descriptions: they tend to look so...  automatically generated.

Sure, in essence it is repetitive, but add enough systems which affect
the state of the key object as a side effect of their normal operation
and the total set of possible states can quickly get extremely high.

--
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