random map generator (a request for specs)

[primemover]

Hey, this is primemover, looking in after a long recess (forgive the pun). I got bogged down with school and I was so burned out when school was finally over (being it was my first year teaching and being in a difficult district) that I just took the summer off free of thinking. I have switched districts and this *may* be a less stressful year.

But I'm in the mood to do something with this civ effort today and thought I would get started on an attempt at the random map generator I offered to do. Provided that school doesn't get me over stressed again, I am more likely going to be able to follow through this time. I would like to start a C++ attempt at the map generator (to find a good algorithm for our needs) that can be translated into Java at a later time (I.E. the only thing that should need to be dealt with are differences in pointers, objects and the GUI if one is necessary) We could also potentially use the generator as a separate executable that creates a scenario.

Keep in mind, that I will need to do this as I have time. Weekends like this one where nothing pressing is to be done are ideal, but there will be periods when I will not be able to work on it. Also keep in mind that since the Call to Power II source code is about to be released, I may eventually join that coding team, as it is very close, playwise, (with some significant additions/modifications) to the kind of game I have in mind. That being said, I am ready to do some work.

I have a general idea of how the map generator is going to work (if we are still using local maps) and I don't anticipate a local version being too difficult to do (a global one, however, is a significant task). As it is, it looks as though, we are still dealing with local scenerios so I am assuming we want a randomly generated local map. So now I am looking for any comments regarding the generator, specs on map layout, and current environmental model.

So here are my questions:

1. What is the current map size and characteristics that I need to know overall in order to generate the maps?

2. Any significant changes made since I last posted? (back in Jan or Feb I believe)

3. What are the current types of landscapes, weather, vegetation models, currently in use?

4. ID numbers, DEF's, constants and specification/header files would also help in issues with item in question #3 (eg... assignments such as DESERT_TERRAIN_ID).

[LDiCesare]

Hi,

The best thing to look at is the scenarios folder in the jar file. Therein, there is a map section where you have basically all the information.
I think a good map size would be around the size used fro Jericho or a bit bigger (12 x 32). You may want to make it bigger, or as an input of the program. There are no hard limits on map size, but memory becomes a problem (far too) fast with big maps.
The model currently in use is still very simple:
You should check the dataformat.html file if you have it for the data format, but here is the list of terrains currently coded:

• 
  o
  - ocean
  
• 
  c
  - coastal
  
• 
  f
  - flat
  
• 
  p
  - plain
  
• 
  r
  - rolling
  
• 
  b
  - broken
  
• 
  m
  - mountain
  
• 
  d
  - dunes
  
• 
  s
  - swamp
  
• 
  F
  - forest
  
• 
  j
  - jungle
  
• 
  t - tundra

I think the easiest thing to do would be to generate a scenario xml file, with stubs for the constant parts, and generating the map part. You actually don't have to put any civ in the game for it to show the map, but that may be easier by copying everything but the map part from another scenario and changing the map. Beware there are square references in the scenario that you may have to change too in order to get it to work.

[Mark_Everson]

Re: random map generator (a request for specs)

Hi primemover, good to see you back. Picking up from where Laurent left off. . .

Originally posted by primemover
2. Any significant changes made since I last posted? (back in Jan or Feb I believe)

Not AFAIK

3. What are the current types of landscapes, weather, vegetation models, currently in use?

Like Laurent said, it is Very simple at this point. You can open the demo .jar file in winzip and look at the file \resources\terrain.xml to see what there is. For now the info about vegetation is only contained in farming sites.

For what Will be there in terms of vegetation etc. the old discussions in the ecology thread, some of which IIRC you participated in, are still valid.

Cya,

Mark

[primemover]

Here are my thoughts on what has been said:

I think a good map size would be around the size used fro Jericho or a bit bigger (12 x 32).

umm... that is REALLY small. I don't remember it being that small... but hey it's been a while

I think the easiest thing to do would be to generate a scenario xml file, with stubs for the constant parts, and generating the map part

Since I don't know much about XML (other than what is is...) this went a bit over my head (in terms of what a stub is and the exact meaning "constant parts" has in this context).

Same with the following...

Beware there are square references in the scenario that you may have to change too in order to get it to work.

[primemover]

Like Laurent said, it is Very simple at this point.

Should I expand on it? Make it a bit more complex? (Althought we would have to come up with more graphics if I did that)

Is vegetation separate (an overlay?) from terrain? (yet?). Keep in mind that they *are* two different things! (Swamps generally occur on flat terrains for obvious reasons, but forests, rain forests, grass, etc... can occur on mountians, planes, hills, etc...)

If we decide to make things more complex (such as separating the concepts of terrain and vegetation) we will need to make some graphics to accomodate.

Matthew

[LDiCesare]

Vegetation should be separate, but is not yet. The graphics aren't really the hard part (forests can be an overlay quite easily), but I think we must accomodate the code to take these into consideration.
Terrain currently is just (vegetation + terrain type) a la civ, with the additional possibility of having rivers and coastlines on the sides, and special features (like gold ore, etc.).
The terrain.xml file really contains everything we can do with terrains now. Adding something like separate vegetation/topography is feasible, but just takes time.
Also, we don't have a xml description for rivers now.
All these things can be done, but I'm too busy with the ai right now to tackle them soon, and don't think anyone else has time for it.

[Mark_Everson]

Hi Gents:

My take on this is that you should make the world generator according roughly to what is in the ecology model. It doesn't have to get there all at once, but that should be the overall goal. We can then adapt the output of the map generator to make the map for the game with whatever simplifications are needed to make what the game needs at that point. If you will, we'll have an adapter to dumb down the generated map.

