Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: Tidying savegames to pave the way for plug mapgens
Home

[Freeciv-Dev] Re: Tidying savegames to pave the way for plug mapgens

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Cameron Morland <cameron@xxxxxxxxxx>
Cc: FreeCiv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Tidying savegames to pave the way for plug mapgens
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 24 Apr 2003 11:35:55 +0200

On Wed, Apr 23, 2003 at 09:15:24PM -0400, Cameron Morland wrote:
> Hi,
> 
> This patch does a number of things, primarily to make plug-in map
> generators much easier to write. For the most part I've been changing
> what is required to successfully load a file as a savegame.
> 
> While I was at it I removed some features required to load extremely
> old savegames. We already require that a savegame claim to be version
> 1.9.0 or later, so checking for features from 1.1 (!) isn't
> productive.
> 
> Irrelevant Parameters
> =====================
> First of all, there are a very large number of parameters in a
> savegame file, many of which do not need to be stored in the game,
> especially for scenarios. It should be possible to set parameters,
> such as gold, skill_level, nplayers, settlers, explorers, save_nturns,
> etc and then load a scenario, without the scenario overriding the
> specified values.
> 
> Most `x = secfile_lookup_<type>(...)` statements have been replaced
> with `x = secfile_lookup_<type>_default(..., x)`, ie use the value
> which the person running the server has already specified (or the
> default, if the user hasn't specified anything). Most options just
> need to be recorded in the file if the file wishes to change 
> the pre-existing value. For more complex options, such as
> fixed_start_positions and heightmaps (see below), I use the
> has_capability thing, so the savegame must specify that it will use
> those features. 
> 
> The only parameters that a scenario must specify are map.width,
> map.height, game.version >= 10900, and game.server_state == 0.
> If a scenario wants to keep its tinyisles, it has to specify
> tinyisles=1; mapgen makes much more sense this way.

The idea is good.

> Loading Height Maps
> ===================
> Currently, generators{1,5} construct a height map, then run make_land to
> add the terrains. Generators{2,3,4} make tilemaps directly, including
> rivers. I wanted external generators to be able to make use of the
> terrain/river/specials placing algorithms (especially since Karen and
> Ross have been working on making them better), so they needed to be
> able to provide height maps.
> 
> With this patch, a map can provide a height map, which is a 16-bit
> hexadecimal map. Once this is loaded the built-in terrain placing
> algorithm runs (with specified landmass, etc), and a tilemap is
> created.

This looks like an intermediate step. This depends on what the goal
should be. If we have the infrastructure we should IMHO out-source ;)
all of the map generators. There could than be a generate_height_map
program which is used by the real map generators programs. But all
this doesn't matter for the core freeciv code. It just gets a
(terrain-)map. If this is also our goal than this above patch step
isn't necessary.

> General mapgen layout
> =====================
> A few bits of mapgen make more sense now (IMHO). Instead of requiring
> each generator to do everything, it can specify what it does by
> setting booleans, then default functions can be applied later. This
> should make the code tidier. 
> 
> Since making rivers depends on having a height map, I wrote a simple
> function to generate a heightmap given a tilemap.

Also this logic should be moved to the external program.

> Load Command
> ============
> If you ask for help on the 'load' command, it will say that "Any
> current data including players, rulesets and server options are lost."
> This is rather annoying, and is mostly fixed by the "irrelevant
> parameters" section above. It still screws up the players, but pretty
> well everything else should be left alone (assuming, of course, that
> the file you load doesn't specify these things). It's a start.
> 
> External Generators
> ===================
> I haven't written the glue code to run external map generators, I've
> just been running them from the command line, redirecting to a file,
> then loading the file. But now at least the plug-in generators don't
> have to be so complicated; if they want to use a heightmap technique,
> they can just generate the heightmap and let mapgen do the rest.

> Attached are the diff, and a pretty terrible map generator written in
> Perl (it's not a great generator, it's just something I hacked
> together as an example). Comments? I'll be away for a few days, but
> I'd like to see what people think.

> ? generatesillymap.pl
> ? punchmap.pl

The perl code isn't included.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Windows is the one true OS. MS invented the GUI. MS invented 
   the 32 bit OS. MS is open and standard. MS loves you. We have 
   always been at war with Oceana."



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