[MUD-Dev] Re: Terrain/Landmass & GIF/BMP

[quzah]

From: Niklas Elmqvist <d97elm at dtek.chalmers.se> on Wednesday, October 07, 1998
at 10:58 PM
Subject: [MUD-Dev] Re: Terrain/Landmass & GIF/BMP


>On Wed, 7 Oct 1998, quzah [sotfhome] wrote:
>
>[snip]


First of all, thanks everyone for replying. Rather than reply to
every message, I'll try and keep it short (grin) and hopefully
limit it to one or two replies. Thanks again all.

>
>> The first is this: I am developing a world generator of
>> sorts, that with a few parameters will generate the entire
>> mud world. It will take into account the following info:
>>    sizeX (width of world west to east)
>>    sizeY (length of world north to south)
>>    clustering (continents/small islands/large islands/etc)
>>    "hillyness" (flat/small hills/mountains/etc)
>>    mineral richness (frequency of mineral deposits)
>>    temperature (over all cold/mild/warm/hot/etc)
>>    on land water supplies (rivers/lakes/etc [amount of])
>>    wetness (over all very dry/dry/moderate/damp/very wet/etc)
>
>Neat. I am doing the same for a 3D terrain renderer.

I'm just doing a basic 2d map (overhead) of the world, where each
element of the 2d array is a kilometer^2. Then, if the kilometer
in question is actually encountered by a player, one will be
generated. (Think of each kilo as an "area" in diku). However,
rather than bother with rooms, I'm going to just create the kilo,
create the creatures that inhabit it, give them homes, add in any
items they require to live, toss in vegetation (based on the kilo
info stored in the 2d [temperature,eleveation,water supply,etc])
find out what direction the entering player is facing, where they
are entering from (coords) and generate them a "room description".

Basically, the terrain-bits stored in the 2d give the skeletal
of the kilo, and it is considered flat. Then, to give it shape,
I plan on adding its "land forms"; be they hills, tree clusters
or whatever. They'll all get a set of coords in the kilo, and
depending on your closeness to them and the direction you are
from them/and facing, it will determine your "room description".

>> Does anyone know a link or quick formula I could look at to do
>> something along these lines? I can just toss out random +/- to
>> a given coordinate, and check its neighbors to make sure there
>> is not too big a jump, but I think that would be inefficient
>> and or ineffective in the long run. Any suggestions?
>
>Well, other posters have already suggested the use of fractal terrain
>generation, and I tend to agree.



I am unfamiliar with them, but I'll look into it. (Actually, I may
even have a link or two already.) Again, thanks all.




>A good place to start out is with the following article, which explains
>the technique in pretty good detail:
><URL: http://www.gameprogrammer.com/fractal/fractal.html>


I'll check it out in a bit.

>> (For rivers I plan on using heuristics for getting from point
>> A (river source) to point B (river mouth) but I haven't looked
>> at it too in depth. Finally I believe I have managed to locate
>> the actual formula for "A*" so I may see what I can do with it
>> at a later date.)
>
>I'd certainly be interested in seeing this if you have the possibility to
>post it.


Here are a few on A* and the like:

<URL: http://www.gdmag.com/stout.htm >
<URL: http://www-cs-students.stanford.edu/~amitp/gameprog.html#Paths >
<URL: http://www-cs-students.stanford.edu/~amitp/Articles/AStar3.txt >

Actually I don't think I'm going to end up using it, because of
the fact that water flows down hill. (Yes, I'm aware of the one
instance, perhaps more, where it doesn't, but as a whole...). So,
not knowing enough about A* yet, (I haven't played with it yet) I
probably will opt just to do something like:

start(x,y)
find the valid moves from current local
flow in one dir at random
repeat

Again, I'm not sure, as I haven't gotten that far; must form the
land forms before I can add water. Mix dry ingredients, then add
liquids.

>Hmmm.... Seems to me that if you want to encode *all* the information in
>the map in a single picture, you'll get a very messy one. That is, it will
>be very hard (just as hard as with your ASCII output) to get a feel for
>what the map looks like. You can simply *not* encode all the data fields
>in those 20 bits (some of which are heights, others which are resources,
>and so on, I take it?) and make it useful for a human reader ("so, okay,
>um, a lot of green mixed in with a little red should mean high altitude
>and some, um, lessee, iron ore...").


The only thing I currently need the picture for is water and land.
The rest will be left off for now. I only need to see how high/low
terrain is. (So I can see if I like its grouping, or if it just looks
like a bunch of random crap ;) The image won't be used actually in
the game, just for some test runs when map generating.

>As for graphics formats... The format that strikes me as the simplest is
>plain BMP (the Windows incarnation, that is). However, other posters have
>responded to this, so I will refrain from doing it as well.


I haven't done anything with graphics ever, so it'll all be new
to me. Again, thanks everyone for the help.

>-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
>  "Nanny Ogg looked under her bed in case there was a man there.
>   Well, you never knew your luck."
> -- Terry Pratchett, Lords and Ladies


-Q-