[CF-Devel] Suggestion.

[Mark Wedel]

 I had a fairly long discussion with garbled last night on this topic, so rather
than responding on specific points, let me put out the proposed idea.

 An external program will use the perlin function to generate elevation data. 
That program would then figure out appropriate terrain types based on things
like elevation, and write the data out in tiled map format, which is the same
format as used by the rest of the maps.

 The server admin can then very easily modified these generated file to his
desired needs.

 To make this easier, there would be a few other files in the map directory. 
One would describe maps that should get inserted into the main map (eg,
navar_city, east coast, bay to north), etc.    For simpler ones, which are just
exits (eg, dragon cave, castle arg), there may be other hints, like 'within 200
spaces of navar city', or 'near center of the world'.  I'm using broad english
terms here, this would become a much more formalized language that will make
parsing and figuring this data out.

 There would also be a file generated that contains symbolic exit locations, eg,
something like 'peterm_dragonquest:world_50_23:18:14'.  This would be used for
two things - one, npc scripts would be able to query this file, so that it can
formulate messages that give some hint of the location (you can do a coordinate
translation, so can easily know if the map is to the north, east, ... from where
you are now'

 The other thing would be that maps could use these symbolic names.  Thus, the
dragon cave could have something like 'slaying @peterm_dragonquest', which would
then figure out that it should lead to world_50_23, at 18,14.  In this way,
dungeons can be located anywhere on the world without much trouble.

 Garbled plans to contribute weather effects to this, some of this is done in
the server.  Thus, the difference between a plains and desert becomes the amount
of rainful the two areas get.  The world would also evolve somewhat - areas that
are frequently travelled between would develope paths (by tracking the number of
times a player visits a space, and when beyond some point, trails, and then
perhaps, roads evolve. At the same time, there is some decay factor, so if a
path does not get used, it decomposes back into solid forest.  Related, forests
could spread if the climate is right, and they could die back from various
effects (eg, fire balls or the like), and then grow back over time.

 My personal thought is that if you rainful in areas, you can determine where
rivers may be (eg, you can figure out how much water accumulates on a space,
figure where it runs to, and when it gets to a certain point, you have  a small
river).  Figuring the coarse of the river is pretty easy - once you figure out
what space it is on, find the adjacant space near by with the lowest elevation,
and put the river there, and repeat.  Eventually, you will either reach and
ocean, or you will get to a point where all the terrain around it is now higher,
the end result is a lake, that keeps spreading until it gets to a point that it
can break out and continue.

 A lot of this may be for a second or third pass approach.  I also was going
look at least at doing a phase one implentation sometime in the next few days
(eg, use the function, that then generates out a set of tiled maps).

 The advantages of this approach:
1) Main generation removed from the server, keeping the server simpler, and not
needing to worry about possible cpu times to generate the world.
2) With the maps written out in standard map format, very easy for the server
admin to inspect and modify various areas.  If you just have something which
overlays on top, with the server making the underlying terrain, that is
difficult as what that terrain is only maintained as mathematical format.  The
server admin could more easily identify a high area of mountains that they want
to locate some secret city in for example.
3) A pre made version could be distributed for those that don't want to spend
the effort to generate one.

 Disadvantages:
1) Disk space for the maps.  Note that the maps can be compressed, and the
loader will run gunzip or zcat or whatever is needed.  That doesn't complete fix
the problems, but the maps are very compressible (IMO, I would rather leave the
maps in text format and compress them vs trying to come up with a more efficient
binary format).  The server admin could provide size specifications when
generating the world - thus, if they don't have a lot of space, the specify a
smaller world, if they have a larger one, perhaps they specify a much larger
world.

 There may be other disadvantages - that is the main one I can think of.