Terrain

[Simon Loverix]

Hey, I'm really back, I printed out stuff and I've been working on it before replying.

1. Landform. flat, rolling, broken, massif.
I would add depression/valley/basin also. It can be used for valleys, river valleys, wetlands,coastal submerged lands, ..

2. Material. What the land is made of: soil, sand, rock.
Most areas have multiple layers in their soil. Also, very different material come to the surface on 10000 km².
Just assume : where vegetation is, is soil. Mountains are rocky.
Depressions collect soil.

3. Altitude. In metres, rounded to 100.
4. Landcover. None, crops, pasture, scrub, forest, jungle.
You can display it as no green to totally green (according to the BM classes: W(nothing), D, LC(scrub/ pasture), HC(crops), LF, F(forest) , CF(jungle)

5. Climate.
6. Watertable. Ocean, sea, mudflats, swamp, arid. The arid category covers the various types of desert.
Why not like the eco-model: Ocean (dark blue), Sea (blue), Lake (light blue), Wetland (partially blue) , Ice (white)?

7. Rivers.
8. Passes.
I think passes are better treated as geo-specials. A pass longer than 50 km seems a bit exaggerated.

9. Roads, including causeways.
10. Railroads.
11. Canals.
12. Urban areas.
13. Settled areas
Keep one percentage for terrain use: % natural/ % in human use. The % in human use can be further split up in % farmland and % buildings (depending on existing number of units of infrastructure). The dominating % would be displayed. (Or, if a city is just a partial overlay for the square, draw it on top.)

Aren't we going for composite squares? I mean drawing terrain, vegetation, water and infra independently on top of each other. Would be easier to code I think, but maybe it takes too much time to display... But it allows for hundreds of combinations with only a few overlays.

[Gary Thomas]

Great to have you back!

1. Landform. flat, rolling, broken, massif.
I would add depression/valley/basin also. It can be used for valleys, river valleys, wetlands,coastal submerged lands, ..

My immediate concern was for what is visible. If land is submerged it doesn't make a lot of sense to draw the underlying hills or plain then the sea on top of it.

I would imagine that "depression" is a matter of altitude, as is, say, plateau, though this does raise the question of transition from one altitude to another.

2. Material. What the land is made of: soil, sand, rock.
Most areas have multiple layers in their soil. Also, very different material come to the surface on 10000 km².
Just assume : where vegetation is, is soil. Mountains are rocky.
Depressions collect soil.

This could certainly be included in cover, and I have done so in the code. Effectively, everything is soil, except sea, desert and rocks. Just now the only rocks are mountains, but a rocky desert is possible.

4. Landcover. None, crops, pasture, scrub, forest, jungle.
You can display it as no green to totally green (according to the BM classes: W(nothing), D, LC(scrub/ pasture), HC(crops), LF, F(forest) , CF(jungle)

These have quite different effects in other ways, so should be made visually distinct.

6. Watertable. Ocean, sea, mudflats, swamp, arid. The arid category covers the various types of desert.
Why not like the eco-model: Ocean (dark blue), Sea (blue), Lake (light blue), Wetland (partially blue) , Ice (white)?

The terrain is all done by way of pre-prepared images, not just by colour. So we need a specific image for every terraion type to be displayed.

13. Settled areas
Keep one percentage for terrain use: % natural/ % in human use. The % in human use can be further split up in % farmland and % buildings (depending on existing number of units of infrastructure). The dominating % would be displayed. (Or, if a city is just a partial overlay for the square, draw it on top.)

This is already implemented, except for the buildings part. I would not imagine that, in most circumstances, buildings contribute very greatly to covering a 100 km² area.

Aren't we going for composite squares? I mean drawing terrain, vegetation, water and infra independently on top of each other. Would be easier to code I think, but maybe it takes too much time to display... But it allows for hundreds of combinations with only a few overlays.

Unfortunately, in many cases this doesn't work. Forest on top of hills is hilly forest, and different in appearence from flat forest. This is true of any kind of vegetation - the underlying land form is visible, so if you just draw flat forest on top of rolling hills, what you will see is flat forest.

The problem, essentially, is that most of these things cover the whole square and are opaque, so you will not see what is undeneath.

Cheers

[Lord God Jinnai]

My immediate concern was for what is visible. If land is submerged it doesn't make a lot of sense to draw the underlying hills or plain then the sea on top of it.

There is such land that is below sea level.

This could certainly be included in cover, and I have done so in the code. Effectively, everything is soil, except sea, desert and rocks. Just now the only rocks are mountains, but a rocky desert is possible.

desert is soil. Ice however (such as most of antartica) isn't.

[Gary Thomas]

There is such land that is below sea level.

I didn't say there wasn't, just that it isn't visible and therefore it is pointless drawing it.

desert is soil. Ice however (such as most of antartica) isn't.

Desert is actually a state of aridity. So you can have a soil desert, a sand desert, a rock desert or (oddly enough) an ice desert.

The commonest kind of desert (by area) is rock.

To avoid confusion I have renamed desert as "dunes".

Cheers

[LDiCesare]

I agree that being below sea level doesn't change much: Around the dead sea, you won't draw an artificial sea level change in the plains.
As for desert, dunes are actually desert sand hills. I also think most common desert is ice but that's pointless.

[Simon Loverix]

The building % of a square isn't that important and won't be used that much (and that is why it can be calculated only when needed). I had things in mind like greenhouse gasses absorption and, more importantly, the chance for a infra to be damaged when a minor disaster occurs, be it natural or man-made (eg. meteors or bombs). It's quite easy to bomb eg. Hirosjima, but to bomb the States' nuclear control center, it needs to be found first.

In the ecology model, desert is defined as minimal BM (1-15). So are you going to record the type of soil for every square to display it? Since every square can become desert..

What will be the functions of the main map? It would be appreciated if we made useful distinctions.

Most of the time, forest will not cover the whole square ( with the trees Fiera drew anyway), so you can still see what's underneath. You probably can't distinct between flat and rolling maybe but that's irrelevant anyway since there are trees.
Also, weren't there plans to represent reliëf like SMAC?

[Gary Thomas]

In the ecology model, desert is defined as minimal BM (1-15). So are you going to record the type of soil for every square to display it? Since every square can become desert..

There is a distinction between what is in the square, according to the ecology model, and what we show on the screen. The first affects what can happen in other models, the second is what we see. Hopefully there is a close modelling between the two, but in the immediate future (D5) we are constrained by the tile images we have available.

What will be the functions of the main map? It would be appreciated if we made useful distinctions.

Not sure what you mean here. The map shows the geography, the units and any cities, at present.

Most of the time, forest will not cover the whole square ( with the trees Fiera drew anyway), so you can still see what's underneath. You probably can't distinct between flat and rolling maybe but that's irrelevant anyway since there are trees.

Fiera's forest tile is opaque. The bits between the trees are still part of the forest.

Also, weren't there plans to represent reliëf like SMAC?

That is altitude. SMAC has a whole team of artists to produce hundreds of different tile images. We do not have that luxury.

Yet.

Cheers

[Simon Loverix]

With the function of the main map, I mean: what will the map be used for mainly. Military, economic or cultural matters FE. Just keep that in mind when designing the pictures.
You can also use only the trees of Fiera's forest.

But for the demo's it's better if it doesn't get too complex, I agree.

I thought I saw F_Smith mention (to Mark) in another thread that it only took deformations to do altitude, so we don't need any extra tiles.

[Gary Thomas]

I thought I saw F_Smith mention (to Mark) in another thread that it only took deformations to do altitude, so we don't need any extra tiles.

I hadn't thought of that one. Maybe the same approach will cover the various kind of hills as well.

On the other hand, the problem with lots of tiles is not the code, but drawing the damn things in the first place.

Cheers.

[Gary Thomas]

I want to make it quite clear that this post doesn't relate to D5, or even to D6 (which, I feel, should concentrate on Tech, Government, Diplomacy, an improved GUI and, above all, some AI), but maybe to D7.

I have always felt that 100km squares are too big for some of the things that could add considerably to the game.

In the discussion below "square" means 100km, "minisquare" means 10km, "microsquare" means 1km and "nanosquare" means 100m.

Certainly for combat, I favour 100m squares. This gives a mere 53,000,000,000 (on a quick calculation) for the Earth's surface. Entering the starting data would be quite a job, so, presumably, they will have to be generated automatically.

If they can be generated automatically at the start of the game, why not generate them automatically whenever they are referred to? The important point is that they have to be exactly the same every time they are generated. And the results do not have to be stored.

Here "repeatable pseudo-random number sequences" come in. See "Game Programming Gems", chapter 2.0.

At the start of the game, a normal random integer is generated as a seed for this game. It is saved as one of the parameters for the game. Then, as the map squares are generated, each gets assigned a random integer from a repeatable sequence. These numbers will be regenerated each time the game is loaded.

When a minisquare is referred to it will have x and y coordinates as integers in the range of 0-9.

Another repeatable sequence, seeded by the number for the main square, will run across the x-coordinate. That is, the first (left-most) column of squares will use the first repeatable pseudo-random number from the sequence, the next colum will use the second, up to the ninth. The same system is then used to work down the column to the correct row.

This process is then repeated for the microsquares and then the nanosquares, finally obtaining a random integer which defines the characteristics of the nanosquare.

Now yet another sequence is used to define the contents or characteristics of the nanosquare (which should be completely homogeneous - lets not go to the level of 10m squares). Also, the contents will be modified by the terrain type and any artifacts (city for example) found in the main square.

Generation of pseudo-random integers can be made extremely fast, and this whole sequence will have, on average, 27 numbers, plus one for each square characteristic.

Each time this square is referenced (and this will only happen in a battle, or perhaps during road-building) the above sequence is followed. This means that when we get to the point of displaying a tactical battle map (in the style of CtoP2), the terrain will be realy realistic, and stable.

Road and rail building could be a lot of fun, too. Also, in square rivers can exist and have realistic effects.

I suppose you might have guessed that random terrain generation has been an interest of mine for many years...

The memory, execution time, disk space, and coding requirements for all this will be minimal. You will notice that I did not mention artwork here...

Cheers.

[Mark_Everson]

Well, we've discussed this idea before, although not with the wrinkle of not actually saving the mini-squares... which certainly makes implementation more practical. I'm going to follow my self-imposed rule of not discussing in detail things that are quite a ways off. (IMO its more like a Demo 10 topic) Do you mind shelving this discussion 'till much of the required things for the game are in place? It seems your idea could easily be a late-implemented feature if we decide we want it.

I'm with you on your thoughts for what to do on D6, but we should have a dedicated thread for discussion of those issues starting fairly soon.

[Gary Thomas]

Sure.

I just mentioned it at this stage to get it on record.

Cheers

[Simon Loverix]

More detail means more realism, so that's great. Watch out for micromanagement though, but you know that of course.

Can the terrain change from four categories to a range of 100-0%? 100% then means 100% usable ( 100% flat) while 0% means there really isn't any space for anything, agriculture or buildings (mountain peaks). This would avoid Discontinuous jumps and it's probably easier to generate too. And I can do food sites*terrain to adjust food sites for terrain. Four categories would be too restrictive, but we are used to them from Civ, probably.

[Gary Thomas]

Sorry, I don't understand what you mean by "four categories".

Cheers

[Simon Loverix]

I mean flat-rolling-hilly-mountain, which is similar to certain terrain types in civ.