[Freeciv-Dev] Re: I have written a new terrain generator

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 11:12 AM 02/04/30 +0200, Helge Hafting wrote:
>"Per I. Mathisen" wrote:
>> 
>> On Fri, 26 Apr 2002, Helge Hafting wrote:
>> > I have written a new terrain generator, and wonder
>> > if there's any interest in testing it,
>> > and where I should send the files.
>> 
>> This is interesting. You should upload a tarball of the files to
>> ftp.freeciv.org in the directory pub/freeciv/incoming, and then let us
>> know, so that we can test it.
>> 
>Thanks, I have uploaded tergen.tar.gz to incoming.
>Untar it and move source files to
>freeciv-1.12.0/common/ (it uses the registry routines)
>
>Helge Hafting

I tried things out and except for problems with the savegame (I commented out
this code to allow the printed results to complete) it looks quite intriguing.
I used a release version of freeciv-12.0 from last summer. Attached is a
printout if one needs an example to make sense of my comments.

I was impressed by some of the simplicity of the algorithms and coding style
which produce quite reasonable results. 

I saw nothing objectionable in the code save maybe for a tendency to code very
long lines vs wrap at ~80 columns. The style, technical level and
documentation
are very readable and professional.

I also think that the various steps are modular enough that it should not be 
difficult to replace, say the heightmap generation, or river generation with 
other modules. Or conversely, insert these into the existing mapgenerator1 as 
replacement for some of its current modules.

It should also be possible to slip some of the make_fair() and other routines 
into this sequence to enhance some aspects via post-processing.

Your terrain rulesets could quite easily be combined with the make_{type}()
routines to provide additional or replacement parameterization/functionality.

make_plains() converts roughly half of remaining grassland to plains in
mapgenerator1. The trick with height, temperature and wetness is to bias such
selection so higher/colder/drier tiles are more likely to be plains, but the
overall weights sum to 50%. There are some attempts to build such effects
into the existing module, but it would be trivial to use the per-tile values
from your system vs the current computed ones to give a more sophisicated
flavour.

Now for some "weaknesses" ...

The update/rewrite savegame code needs to be rethought and rewritten for
viable standalone use. I doubt you will find this comment a surprise :-).

The map structure appears to be quite blocky. I suspect this is just a matter 
of playing with the smoothing algorithms, or substituting calls to things
like 
adjust_map()/smooth_map() in the corecleanup mapgen.c to make the heightmap 
more uniform/contiguous and/or round off some of the edges so their original 
NxN character isn't quite so apparent. If you look at the asteroid rain
"splash" effect in the corecleanup mapgen.c, there might be some ideas about 
how to tip or randomize block adjustments within a smaller range to destroy 
the integrity of the block borders with little basic change to your system.

The area where this blockiness may be a more severe problem is in the terrain 
allocation. All terrain above a certain height is not a mountain, but quite 
often high level plateau, or a fertile river valley. Some of the simplicity 
here might be modified to detect "roughness" or changing elevations, or 
conversely find a way to un-smooth mountains into thin linear chains rather 
than blocks. Hills can be more blocky, but should have a similar "natural" 
shape. There are a lot of coastal mountains, i.e. at the edges of tectonic
plates in the real world, with the centers of continents often being quite
flat.

Your big continents tend to uniformly mountainous interiors or be composed 
of a central height mass with peripheral lowlying blocks, i.e. dome shaped.
Note, there is a similar tendency in CVS, so you are no worse at this aspect
of heightmap generation and usage.

Inland lakes and seas should be possible with your system, but I didn't see 
that many. It might be that restricting outflows and setting a threshold for 
combining adjacent rivers into swamps and lakes would give this effect. I 
suspect that your seas are of the Dead Sea type, i.e. below true sea level.

Rivers should flow through drylands. There seems to be a tendency for a lot
of short rivers on the windward slopes, and nothing flowing to leeward. Long
river systems are typically found in the latter case.  I'm not sure if this
can be tweaked by increasing flow-through values and/or a greater wetness
distribution area that extends 2-3 tiles with at least some major rainfall on
the immediate leeward slopes. The mountain heights need to be narrower or a
change in height be used as the moisture squeezing operation on clouds, maybe.
Rivers also appear to have multiple outflows in some cases, or be joined at
their headwaters. Random rivers without constraints can be very unrealistic
but this is difficult to get right.

make_fair() postprocessing and/or some additional variability in the selection
of forest/jungle, grass/plains, swamp/hills, tundra/arctic might reduce the
mono-terrain aspect of the current selection. The trick is to have a range
probability that peaks or plateaus near the optimal conditions (but is not
100%) and extends (possibly) far out into suboptimal parts at low threshold.
The order in which the terrain types are allocated can be used as well. The
resulting effect is a measure of randomness or denseness for each terrain type
that controls its possibility of appearing and clumping when it does.

