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

Brian Price blprice at bedford.net
Sun Aug 31 21:52:06 New Zealand Standard Time 1997

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

```