At Marks' suggestion, I've volunteered to pick up on the map generator model. Since I've been unable to reach Gregor to get his version, I've worked up a fairly simple model of my own. My background is in cartography and natural resources, so I'll try to use that to our benefit where possible. Following is a brief outline of what the model will do. I'm still working on the (pseudo)code for the working model; since I program in "ESRI Avenue" (also object oriented) and not Java (yet) it is not a "true" code, but it shouldn't be too tough to translate it later into something that will actually run. Please note that this is still really rough, but I wanted to get something posted to get some comments before I get too involved in hashing out the details.

The basic idea is to simulate plate tectonics as closely as we can without taking up a huge amount of processing time (simple, eh?).

This model starts off by creating a supercontinent, then fault lines are arbitrarily defined by splitting the supercontinent up into x plates. 25% of these plates (we can tinker with the ratio as needed) are labeled as "sea" plates, while the rest are labled as "land plates". The purpose of the sea plates is to create seaside mountain ranges (eg Chile) when the sea plates ram into the land plates

Next, the plates are moved around a bit, forming mountain ranges where they collide. A primitive climate model is used to determine the positions of deserts and vegetation distributions. Finally rivers, resources, and initial starting positions for the civs are selected based on certain criteria for locations (FE you wouldn't stick a tribe on a mountain top - usually!)

I know that a lot of people liked the idea of setting the sea level later to create undersea trenches, etc. That would require a Digital Elevation Model (DEM) or something similar to it for that type of model to work. I have quite a bit of experience using DEM's for hydrological analysis in the real world, and so haven't ruled out developing a model like that as well...I just put it off for the sake of time now, since it would be considerably more complicated. Any suggestions, gripes, etc are welcome! I'll link the actual "code" on my own site when I get it written up. Have at it!

I. Build Land Mass
A. Create Supercontinent
i. Select centroid
ii. Randomly build cells around centroid
B. Create Faults
i. Select landmass centroids
ii. Build landmasses about centroids
iii. Randomly designate sea plates (4:1 ratio of land plates to sea plates)
C. Move Landmasses
i. Select random direction move each landmass
ii. Move landmasses
iii. Change terrain as landmasses collide
D. Finalize Landmass positions
i. After n iterations, end movement
ii. Remove sea plates (they’re underwater anyway)
II. Climate Zones
A. 4 primary jet streams
i. Divide the map into 8 lateral bands (at equator, and halfway between the poles)
ii. Assign E-W and W-E alternately to each band
B. Delineate climate zones
i. Assign polar/boreal regions (bands 1,8)
ii. Assign temperate regions (bands 2,3 and 6,7)
iii. Assign tropical regions (bands 4,5)
III. Vegetation, Rivers, Resources, Tribes
A. Distribute vegetation
i. From “starting” edge (depends on wind direction) move pointer across map
ii. Assign vegetation according to terrain at pointer and according to 2 squares upwind)
iii. Move pointer to next square
iv. Iterate until band is vegetated
v. Move to next band and repeat
vi. “Average” out terrain at climate bounaries to avoid extreme transitions
B. Place rivers and lakes
i. Randomly place lakes and seas (within climate limits)
ii. Randomly select headwaters (50% of lakes will have a HW)
iii. Trace rivers from HW to sea according to terrain
C. Distribute resources
i. Randomly assign resource x,y coords
ii. Allocate resource at random coords according to terrain and veg at location
D. Distribute starting tribes?
i. Randomly assign tribe locations based on min distance from other tribes and veg/terrain limits

Your model looks great so far to me. I have only one question, and one comment at this point. My question is, I don't see how you get eight lateral bands out of something (a band, or a line) at the equator, and to more halfway between the poles. Can you clarify that for me?

In terms of placement of civs, we may not necessarily want to distribute them evenly. I think this can be left up to the player. We were planning on having a cost system for various start-up options such as cultural attributes, initial size of civ, proximity to others civs, etc. So civ placement might or might not be determined by the player (in general terms) and might have a point cost associated with it. The actual costs used would depend on play-balance determining the values of the various options.

you model looks very good.

Only got couple of comments,

