[MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)

Ling K.L.Lo-94 at student.lboro.ac.uk
Thu Feb 19 16:47:41 CET 1998


On Wed, 18 Feb 1998 coder at ibm.net wrote:
> On 16/02/98 at 02:25 PM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray)
> said: >[Chris L:]
> 
> >:Why not hand-design the gross features of the world, its basic terrain,
> >:resources characteristics, etc, and _then_ define the rules which govern
> >:the use of those resources.  Plug it in, flick the switch, bake at 400 for
> >:an hour and Voila!  Instant world of 12 million rooms (if you're still
> >:using rooms).	Want cheaper, easier, more interesting?  Do allt he same
> >:definition work, but skipp the baking step,  Just load the raw dough onto
> >:your servers and throw your players in like yeasty raisins.  As soon as a
> >:player opens his virtual eyes, the world creates itself about him.  The
> >:question of the tree falling in the woods is finally answered: with nobody
> >:there, there is no tree, there are no woods, and there are no ears to
> >:hear.
> 
> A key point in the design would be the level at which generation and
> prediction takes place.  If your world is constantly torn down as players
> move out of areas, and then rebuilt when they move back in, something has
> to do the predictive work to regenerate the new world.  Given the fact
> that such probabilistic systems tend also to be complex systmes (made of
> simple parts, very complex behaviours) especially over time, its very
> encouraging to keep the majority of the world static and only make the
> details dynamic.

I took a shot at this some time ago, nothing came out of it apart from
several pages of semi-interesting notes.

I wanted to create fractual cities and let the player meander wherever he
likes within.  This wasn't a problem in itself, recreating a static city
is easy enough but I introduced a time element so the player returning
years later would find it sufficiently grown/changed but not rebuilt from
scratch.  My solution went something like:  generate the city normally
then use pseudorandom numbers to extend/grow the city X years.  This seems
okay, if there was a depression period, it could all be incorporated into
the growth algorithm.  Even wars could be accounted for.

My major downfall at the time was being a wee bit too ambitious.  It was
for an Elite-type game and I wanted information like passenger lists for
airlines to be pseudorandom as well, the player could scan the passenger
list for the past year and a half and obtain a list of all regular
passengers.  The big wall I hit upon was tying in conflicting information.
My case scenario was to allow a player to stalk an npc all the way home,
the system should not show silly inconsistancies.  Npcs were characters
generated from a seed, this seed specified for the character to live at a
particular place, that particular place could turn out to be a bit of
road.

Ideally, the system would work vaguely as follows (all on demand):  npc is
generated, found a place to work.  Npc is tied to a home, home should also
point back to npc.  Home should generate an entire family.  Npc has
regular patterns.  I've lost myself, you get the general idea, it gets all
horrid and complex and ugly.

Imagine something like Ultima with all the world and npcs generated as
above on a low-mid range Amiga. :)  Doomed from the start.

  |    Ling Lo of Remora (Top Banana)
_O_O_  Elec Eng Dept, Loughborough University, UK.     kllo at iee.org




More information about the mud-dev-archive mailing list