The concept of controlled percentages for various terrain types is also
something that appears to be missing. Your algorithms can still be used but
their "average" points or "distribution" weights may need to be adjusted by a
(un-)smoothing function. Or the random selection use the computed averages in
some way to compensate. You provide a number of different (and maybe more 
useful) parameters to control the texture of the final map, but it may turn
out that some interface to the currents percentage system is either required
for backwards compatibility, or as the common form that all generators agree
to support for uniformity of user interface. Optionally allowing per generator
paramters is perfectly reasonable as an additional way of using them for
advanced users.

It would perhaps be worthwhile to see what sort of post-processing or builtin
capabilities would really entail in terms of changes to your system.

But I really do like the basic simple and yet conceptually realistic approach
to the fundamental generation here and think this is an excellent basis to
develop further, perhaps even close to the current CVS mapgen in usability as
it stands.

I guess a followup question is what would you like to see happen next. Are
you interested in enhancing or upgrading your system? breaking it down and
integrating it into current modules? discussing and/or working with others
to do any or all of the above? having others take over and do such things?
working on a design proposal for discussion and presentation?

Cheers,
RossW
=====

rww@wetrec[290] sh -x mktergen
+ gcc -g -O2 -o tergen tergen.c registry.o sbuffer.o astring.o genlist.o
hash.o
inputfile.o ioz.o log.o mem.o shared.o support.o -lz
rww@wetrec[291] ./tergen cg-4000_001.sav
Growing terrain...

aaaaaaaaaaaataaatttaaaaaaaaaattaaaaaaaaaaaaaaaataaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaa
aaaaaaaaaaaataaaataaaaa aaaaaaaaaaa  aaaaatttttaaaaa      aaaaaaa
aaattaaataaaaaaaaaa     aaaaaaaaa     aaatttttaaa         aaaaa
aaaaaaa               aaaaata        attttta            ata
Segmentation fault (core dumped)
rww@wetrec[292] gdb tergen core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./tergen cg-4000_001.sav'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  chunk_alloc (ar_ptr=0x2abeea00, nb=16) at malloc.c:2875
2875    malloc.c: No such file or directory.
(gdb) where
#0  chunk_alloc (ar_ptr=0x2abeea00, nb=16) at malloc.c:2875
#1  0x2ab4eaf6 in __libc_malloc (bytes=12) at malloc.c:2703
#2  0x805137b in fc_real_malloc (size=12, called_as=0x8053b7f "malloc", 
    line=133, file=0x8053b75 "genlist.c") at mem.c:60
#3  0x804db0a in genlist_insert (pgenlist=0x806610c, data=0x8141118, pos=-1)
    at genlist.c:133
#4  0x804adca in entry_list_insert_back (tthis=0x806610c, pfoo=0x8141118)
    at speclist_c.h:64
#5  0x804c7bb in section_file_insert_internal (my_section_file=0x8056838, 
    fullpath=0x7ffff430 "map.t003") at registry.c:1007
#6  0x804c095 in secfile_insert_str (my_section_file=0x8056838, 
    sval=0x8075ed0 "     aaaaaaa", ' ' <repeats 15 times>, "aaaaata
attttta", ' ' <repeats 12 times>, "ata", ' ' <repeats 16 times>, 
    path=0x80532be "map.t%03d") at registry.c:800
#7  0x804a8aa in tergen (savegame=0x8056838, conffile=0x8056850)
    at tergen.c:496
#8  0x2aaf3790 in __libc_start_main (main=0x804abc0 <main>, argc=2, 
    ubp_av=0x7ffff974, init=0x8048ce4 <_init>, fini=0x8052e1c <_fini>, 
    rtld_fini=0x2aab835c <_dl_fini>, stack_end=0x7ffff96c)
    at ../sysdeps/generic/libc-start.c:111
(gdb) 


        printf("%s\n", line);
496->   secfile_insert_str(savegame, line, "map.t%03d", y);
        secfile_insert_str(savegame, rivr, "map.n%03d", y);
        /* To be removed.  Make terrain instantly visible in order to
           evaluate the tergen algorithms. */
        secfile_insert_str(savegame, line, "player0.map_t%03d", y);
        secfile_insert_str(savegame, rivr, "player0.map_n%03d", y);
        memset(line, 'f', dx);
        line[dx]=0;
        secfile_insert_str(savegame, line, "map.a%03d", y);
    
        /* After this, the user must edit the savegame and
           remove duplicates, or the game won't load.  */
      }
      free(line);
    
      if (!section_file_save(savegame, "game_test_tergen.sav", 0))
quit("save failure");

tergen.zip
Description: Zip archive