[MUD-Dev] Hard Sci-fi Muds was Character Evolution

Brian Price blprice at bedford.net
Mon Sep 1 19:50:08 New Zealand Standard Time 1997


> Date:          Mon, 1 Sep 1997 14:43:11 PST8PDT
> From:          Adam Wiggins <nightfall at user2.inficad.com>
<snip suspension of disbelief discussion>

> Depends on what your 'hard science' actually is.  You could easily have

I'll try to the definition of the genre (hard sci-fi) as defined in 
literature, doubt I'll do a great job though:   Hard science fiction 
uses an absolute minimum of plot devices which are either against or 
completely untouched by current theory.  A great example of a pure 
hard sci-fi work is Charles Pellegrino's Flying to Valhalla, all 
technology used in that book is a direct extrapolation of current 
theory.  Larry Niven is an author who's works are oft referred to as 
hard sci-fi, I would say that his works are hard sci-fi but he 
definately skirts the edge.   GDW's Traveller rpg (esp add-on works) 
is another example of hard sci-fi, only two or three plot devices are 
postulated which are totally untouched by current research, and the 
postulated 'theory' behind those plot devices are at least not 
totally disproven by current knowledge.

To the best of my knowledge, there has never been a hard sci-fi 
TV series except perhaps Babylon 5..  There have been a few movies 
which qualify although Star Wars is _definately_ not one of them.  Soft 
sci-fi makes liberal use of pseudo-technologies which have no basis in 
current research.  Although I enjoy Star Trek and its offsprings immensely, 
it definately represents the soft sci-fi genre.  The line between the 
two types of sci-fi is not a rigid one and is mostly characterized by 
an attempt to actively minimize the use of unknown tech plot devices 
and a general prohibition against violating known physics in hard sci-fi.

> interplanetary travel without any sort of vessels - ie, some sort of
> farcaster portals (ala Dan Simmons' Hyperion) which were granted by some
> more advanced species.
> I assume you mean the typical Star Wars/Star Trek/whatever sci-fi where
> anyone who can get their hands on a small ship with a FTL drive can go
> just about anywhere.

Actually I find myself more drawn to the jump gate style of 
hyperspace ftl model.  Only very large (and very expensive) vessels 
would be capable of hyper-transition unaided, ala Babylon 5.  This 
model provides ftl travel at two widely seperated economic levels, 
the first allows anyone who can get there hands on a interplanetary 
vessel and afford the gate charges could travel throughout the 
jumpgate network.  

> > Perhaps 25 is too large a number for a workable hard sci-fi approach. 
> > This line of inquiry begets a number of questions:
> > 1.  How many zones/rooms would be required to model a habitable 
> > world?
 
> This goes back to the landscape-generation stuff we always talk about, which
> is useful for any kind of mud with landscapes in it.  Thus you could potentially
> model as many worlds as you want by simply painting landscape maps for them
> with a paint program.  If this is too tedious for you, there are tons of
> great fractal landscape generators that can give you endless random landscapes
> of varying terrains.

I'm going to attempt to stay text oriented but fractal patterns may
have a place.   I may end up using a seperate subsystem for terrain 
mapping in a grid layout using a set of clonable rooms to represent 
the terrain.  Do you know of any fractal landscape generators out 
there available in source code form?

> > 2.  How many rooms to model an orbital habitat or station?
> 
> This is more like a normal sized area - like 100 or so is probably good
> enough.  Of course, I would tend to think that in a mud like this you'd
> be moving away from hand-crafted zones and instead start creating lots of
> generic objects.  Ie, you create a space station object which contains around
> 100 rooms, only 10 or so of which were created custom for that space station.
> Then you can make many of these space station objects - they are different
> because of the people that inhabit them, the stuff that is in them, etc.

Yes, I think only some of the main areas will actually be done fully 
by hand.  Others will likely be assembled from pre-built modules.  
Exactly how to do this without making all zones look the same is 
still a question though.

> > 3.  How many zones/rooms to model an uninhabitable world  with and 
> > with out colonies (such as a future Mars)?
> 
> Here it's easy to put limitations - you smack into the edge of the domed
> city.  Of course, then if you allow space suits and exploration outside the
> city, you revert to your fractal landscape, with possibly a few alien artifacts
> or ancient ruins thrown in to make things a tad more interesting.

Functionally a domed city and a habitat would be equivalent.  
Features such as ruins would likely be another example of a hand 
designed area.
 
> > 4.  How many zones/rooms to model a gas giant with its moons?
> > 5.  How to represent an asteroid belt?
> 
> Rooms would suck for modeling these, IMO.  Here's where you'd *really*
> want to go to a coordinate/object based system.

Perhaps a mixture of the two, objects large enough (and friendly 
enough) to land on would have a room representation, the others would 
not.  Thus a facility on Io could be modeled while still representing 
a gas giant as a single non-landable(?) object.
 
> > 6.  How many of the above features can minimally represent a star 
> > system (assuming pc inter-planetary travel)?
> 
> You randomly generate as many star systems as you like.  Each system generates
> a number of planets from 0 to (say) 10, based on the attributes of the star.
> Each of these planets is given attributes (size, age, terrain, clime) based
> on the attributes of the star and the distance from the star.

Yep, there's an excellent system in the Traveller rpg series, 
detailed in the book Scout.  I'd think a derivative system would 
work.
 
> At this point you have the choice whether you want your races hand-crafted
> or not.  You may want to create a bunch of interesting alien races, then
> have the generator (or possibly yourself, if you don't mind some busy work)
> search for a planet which meets all the life-support requirements for the
> race.  If you want a dizzying number of races (ala Star Trek), you'll probably
> want to define basic attributes (ie, 'bumpy forehead' or 'warlike') and
> families, then have a generator that actually creates aliens from there.
> Giving them culture and history is another thing altogether, but this will
> take care of pre-civilization races romping around on various planets.

Again a mixture of computer generated and hand crafted, it sounds 
like an excellent approach.   It would be nice to first map out a 
core region using the virtual star system generator and then 
'concrete-ize' those that where to become the hand modified core 
worlds representing the homeworlds and major colonies of the major 
races in the game.
 
> > 7.  How many zones/rooms can an average builder generate in a years 
> > time?
> 
> This varies quite a bit, but more importantly I doubt that what you are
> after is a hand-crafted, room-based world.  At any rate I would probably
> throw up if I logged onto a 'space' mud and walked around spacecraft or
> even space itself with 'n, e, s, w'...something like this literally begs
> to be a coordinate/object system, with commands like 'go towards', 'turn
> toward', 'avoid', etc.

Space travel and like activeties will definately require a 
co-ordinate/object type of system.  However, for walking inside of 
objects/areas, I think a more traditional approach will not only work 
but be more familiar to the players... although I may well go to a 
facing system for player movement.   For a simple test, I logged onto 
swmud last night and played a bit.  While there where quite a few 
things I didn't particularly care for, I found the vector/co-ordinate based 
movement in space and the cardinal movement on worlds to combine 
quite nicely.  

Brian Price aka Delver <blprice at bedford.net>



More information about the MUD-Dev mailing list