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

[Adam Wiggins]

[Brian P:]
> > From:          Adam Wiggins <nightfall at user2.inficad.com>
> > 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.

Right-o.  The difference, then is:

hard sci fi = SCIENCE (fiction)
soft sci fi = (science) FICTION

It's much easier to have more fantastic and interesting stories when you're
only constrained by the bounds of your own imagination, instead of the
properties of the real world.  This is exactly the same as the difference
between a medieval mud with or without magic, mythical beings, and so forth.
I like a mix, which (as you point out) authors like Niven captialize on.
This way you're rarely distracted by ridiculous plot devices, but at the
same time the authors don't have to retrict themselves completely to known
science.

> > 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 potent
> > 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 landsca
> > of varying terrains.
> 
> I'm going to attempt to stay text oriented but fractal patterns may
> have a place.

Of course.  We're text based, but we paint all our terrain maps as bitmaps
in order to make life easier for ourselves.  It's just that certain pixels
translate to 'you are on a tall mountain without any foliage' while others
translate to 'you are in a softwood forest near the ocean'.

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

I used to have a ton of them quite a while ago, but I'm sure they are long
since gone.  At the time I don't think I even had a hard drive.
At any rate I've seen very simple fractal algorthims covered in computer
graphics books, so that might be a good starting point.  Once you're
comfortable with the theory you can just putz around with various formulas
until you start to get outputs that you like.

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

The same way things work in real life.  My apartment looks exactly like
every other apartment in the complex, yet I doubt anyone would have trouble
telling it apart from any of the others.  The room layout, oven, refrigerator,
microwave, washer and dryer, ceiling fans, carpet, kitchen/bathroom tiles,
wall colors, etc etc are all 'stock'.  It's all the *stuff* that's
in it that sets it apart.  And if your rooms are good and modifiable, even
a 'stock' room may cease to look the same - it gets burned down, or the
walls painted a different color, or the floor ripped up, or whatever.

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

Well, IMO the trick is to basically ditch the room abstraction at the system
(code) level, but leave it there for the players.  A 'room' is basically
an organized list of everything they can see, hear, smell, or feel at
the moment they type 'l'.  There may be no such thing as a room at the DB
level, though, which is, I think, your best option.

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

Well, if you want to set up some direction-mapping on the player object
to facilitate movement, that's fine.  Ie:

> l
You are standing in the midst of a stinking jungle on the planet Beuron.
Trees stretch upwards all around you, blocking out any light from the
sun.  Off to your right lies the smouldering wreckage of your escape pod.
> walk to pod
You walk over to your escape pod.
> search pod for direction finder
You begin to rummage through the wreckage.
(...)
You find the pod's direction finder.
> get finder
You pull the direction finder free of its harness.
> align with finder
You notice that the direction finder's arrow is pointing fourty-three degrees
to your left.
You will now assume that this is north.
> n
You head off to your left.


This, of course, allows for broken direction finders, or people trying to
guess which direction is north based on moss growing on trees or whatever
other mechanism you might like.  There's no internal representation of what
'north' (or any other direction) is, however.  Like rooms, it's just a
conveinient abstraction for players, and has nothing to do with how the
system organizes itself internally.