a) Are mountains only created when landmasses collide?

b) Wouldn't it be better to place rivers first and then decided placement of tribes?

Keli

I really like the idea for distributing starting civs on a point basis, since it allows for the handicapping of expert players.

Keli: Thanks for the input! I had actually thought about volcanoes, the other major contributor to mountain ranges, when I was brainstorming but I forgot to include that into the model. I definitely will, since they do affect major portions of fault areas. Since we're identifying fault areas, this gives us the potential for including natural disasters in the sim (eg earthquakes and volcanoes in addition to weather related disasters based on the climate model). Disaster-prone areas could be identified at the start and given a value based on the likelihood of each disaster ocurring. Disasters could then be randomly triggered based on the potentials calculated at the start. Any thoughts on this, anyone?

I don't think handling the plate-induced natural disasters will be too tough. Esp when we know plate boundaries (and maybe intra-plate stresses?) However, I'd be happy to skip the specifics for now since I think its an easy add-on later.

What do you think about climate change through the game? Now That would be cool.

Great stuff,

I have a conceptual model in progress (eg if cell A collides with cell B, then that cell becomes "mountain"). Is that what I should be producing now? Or should I be identifying objects, etc. It's a little tough for me to get really detailed in the exact process, since I'm not totally familiar with J++ and the requests that you can send to the different objects (and as a result, I obviously don't know which objects are returned).

Bottom line: How detailed should I be in modeling the processes? Any idea who is going to actually code them? I could give it a whirl, but I won't be able to invest the time in learning J++ until November (I defend my M.S. in October ) Or is it ?

Thanks!

I'm not sure what Mark is going to say, but I can go this far, I think --

In the 'Space' class (dumb name, but it's early!) there will be a 'Map' class/object. In that 'Map' class there will be a 'generateMap()' method. This method likely will instantiate another class (MapBuilder?), where your model will be coded. Any parameters can be sent to it, of any kind, and anything can be returned -- even another object. Most likely 'generateMap()' will return a 'Location[][]' object. That's a 2-dimensional array of 'Location' objects (we will write those, too, of course). This 'Location[][]' object array will be the functioning worldmap. Locations will be accessed by index #, relating to grid coordinates. I.E. 'worldmap[2][3]' will be the 'Location' object that contains all the vars for map location 2, 3.

The outline of your model sounds great.

I'm looking for a limited (in size) corner of the project to work on, so if you have a somewhat detailed algorithm that you think will work, then I can try to implement it in Java.

Just a quick update on the progress with the Map Gen Module: MCA and I have begun collaborating on the coding of the model. I've worked out a pretty detailed conceptual model that should be reasonably easy to implement (MCA can verify if I'm correct in this assumption!)

You can add the following features to the original proposal above:
1. Volcanos produced near faults
2. Deep sea volcanos to produce some islands
3. Atolls/island chains
4. Erosion effects during map development (FE wearing down of older mountain ranges).

I have some pretty solid ideas on how to implement these features, so we'll see If we can do everything in the outline, I think that we'll have the most geographically/geologically accurate maps in any sim out there. MCA and I'll keep everyone updated as we make progress to ensure the inflow of fresh ideas that can only enhance the model.

What is the size of the map matrix (x,y)?
What land area does each cell represent?
Has anyone come up with final definitions for terrain/vegetation types?

On these last two, several proposals have been bounced around throughout various threads, but I haven't found anything listing the final say on what we'll use.

If terrain/veg types are not defined yet, what number are we limited to? FE in Colonization, forest is broken down into several types (conifer, mixed, deciduous, etc). Forgive me if I didn't get the Colonization types right - it's been ages since I played that game (got boring REALLY quickly - too much micromanagement!)

I like the new features .

> What is the size of the map matrix (x,y)?
I'm going with 320 by 200 cylindrical right at the moment...
Suggestions welcome.

> What land area does each cell represent?
Approximately 100 kilometers on a side.
The current graphics plan is to have them be "diamonds" with the corners pointing in the compass directions. Like in Civ2...

> Has anyone come up with final definitions for terrain/vegetation types?
No, don't have anything final on this one. I guess just pick the ones you like from the discussions.

> If terrain/veg types are not defined yet, what number are we limited to? FE in Colonization, forest is broken down into several types (conifer, mixed, deciduous, etc). Forgive me if I didn't get the Colonization types right - it's been ages since I played that game (got boring REALLY quickly - too much micromanagement!)

I think we can cope with several kinds of forest / jungle etc. if you think your model can reasonably calculate them. If it turns out to be a fundamental problem we could just redefine them all back to forest.

> Should we start a thread listing the "final" parameters for "global" variables? FE cell area, # terrain types, # units, etc. It might make things easier once we start docking modules. Then again I'm not a programmer, so what do I know!

Well... we Should, but I'm not up to it at the moment. if you would like to take a shot at the terrain types here I'd appreciate it. The military model is far from being reasonably complete, so I think starting to talk about specific units would be premature. These are all going to be read in from an initialization file anyway, so they really don't have to be finalized until fairly late in the project. Obviously, the stuff with graphics will have to be worked out well before then. My best guess is we should just work out the specifics of each model when that model is at the right stage, in the sprirt of OO programming .

On the topic of wearing down of mountain ranges, I may have missed it, but are you going to start with pre-existing mountain ranges on your mega-content? So we can have really old mountain ranges, as well as relatively new ones?

BTW, any chance of getting reasonable mineral deposit locations with your model? I know I'm really stretching, but hey, I've got to try!

There are still some issues that need to be addressed: how and how much we're going to move the plates, some mountain raising and erosion parameters that need to be found, and (perhaps most importantly) some "interesting effects" that I can't quite explain yet, before we move on to climate zones and vegetation.

Note that the implementation so far uses square map cells, because it is a no-brainer to display them

Source code, of the early prototypical variety, is available.

Looks cool. If the red are mountains, they already look more realistic than civ I can't wait to see it when you move the plates around a little more vigorously.

Great Work!

Please note that previously posted links to source code and screenshots are now invalid.

Since this really has little to do with graphics, it's a bit OT, but since you asked the question here, I'll answer it here. If you wish to pursue it in more depth, I suggest that we either find a more closely related thread or start a new one
I think that you may have misunderstood my last posting (I apologize if I was unclear). We can easily display subs under the polar caps - the problem is with the map projection itself and with how we handle the movement of units on that projection. There was a thread that dealt with this back in late August or early September (do a search on "projection" and "Albers" and it should come up). We're using what's basically a Mercator projection. If you're unfamiliar with that term, think of the map you may have seen (often in elementary school) that shows a huge representation of Greenland in proportion to the rest of North America. While this projection is OK for many things, it's terrible for displaying anything near the poles due to the distortion (that increases the closer you get to the poles). The problem we would face is this: picture a sub going over the pole from North America...it crosses the north pole and heads south towards Russia. On our flat map, it would head "up" the map from N. America and pop up further east (or west depending on how you look at it) at the top of the map heading "down" the map. While not impossible, it's an aberration from the normal movement mechanics that Mark is working on. He can probably give you a better answer on whether it's really "doable" or if it's not worth the work involved. As far as using a different projection (like your donut), we've already discussed that topic to death in past threads (you should do a search on those if you really want to pursue this, so as to not repeat anything that we've already discussed). As to your original posting - I'll look into expanding on the temperate zones (I had already given some thought to it, but you just gave me greater incentive to do so)

We might do something about polar movement Eventually, but it would be a kludge added in near the end. I'd prefer to put off discussion on such things until we get more of the basic model and code implemented.

Fog of war will be handled in some way TBD. That's more of a military issue.

MCA:

Hi. Glad to hear from you. Hope everything's going well with you. The GNU Lesser General Public License concerned me for a bit, but it Does look like the right way to merge open-source parts into Clash. I'll need to look into some details later...

MCA & Paul:

Don't worry, the very polygonal shapes of the continents and the very linear mountains are not features, but broken features, as noted on the page. The issue will therefore be addressed in future releases

The LGPL permits open source modules to be linked to proprietary code, so I expect there should no problems with the licence.

I am a geology researcher and my MS (soon to be I hope :-) is in gold and tungsten deposits so I believe I can answer Mark on the reasonable location of resources.

There are plenty of papers on Plate-tectonics, geodynamics vs resources
We can assign a probabilty of a resource existing on a square according to a tectonic classification that we could give to the square:

Is it a recent plate boundary (ocean vs continent, continent vs continent), an old plate boundary, a forebasin etc etc
Then we can give a probability of each resource appearing in each of those types of squares according to known actual relations

here are some of these relations

Copper porphiry deposits (I am not sure whow to spell these) are very comon on recent mountain ranges in ocean-continent boundaries

massive sulphides (tin and coper) on old oceanic basins and recent ocean plates

That's Great! Here is a list off the top of my head of the major geology-related resources. I don't know if we will use all of these, but this is pretty close to a probable final list.

Gold, silver, gemstones (could be a variety of types)
tin, iron, possibly copper, aluminum (bauxite)
coal, oil and uranium

Extra idea 1. Deposit types.
I don't know if it has been mentioned yet but could it be possible to have 3 types of deposit surface, mineable and deep. A surface deposit requires no mine to gain the benefit, rare but immeadiately useful. Mineable is as is currently available in Civ2 requiring a mine. Deep could be a new type where GEOLOGY needs to be learnt before you can detect the deposit. This gives all those Explorer/geologists something to do in the later game. It may be possible to include a special Mine improvement for Deep deposits.

Extra idea 2. Resource Exhaustion.
Many of the deposits around the world that were originally mined have now degraded. The copper and iron deposits in Turkey for example, Aluvial gold in California. Could deposits be given a "life"? This could be hard to implement but may be a nice feature. (To go with the above, many surface deposits could have limited lives, while mineable and deep deposits remain)

Extra Idea 3. Yield/Quality.
Way to many ideas. Variable yields for deposits. A gold mine is not necessarily the same as any other. Maybe the yields could vary by 1.

Also Nickle and platinum. Also make sure diamonds are common. They really are in this world but because of politics/economics many of the diamond mines are never mined because the price would drop drastically. Any time one is discovered now days it is bought out by the largest diamond mining company in the world to keep prices high.

2. Just simulate very large deposits - geologic anomalies - in this case it is a bit useless to simulate deep/shallow or depletion issues. Large anomalies are LARGE anomalies.

I come down mostly on the side of your choice 2. Although if these aren't enough for game play purposes, it would probably need to throw in some of the larger deposits in your category 1.

While clearly in reality each square should have a potential to contain any of the many resources, the current plan in the economic model is to have only one "special" (and minerals are among these) per square. So although I think it's worthwhile to calculate deposits and their chance for every sort of square, I just wanted to make it clear that the game mechanics will probably cut off most of these possibilities. So, for instance, while there might be tin in Greece, the early Greeks had to go to near Rome and other places to obtain tin. If there aren't nonuniformities in the distribution of tin, we will miss out on effects like that.

step one
Allocate geographical position and abundance of resources on the map (with geological credibility)

1 - They will be divided in surface and deep resources.

2 - resources are exploitable only if you have the knowledge to do so and if you have found them (this will require infrastructure investment - covered by econ model; and prospection investment - not covered yet.)
ex. a big % of surface deposits will be readily available to the player, for the rest of surface and deep deposits they will have to be hable to explore (prospection) on a square/province level and create production infrastructures.

How to make the player A really need those products that only B has?

Well... small deposits will only give you a little bit of production, way bellow your needs, and tendency will be for them to get smaller.

The very large anomalies (that can be simulated in example 1 as well as in two) will be 100 to 1000 times bigger and also much more productive (and this is not unrealistic!). The deposits in these regional anomalies (something that should be 2-10 squares big if the scale is 60 miles across)will be huge and hard to deplet (germany still produces huge amounts of coal :-))

The idea is to make everybody able to produce a little bit of everything (even if to make it so they have to invest a lot, and STILL not being able to satisfy product needs - one small deposit will only produce a max amount of ore no matter how much money you put into it) but make it much more cost per unit efective to trade.