[MUD-Dev] Hard Sci-fi Muds was Character Evolution
yospe at hawaii.edu
Thu Sep 4 09:35:53 New Zealand Standard Time 1997
On Wed, 3 Sep 1997, Adam Wiggins wrote:
:> > 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.
See my earlier list of (somewhat) hard sci-fi writers. I included David
Weber, in spite of the fact that his tech is based on completely fabricated
physics, because the physics are plausible, incredibally well detailed and
explained, and completely consistant. Gravitational stress distorts more
than just normal space, creating hyper bands that can be tapped for what
appears to be faster than light travel, in normal space... the actual lines
of major flux are deadly for the normal mode of travel, but can be navigated
by a sort of grav sail... and its all concrete, down to the histories of the
physicists and engineers responsible... this definately qualifies as hard
science to me. Niven is a little shakier - he has those "outsiders", and the
coldlife, which tend to really rub off the edge.
:Right-o. The difference, then is:
:hard sci fi = SCIENCE (fiction)
:soft sci fi = (science) FICTION
Bingo. And then there is Science Fantasy (Space Opera usually falls into
this - Star Wars comes readilly to mind, and personally, I'd throw Trek in
there too, what with the occasional mages and such.)
: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
There is no restriction to "known science"... remember, most hard sci-fi
authors have a formal college education, often a PhD, in physics. They know
how to extend "known science" to whatever they need, within reasonable
:> > This goes back to the landscape-generation stuff we always talk about,
:> > is useful for any kind of mud with landscapes in it. Thus you could
:> > model as many worlds as you want by simply painting landscape maps for
:> > with a paint program. If this is too tedious for you, there are tons
:> > great fractal landscape generators that can give you endless random
:> > 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'.
Ah, the graphical seed method. This can get cute - throw in a picture of
Homer Simpson, or your favorite italian cookbook's ingredients splash page,
and watch the fun as it generates a rather unique area...
:> 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.
Fractals are not ideal for landscapes, however. I speak from experience.
:> > 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
:> > 100 rooms, only 10 or so of which were created custom for that space
:> > Then you can make many of these space station objects - they are
:> > 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.
Extend it enough, and you can generate LA on the fly. Well, maybe. I have no
idea what LA looks like from the inside, but I can generate massive cities.
Well, sort of.
:> > > 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.
A room, in my system, is an area of limited enough visable range that you
tend to see all the walls when you look around. As opposed to just looking
:> > 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:
: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.
: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.
The irony of that is, while I have as yet provided no way to find where
"north" is as a player (have not yet implemented magnetic fields - sue me)
there really is a hidden ijk coordinate system (xyz for you non physics
geeks) under everything, oriented north to the orbital k vector of the
planet, mapped to local j, local k being away from the center of the planet.
Of course, this coordinate system is arbitrary, could be overloaded by a
spherical model in a second, and occasionally is.
"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe Registered Looney by Terry Pratchett
yospe at hawaii.edu http://www2.hawaii.edu/~yospe Meow
More information about the MUD-Dev