Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: topology patches
Home

[Freeciv-Dev] Re: topology patches

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: topology patches
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 29 Oct 2001 22:19:37 -0500

At 10:47 AM 01/10/29 +0100, Raimar Falke wrote:
>On Sun, Oct 28, 2001 at 06:34:01PM -0500, Jason Dorje Short wrote:
>> "Ross W. Wetmore" wrote:
[...]
>> We definitely do not want to have to write a new
>> map generator for each topology when the existing ones will do a
>> minimally adequate job of providing a basic one.
>
>Ross was talking about a new generator which takes all the topologies
>we are talking about into account. This one would general from the
>start. I have no idea how much work it is to change the current ones
>compared to the work for the new one.

Well, if you want to do an evolutionary design without touching the 
current code, just clone mapgenerator1 -> mapgenerator5. Everytime
you have the urge to touch one of the underlying routines clone the
hierarchy to that point and flail away. :-).

But it is probably a bit better to get an idea of what sort of 
"features" you want to build into maps. Then which topologies support
those features with a few mockup examples. The next step is deciding
what sort of algorithms and (user adjustable) parameters you want for 
each feature. The current make_<blort> and other elements can be used 
as a starting point for collecting this information.

Lastly, you put together a framework to select and filter various
elements so you can't do stupid things that don't apply to various
topologies. And you write the various modules to plug cleanly into 
this system, with easy ways to add new ones in the future.

Just to give you a quick feel for the current code.

The mapgen patch tidied up the basic make_<blort> feature routines
used primarily for mapgenerator1, and hooked them in to the tail
end of the cycle for the other mapgenerators so a lot of the final
prettying after the basic terrain building and type distribution
is actually done by common modules. They are still hardcoded calls 
in each mapgenerator, but changing this to a loop over a selection
is really very trivial. Map making goes through a well defined
sequence of actions largely accomplished by independent modules
acting on a map object to add features.

- init map and working memory, 
- pseudo-randomly distribute height with smoothing
- set the ocean level (i.e. landpercent parameter, all land is GRASS)
- make_mountains((maxval*66)/100);
- make_deserts();
- make_forests();
- make_swamps();
- make_polar();
- make_fair();
- make_passable();
- make_plains();
- make_rivers();
- remove_tiny_islands();
- remove_tiny_lakes();
- assign_continent_numbers();
- setup_seadata();
- map_check();
   

The island generators 2-4 do thir own initial distributions then this
sort of final pass.

  /* final cleanups using mapgenerator1 routines */
  adjust_map2();
  make_fair();
  make_plains();
  make_rivers();
  remove_tiny_islands();
  remove_tiny_lakes();
  assign_continent_numbers();
  setup_seadata();
  map_check();
   

The current features are pretty much tuned to the standard earth as
with bands of desert latitudes, and the make_polar or make_passable
add the stock CIV characteristics of isolated polar continents
which the server sanitycheck() is pretty anal in assert-ing must be
there.

No new development needs to impact the existing map generation until 
it is fully complete and stable. You can continue maintenance fixes
or updates as needed, but don't have to worry about "breaking" the 
world. *If* the new stuff makes the current stuff obsolete, or is 
significantly improved over it, then it can become the default 
generator, and the rest be relegated to alternates for those that 
really do want to stick with the old flavour.

Map generation is a good area for parallel development and 
non-intrusive experimentation. If you really want to carry this to 
extremes, just code load/savegame to handle any map_type you want to 
play, and write a standalone program, or use civworld as your map 
editor. It is trivial to even put in a mapgenerator that forks off 
and runs such a separate program to generate any map. Map making 
doesn't need to be server code.

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
>  reality.sys corrupt. Reboot Universe? (y,n,q)

Cheers,
RossW
=====



[Prev in Thread] Current Thread [Next in Thread]