There are a number of things not in the ecology model that Laurent has brought up, like economic specials such as gold.

Laurent is pretty much our only active programmer for now. Until someone else shows up, or I or Gary get back to coding, we will have to do things in a way that he can live with. The xml map part of the scenario files shouldn't be that difficult for your code to generate primemover. That is what Laurent is talking about, and seems to be the path of least resistance at this point. Take a look at the map section (near the bottom) of FE delenda.xml in the .jar file to see what is involved. There is a doc that describes what the tags mean that is dataformat.xml in the .jar file.

[primemover]

remember my lack of experience with XML (my second posted message in this thread). I will have to become more familiar with it as I go.

Few more questions... I think I'm getting a good idea now (minus the actual details) of how this will work.

So are rivers and coastlines overlays? I am wondering this for a number of reasons. Here are some thoughts that have to do with this and some questions:

1. Call to power II uses a unique system of graphics that integrates with bordering graphics using a specific algorithm to figure out which graphic is to be used. It works out so that the transition between land types is not so cut and dry and so that it looks relatively natural. The advantage is that it has nice transitions (not so modular/blocky). The disadvantages are the complex algorithm, number of graphics, and time it takes to create them all. So my basic question is, how does the COC system work?

2. Since it seems you desire a separation between landscape and vegetation, and perhaps even soil (might help with what I'm about to say), maybe we could come up with an easier system of overlays so that the entire nature of the land was done using overlays. As long as we are on a cartesian map, we could even cache the layout of the land every so often so that we don't have to do too much of the overlaying (other than tile improvements). That way, we can speed up scrolling etc. (we could bit blit instead of contantly drawing overlays other than units, cities, and goods).

Anyway, these are just some ideas I am throwing into the pot.
Here are the questions I would like answered now (thanks for answering the previous ones):

1. It really would help to get the general idea of how the water/land/vegetation works together before I develop a graphic interface to this whole thing.

2. I can go ahead and implement a model that separates landform, vegetation, and even soil type and then we can work with whatever we have (simplifiying it for now, but still having the mechanism for later use). Is that something that you want me to do?

Matthew

[primemover]

addendum

(please read the above post)

As I posted my reply, I just noticed that Mark has recently posted (since I last read the update).

It sounds as though Mark is encouraging what I suggested. Just let me know.

you should make the world generator according roughly to what is in the ecology model.

would that be map generator? I am still assuming you only need a small map generator right now (of a local area). A world generator is a major undertaking in comparison. (A world generator requires that we consider the interaction of an entire plate system, where a "area" generator means we can just make a generalized guess at the local layout of the landscape based on the nearest fault line(s) if they exist at all).

[Mark_Everson]

When I said "world generator" I meant map generator, as you suspected. Don't worry, I'm not trying to talk you into doing the whole world at this point!

[LDiCesare]

So are rivers and coastlines overlays?

Yes they are.

Call to power II uses a unique system of graphics that integrates with bordering graphics using a specific algorithm to figure out which graphic is to be used.

I know that system. It's quite nice, but the blending requires lots of art, in particular if you want to add new terrain types. I don't think we're going that way because of the amount of art needed. Picking the right tile wouldn't be that much of a computation problem, since it can be done when terrain is determined, i.e. usually only once at the beginning of the game.

Since it seems you desire a separation between landscape and vegetation, and perhaps even soil (might help with what I'm about to say), maybe we could come up with an easier system of overlays so that the entire nature of the land was done using overlays.

Yes. I agree that we could have everything as overlays. Currently, the map draws its terrain, coastlines, roads, units, walls, and then there is an additional overlay for showing planned movement, roads and forts. So one or two more overlays won't change much.

1. It really would help to get the general idea of how the water/land/vegetation works together before I develop a graphic interface to this whole thing.

I don't know what kind of answers you expect here. Except looking at the ecology model. As far as what's coded, a terrain has movement and economics features, which should probably be a function of landscape + vegetation, and rivers should have a movement cost (plus maybe some military defense value).

2. I can go ahead and implement a model that separates landform, vegetation, and even soil type and then we can work with whatever we have (simplifiying it for now, but still having the mechanism for later use). Is that something that you want me to do?

I think having the three separate types would be the best, that way, we can simplify it for now, and remove the simplifications when we enrich the code to manage the various layers.

[primemover]

ok... looks like a plan. I will get started soon. Probably this weekend since nobody's going to be around this weekend but me.

[Lord God Jinnai]

OOH yea! all we need now is someone to do some non-sqare-based tiles system...more triangular.

[primemover]

re: non-squared

I hope to eventually do this... but this that would require a major makeover to everything. So first this generator.... next a world generator. Then eventually, a globe generator.

[LDiCesare]

I looked at the existing code. Gary coded a fractal map generator, which gives big mountain masses instead of ranges. As I didn't know what to do on tuesday evening, I coded another algorithm which is a very simple division of the map into polygons (tiles), which I then ram into one another to get some mountains.
The algorithm I used makes it ok for square maps, but maps that have one dimension much bigger than the other will look stretched that way.
Anyway, it took me only one evening to code it, so it's neither very good nor something I plan to use. The code is simple enough, though, so primemover, if you are ineterested, I can send it to you. It would show you how the map interfaces with the rest of the game.
Anyway here's a set of screnshots showing the results of the current algorithms (vegetation is not computed).

The left shows my algorithm (tiles), the right is the fractal algorithm Gary coded. There are 2 screens for each setting. Settings top-down are lots of land, islands, plains: