Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: (PR#4034) External Map Generator
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#4034) External Map Generator
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Sun, 20 Apr 2003 09:18:09 -0700
Reply-to: rt@xxxxxxxxxxxxxx

Here is the full code by Ross (bzipped for obvious reasons).

Now that I look at it, I realise that I missed a lot of files (icluding 
README !!) just because they were hidden.  Ross, why would you do that to 
me??

G.

---------- Forwarded message ----------
Date: Fri, 29 Nov 2002 20:53:00 -0500
From: Ross W. Wetmore <rwetmore@xxxxxxxxxxxx>
Subject: Standalone map generation

Attached is a source drop of a prototype standalone mapgen as a teaser. 
As the ReadMe briefly outlines it has three main purposes. The code 
actually does work reasonalbly well, but do not be fooled, it is very 
much a prototype and has not been debugged down all its possible 
codepaths. The reading should be interesting, I hope.

This is primarily directed to Gregory who claims to have the mapgen
replacement task on his queue. The first purpose is to demonstrate
that running mapgen as a standlone program is quite feasible. As
part of this the key elements of Freeciv dealing with map and 
savegame operations have been packaged up as a wrapper environment
for running mapgen. This should be a good template/example source
base for anyone who wants to build their own. Or they can take
their favorite wrapper parts from this and modify at will. It 
should allow for lots of room to experiment without having to
breach the walls of fortress server/mapgen, and it should break 
through the limiting sound barrier of 5 or 6 map generators, too.

The second purpose once the playground is built, is to start chopping
up the mapgen monolith into bite sized library components with a
few framework systems for building mix and match maps. This may be
of interest to Mike as a library of map manipulation tools and 
constructor sets would be an excellent thing to share with CivWorld.
Something will soon need to be done for topologically sensitive
map making, and new modules or various constraint rules for map
module processing will likely appear as well. This is something for 
Gregory to start thinking about even if to that means planning an 
exit strategy for the duck.

The third purpose is to take a part of Freeciv that has largely been 
cleaned up and tucked behind interfaces, and do a major implementation 
reorg behind the interface wall. In fact, I did a lot of interface 
element renaming in the process, but it should be fairly clear what 
went where and in reality, not too much has changed but a few names 
from the outside. I plan to upgrade the corecleanups over the Xmas 
period to show how it all works at runtime. 

The latter is offered on spec as a practical example of how one might
start moving Freeciv to a version 2.0 base. It tries to move from the
monolithic style of coding tha peeks all over at global data to a 
more object and instance based flavour where functionality is clearly
and fairly tightly managed through a structured set of interfaces
and passed environment elements. Read the various headers as docs.

One example to illustrate what this means is that civtile methods are 
now fairly rigorously coded to deal with local (single tile) scope.  
There are corresponding civmap mehtods which may be trivial convenience 
access but in general if there is any global or adjacency computation 
to be done as a side effect of updating a tile value, the civmap level 
has the responsibility for doing this (as in redoing movecosts).

Some of this reorg should be of interest to Jason, as it involves
tightening things up for topology insertion at the map level, and adds 
the hexagonal adjacency rules for moving the core to a position where 
it can handle hex maps.

The other thing that might prove interesting is just what sort of 
techniques and style one might extract for doing similar encapsulation
and reorg of other subsets of the Freeciv codebase. The GUI and the AI 
rewrites are two that come to mind. In both these case one could make 
a good dent on moving towards Freeciv 2.0 by setting architectural
goals and incrementally moving towards them during this work.

Anyway, this is a trial offering to Gregory to kickstart him into 
thinking a bit more about what he wants to get into on mapgen. Xmas
is coming and he has promised to be in full flight by then :-).

Cheers,
RossW
=====

Attachment: civmap-Nov30.tar.bz2
Description: civmap-Nov30.tar.bz2


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