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

[Brian Price]

Hopefully this spin-off thread will continue so I've renamed it to 
avoid stepping on the ongoing Character evolution thread.  It is 
a discussion of problems inherent in the design of a hard sci-fi mud, 
this post deals with the problems of game universe complexity.

> Date:          Sun, 31 Aug 1997 16:16:13 PST8PDT
> From:          Jeff Kesselman <jeffk at tenetwork.com>
> At 04:06 PM 8/31/97 PST8PDT, Brian peirce wrote:

Note: Choice C is unrestricted pc interstellar travel via starship.

> >Choice C seems at first to merely be a design problem, but assuming 
> >you solve the design problem of generating 'realistic' worlds/systems 
> >randomly, you now have a storage problem...  your universe file will 
> >become _HUGE_.
> 
> This seems liek a classic pseudo random "virtual room" problem as we've
> discussed many times.  If your world is egenrated off of a pseudo rando
> mseeded from, say, the interstelalr "coords" of the world then it doesnt
> ahve to be stored, it can be recreated at any time. Instead justs tore the
> lcoatiosn of moveable obejcts dropped on or mvoed aroudn that world.
 
Assuming that the entire (for lack of a better word) section was 
generated at the same time and the random generator was unique to the 
generating thread, yes the storage of the seed or starting state of 
the generator along with the set of player affected objects in the 
section would suffice.   However  I fear  that we are merely applying a 
constant divisor to a problem that has no upper bound.   Assume x is 
the average number of players on the mud over a unit of time, each of 
these players will explore y new areas in that same time.   For the unit of 
time under consideration we have x*y new areas generated.   Our number 
of areas is then expressed as the x*y*t.  Over the lifetime of a good mud, 
this figure could grow quite large.  Any divisor must indeed be very 
large to have a significant impact.

In a fantasy mud, we might expect (or even force) y to diminish over 
time as the total x*y*t grows larger.  However, with a hard sci-fi mud, 
this reduction of y occurs much more slowly due to the spherical area 
nature of 3d space.  The observable set of stars contained in an area 
of radius r2 vs r1 increases by a factor dependant on r2-cubed - r1-cubed.  
Given pc starships and even a very restrictive ftl model, players could 
quickly depart known space (generated areas) and force generation of 
new areas even after hundreds of star systems have already been 
created.

We have a huge difference in scale between a fantasy and a 
sci-fi setting.  Each star system potentially has up to a hundred or 
more worlds or world-like bodies (moons, large planetoids, etc.) and 
a single world could easily encompass as many areas as an entire 
fantasy mud.  A single star system could easily have hundreds of 
thousands of 'rooms'.  This rapidly gets out of hand, especially with 
choice C above.   Even assuming we somehow managed to compress 
each room to a single byte, we would run out of storage space on any 
realistic server before the first month  of play was complete.

In fact, as I study the problem further, I think that even choice B 
(limited interstellar transport due to a plot device such as 
wormholes/jumpgates)  would need some type of pseudo-random area 
generation in order to be implementable.   Without some sort of computer 
aided auto-room generation, Choice A (no interstellar and limited, if any, 
interplanetary travel) seems the only practical hard sci-fi mud approach.  
Using conventional area design techniques, designing a full set of areas 
for such a mud would be an equivalent task to designing a full set of areas 
for a fantasy mud.    

One approach that may make Choice B practical, would be to create a 
number of building blocks composed of human designed areas together 
with a set of rules as to where they could be used and how they could 
be assembled given the set of 'facts' (design parameters) for the section 
being generated.  After the set of building blocks was designed, a program 
could generate the sections and then the designer could walk thru and 
'tweak' the area.   The section would then be represented in storage by 
its co-ords, seed value, its design parameters, a set of manual changes, 
and the set of player influenced data.  

I may be missing something simple here that would reduce the order of 
magnitude of implementation complexity.  Perhaps there is a logical 
plot device that would restrict a player from examining asteroid 
BX179 in detail (allowing BX179 to be realistically represented as a 
single room perhaps).  To me though, it seems rather drab to land on 
an asteroid and be told you see a barren asteroid, the only exit is 
back to your spacecraft.  Even worse:  you land on the asteroid 
belt(???).

Brian Price aka Delver <blprice at bedford.net>