[Freeciv-Dev] Re: (PR#4034) External Map Generator

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

civmap.tgz uploaded to upload.freeciv.org. This is a Dec-30 snapshot of
the build directory under freeciv, i.e. sister dir to civworld. It also
contains a precompiled working binary. Attached is just the source tree.

Gregory Berkolaiko wrote:
> Creating a ticket for the subject.
> 
> Here is a digest of relevant info.
> 
> Raimar Falke wrote:
> =======================================================================
> Pluggable map generators: what interface to choose? Possible
> are:
>  - compiled in (server/mapgen_tectonic.)

   As GB says, this tends to have a high threshold for update/modification,
and limited scope for extension/experimentation. Only the top few generators
are likely to be here and only as a default set that is always available.

>  - loaded at runtime (mapgen_tectonic.so)

   This needs to have a rigorous interface, as the "device driver" analogy.
It is dangerous as the code runs in the server, and can both crash it, or
do bad things under server permissions when called. Thus it may need a
similar maintainer inspection/update overhead for a security stamp of
approval and code to check authorization signatures. Anyone should be
able to write their own shared object for their own use and run it with
security checks turned off, however.

>  - seperate executable (mapget_tectonic)

   This has the advantage that anyone can write any code they want. The
program runs outside the server and can be run in a secure sandbox if
there are any security concerns (e.g. chrooted like ftp). There is no
need for any Freeciv code change for users to make and use their own
generators. All one is doing is creating/updating savegame files, and
all one needs to do this is a description/spec for the savegame format.

   Since mapgeneration is a once at startup operations there is no real
need for tight coupling to the server, and not doing so keeps the server
runtime footprint small.

> The first one is easiest but not really pluggable since you have patch
> the code. The second one is not much better in this respect. The last
> one is nice but you now have interface problems. How it gets the
> parameters (size, players, ...) and how is the data returned? It
> should not be required that binary needs to like some freeciv code to
> read the parameters and write the generated map. This way you can also
> code the generator in perl, python or java. I think an easy format
> based on common/registry would be nice. For both input and output.
> ======================================================================
> 
> Ross Wetmore has a patch (actually 2, attached) to essentially implement 
> the third approach.  
> 
> Here is what he writes:
> ======================================================================
> There were two versions, dif_00 contains the code to do a full
> reread of the savegame which I never really got to work as the
> game load is embedded and not really modular. But one could
> presumably change it to longjmp back up to the start once it
> had a savegame to read, if working through the details got too
> cumbersome. Reading the full game in means you could use this
> as a game selector as well as just a map generator.
> 
> The second dif_01 just reads in the new map generation stuff.
> There are potential sanity checks that should be done here to
> make sure the map read back corresponds to the right game. It
> works fine using the standalone mapgenerator that was also in
> the drop.
> ========================================================================
> 
> Information exchange with the external generator is done via savegame
> (every savegame contains all generator parameters and the map).  While
> this I think is the most elegant and easy-to-implement approach, it makes
> actually writing the external generators a hard task.
> 
> Ross has an answer to this too, as he possesses an example of such 
> external map generator. 

This was just a working prototype as a teaser/proof-of-concept. But the
idea was that a subset of the source tree could be packaged up as a
library that anyone could link to. Or as is done here, a fully standalone
version with all the bits and pieces could be built as a template. One
doesn't need all this, but having a template program to modify would
both make it easy for new mapgenerator developers and tend to keep things
in a standard mode that might make migration to CVS easier if contributed
works were thought to be useful.

> Unfortunately, I seem to have lost some necessary 
> parts of this example.  Ross, can you resend the whole thing again, 
> please, this time to RT, so that it doesn't depend on the irresponsible 
> members of the community like myself.
> 
> Judging by what I still have, though, it seems that Ross' code is much 
> ahead of the rest of Freeciv, as it seems to handle general topology.

Part of the fun in doing this was to experiment at cleaning up a lot of
the core map elements to put them into a more "C++" object flavour, since
as a standalone program there was no need to maintain CVS compatibility.

But it would be relatively easy to take just the driver and a correspongding
CVS set of *.o's plus CVS mapgen.o, i.e. closer to the libmap.a concept,
and follow the pattern in the source hierarchy to build the template.

In the future, registry and savegame routines or just a simplified savegame
library based on the spec could be ported to a number of languages. This
would enable maps to be built and saved in a very flexible way.

Finally, the libmap.a could be updated with a lot of useful map generation
and manipulation routines. Civworld for one could benefit form this sort of
auxiliary packaging of things and map tweaking resource. To put all this in
civserver is just adding overhead to the footprint.

> G.

Cheers,
RossW
=====

civmap.tar.gz
Description: civmap.tar.gz