Openciv3 - Terrain and map

[Guildmaster]

For this we have the following... I remember if it's too complex even today's most advanced computers would get bogged down, yet if it's too simple it won't be worth playing. This system would provide a simple 8 bit code for each tile and save a lot of memory too.
00 00 00 00

Terrain
00 - Flat
01 - Featured hills
10 - High steep hills
11 - Rocky mountainous
Rainfall
00 - Dry desert
01 - Moderately dry
10 - Rainy
11 - Rainforest
Temperature
00 - Frigid arctic
01 - Cold temperate
10 - Warm temperate
11 - Hot equatorial
Elevation
00 - Sea Level
01 - Up to 500 meters
10 - Up to 2500 meters
11 - Above 2500 meters

All other things like groundwater, rivers and fertility can be a factor of there four.
As for fertility, I don't think it's important in game terms. Basically most flatgrassland is equally arable. To represent superior soil, we could simply have crop or food bonuses for certain areas like flood zones, volcanic soil, etc. Or we could just go on a combination of the above figures. Ever notice that the more rainfall an area gets, the worse it is for growing things? More mountainous areas would generally have better nutrients, ane riverbeds especially would also.

As for water, there needs to be a toggle for ground water?
Well +/-
River +/-
Navigable river +/-
Lakes +/-
I don't know how you want to do this, nut I will think on it.
Something like if groundwater = no, then next tile if groundwater = yes, then specifiy
I dunno

Ocean... How do we want to do the ocean tiles?

[dan ward]

I thought SMAC had a nice model for ocean tiles. IIRC there were several different depths similar to altitudes for land tiles.

[Victor Galis]

Correct me if I'm wrong, but "00 00 00 00" is one byte, allowing us to make tiles about 5 times as complex without worrying about size of the map, right? (Or am I totally insane)

[amjayee]

I have also been concerned about the memory usage of the map. We have to find out what's the best way of doing it.

About your suggestions, something like that could be used. I think that it is a little too simple, though, the terrain should be more varied. But let's think about it. Perhaps in the Sunday evening meeting we can talk those things.

One of the things to decide is the tile size; I have earlier suggested that the tile is 70 kilometers wide. We should decide the tile size and stick with it - that would partially decide the scope of the geography of the game. With 70 km tiles, the map of our earth would be about 570x330 tiles = 188100 tiles... wow, sounds like a lot to me. If we want to keep the map < 1 megabyte, one tile must not be larger than 5 bytes - which might be too little.

But in our world, most of the action takes place in Europe, so we might want to make a little unrealistic map, with relatively large Europe and Asia and smaller Africa and South America.

Well, anyway, just thinking out loud. What is the medium map size, that you would tolerate? It needs to fit in the RAM. Myself, I have plenty of memory, and I might go up to even 30 megabytes or more a in single-player game. Multiplayer maps should of course be smaller.

About ocean depth: Yes, oceans also need to have varying depth - possibly affecting what ships can navigate through that tile.

[dan ward]

There are 256 unique values in one byte (2^8) so memory shouldn't be too much of an issue. We should probably concentrate on making a map that supports great gameplay rather than worrying about memory or realism.

[amjayee]

Well said, dan.

So, gameplay should be the issue, also trying not to make the map too large in memory.

Guildmaster's proposition could be the basic idea how the map would be stored, ie. using bitfields of c++. We just need to think of the tile properties, and the value ranges.

It's not a necessity to have only four values per each property. In bitfields, we can use any number of bits - so there can be 2, 4, 8 etc. values. Also every property need not to have the same amount of bits. I stated that we might want to keep the tile less than 5 bytes, but that's not a necessity. With five bytes, we can have 13 properties with 8 values each, or 10 properties with 16 values. So, let's think of the best choices, without going into too much detail. Here are some things that need to be done, at least.

1. Tile type. This could be single bit - 0 for ocean, 1 for land - or there could be multiple values for each "watered tile" type. For example; ocean, river, navigable river, freshwater lake, coast, dry land, islands. Though the islands we can live without.

2. Terrain, like Guildmaster suggested; from flat to rocky. Though rocky doesn't necessarily need to mean mountaineous - if we have a tile with low elevation and rocky terrain, It would have cliffs, etc. Four values might be enough.

3. Rainfall also similar to Guildmaster's suggestion. We might want to use more than four values, though... but less than eight, perhaps. Four sounds too little.

4. Temperature likewise. Perhaps we could have five values, with middle value, temperate. Perhaps rainfall should also have a medium value.

5. Elevation needs more values, eight could do the trick. We could use the same value for all tile types. With ocean and lakes, it would be depth, with dry land it would represent height from sea level. With coast, the steepness of the coast. With river, it would be the elevation, and the steepness of the river valley, etc... But these we don't need to care about, the map creation and drawing system takes care of these.

6. You seem to have a point when you say that fertility doesn't play such a great role, but I don't know... Perhaps the "crop bonus" thing could be done with a simplified fertility property? four values, for four different bonuses?

7. I liked the "special terrain" idea. Perhaps with some bits we could make flags to allow some special terrain types. Flood zone is a must - the Nile valley would be one, Jangtse another, Ganges, Euphrat, Mississippi, etc... River valleys would always be good for food production, but the flood zones especially. River and flood zone combined with a soil bonus, and that is the best food producing place available. There should be only one or two of those areas per Planet.

8. One thing gone missing is the "vegetation" property. This goes from grassland/savannah/prairie to thick forest/taiga. Four values for this might be too little. But we need to find out.

Does someone want to add something here? With these, I think we could get a very good map system, with some old things, but plenty of new things. Plus, it can be done with the map system I have been testing. With it, the medium map should be under one megabyte. In multiplayer, we could zip the map file... and after all, it is sent only once. When the map changes (after some kind of catastrophe, like desertification), only the changed tiles need to be re-sent.

In the beginning, we would do fine with this map. Some things that need to be included later, is the population of each tile - this would be done with a single unsigned long variable, telling the number of people living in the tile. Another is the resources, but those could be stored in a different place, so the player cannot access them before he learns about the resources in question.

Yet another would be the diseases and natural disasters, like earthquakes. The system should be that these are geographical features - some areas would be more risky for earthquakes, and diseases would live in tiles, but also these could be handled by a separate component.

[Victor Galis]

I think temp could be determined by some formula involving elevation, latitude, and nearness to large body of water. It would not make sense to be able to place an arctic tile on the equator.

And I think some of the fields do need more values.

[amjayee]

It will be determined by a formula, but still it needs to be stored in the file. It makes no sense to use the formula every time you need to know the temperature.

I agree about more values for the properties.

[Guildmaster]

The revised terrain model is as follows:
Start with a 20 bit code having pairs of numbers:
00 000 00 000 000 00 00 000
These pairs coorespond with variables designed to give information to the map. BTW, they are in the order they are in becasue each one affects the ones following progressively, as the last grouping is a factor of all previous groups.

The first pair determines the exact type (referred to hence as T) of terrain.
00=Water
01=Land
10=Ice
11=Gas (mostly used for alien worlds)

The second group is a trio for (E)elevation. For T=00, this is a negative number for meters below sea level while for T=01 and 10, this is meters above sea level. For T=11, this is meters above available surface or highest atmospheric pressure.
000=At or below sea level
001=0-30 meters
010=30-100 meters
011=101-300 meters
100=301-700 meters
101=701-2000 meters
110=2001-4500 meters
111=Higher than 4500 meters (V=00)

The third group of knumbers is terrain (F) feature. IT's the same for T=00, 01, and 10 except that for 00 it's all underwater.
00=flat
01=low slow to rolling hills
10=steeper foothills
11=Rocky, cliffs, and mountainous
For T=11,
00=clear
01=light stratus clouds
10=pillow cloud cover
11=big thunderhead

The fourth group is another trio which refers to (M)temperature. These are the values for T=01, and 11.
000=Tundra
001=Sub Arctic
010=Cold Temperate
011=Temperate
100=Warm Temperate
101=Sub-tropical
110=Tropical Equatorial
111=Too hot for human habitation
T=10 is the same except that 101 refers to arable permafrost, 110 is permanently frozen, and 111 is too cold for human habitation. Also for T=10 there is no M=011 or 100.
For T=00, the ranges go from 000=cold arctic waters to 111=warm tropical waters.

The fifth group refers to (P)precipitation
For T=10, precipitation is in snow
000=none
001=Dry
010=lightly rainy
011=moderately rainy
100=Rains frequently
101=for T=10, light seasonal rain
110=for T=10, heavy seasonal rain
111=Rainforest

The sixth pair is modified by the first pair, and indicates rivers (R) available depending on the T variable:
For T=00
00=No river
01=Fresh Water Lake
10=Shallow Ocean Current
11=Deep Ocean Current
For T=01
00=No River
01=Small creek of stream
10=Irrigable river, but not navigable
11=Major Navigable river
For T=10
00=No river
01=Liquid running water
10=Ice/water River
11=Glacier
For T=11
00=No stream
01=Small air current
10=Trade Wind
11=Jet Stream

The seventh pair determines (V)vegetation. Now this is where it can get a little tricky. Let's start with T=00
00=none
01=coral reef
10=kelp bed
11=thick algae and seaweed (zero visibility)
For T=01, M=101+
00=Sandy desert
01=Dry Grasses and scattered trees (savahanna)
10=Tropical forest
11=Jungle
For T=01, M=011-100, except for E=111
00=Grasses & Plains
01=Grasses and Shrubs
10=Light woods (E=011- deciduous, E=100 mixed, E=101+ evergreen)
11=Thick woods and undergrowth (E=011- deciduous, E=100 mixed, E=101+ evergreen)
For T=01, M=001-010, except for E=111
00=Mostly undergrowth, scattered trees
01=Deciduous forest
10=Mixed forest
11=Evergreen forest
For all of T=10, and for T=01, M=000
00=No Vegetation
01=Light Grasses Only
10=Scattered Evergreen Trees
11=Light Wooded area

And lastly, we have (L) fertility. Fortunately for me I don't have to type as much here because it's pretty simple, and it's the same fertility rate for all terrain types, although a factor of all previous figures.
000=Nothing will grow here
001
010
011
100
101
110
111=Volcanic Riverbed soil

Please enjoy my terrain engine. I believe this would allow the greatest flexibility and at the same time conserve memory over a 32-bit code. Additional terrain aspects could easily be programmed into it and variables could be modified for superior gameplay. By having factors of factors (ie. different temperatures for different terrain types) it's like running through a gear converter. This allows a smaller code to define a greater range of variables.

------------------
Goober

[amjayee]

Very good, Guildmaster! You have put a lot of thought to this. It looks very good - especially the idea of rivers also in ocean and atmosphere! I'd have never thought of that! Thanks.

I might like to change some things, perhaps at least in the vegetation part, and perhaps add something to cover the remaining 12 bits, but the overall idea looks very good.

[The Joker]

About elevation:

I think we could use a SimCity2000 type system. In stead of having below and above sea level as elevation properties, how about just having an elevation value - preferably a lot of these (16 different if possible). This will all be settled before any ocean is included, and will give a world in which the lowest elevation would be 0 and the highest something like 18000 meters high. We could then simply add a sea level, which will mean that all tiles above this are land and all below are sea tiles? I think that this would not only make sence, but also be a good and workable system. This way we could have a global warming scenario, where the sea level rises "one level" thus flooding the lowest situated tiles?

I am not sure if the sea level should be universal. It could be nice to have inland tiles that were below sea level, and lakes in the mountains that were way above it.

[amjayee]

Yes, that's another possibility. We need to test and find out. But, the ocean level would not in any case rise very much. I have heard that in our world, the level would rise by about 70 meters, if all continental ice would melt. And about land below sea level, there are not very many places in our world with elevation lower than the mean sea level. About lakes in mountains, it would be possible to make them. But we will test different ideas. The best solution will be used.

[Guildmaster]

Question: What do we need the other 12 bits for? I mean, if we can get away with using only 20 or 24 or whatever, wouldn't that save both time and memory? I'm all for making a more complex game, but I think think we need to make up stuff to make it more complex just to fill up 12 extra bits.
Unless you're talking about reserving the other 12 for civ-related info...
Perhaps 21 would go like
0=no civ
1=civ present
22-32 would define the civilization.
But wouldn't we need more than that?
Or do you want to save the other 32 for in-game alterations on terrain, such as swamps turned into rivers, ****s built up, etc.

gotta go, bye

[amjayee]

We will need at least those 32, don't worry - I will send some more detailed thoughts later.

[The Joker]

Here is a suggestion for how to generate a world. It offers some of the advantages of the "real world" map generation, but it's still really simple and easy to make.

The world would be generated in steps, each of which should be very easy to do:

1: The world is didived into 10-20 tectonic plates of varied size and shape (randomly chosen). All hexes are a part of a plate - the borders between plates go between hexes.

2: Each hex is given an altitude and an inclination. Both should not be very extreme.

3: Each plate is given a direction, one of the 6 possible via the hexes.

4: All plates are moved 1 hex in their direction. When 2 plates move apart (1 or 2 new hexes are made) there will be formed a new, smaller mountainrange at that place, with the highest altitude at the newly formed hexes (like the one at the bottom of the Atlantic). When 2 plates move opposite ways besides each other nothing happends (for now. In the game that area would be very likely to see earthquakes). When 2 plates move over each other, so hexes are "lost", it is a little more complex. If one plate at the hexes that are lost lies significantly higher than the other then this is pushed on top of the other plate, creating a mountainrange at the hexes on that plate near the border of it. The lower situated plate is pushed below the higher one, and a deep sea grave is created in the hexes on that plate near the border. The mountainranges and graves created has varied depth/altitude. Some would be narrow - only a few hexes wide, like the Andes, where other would be wide - up to 20 hexes (assuming a hex is 50 km wide this is 1000 km) wide. When two plates collide and their altitudes are somewhat the same both hexes would be forced upwards, which creates a tall, wide mountainrange in the borderregion - like the Himalaya.

5: In a later and more advanced model there might be several of these steps to make a more varied terrain, but with the current system if mountain generation it would be pointless.

6: Now smaller structures like hills, small mountainranges (no more than 2000-2500 km tall), valleys and such are created. For now this will just be done with a standard Civ2 type map generator.

7: Ground fertility is determined for each hex. I don't really know how this is determined in reality, so for me it would be fine to just do this randomly. Of cause it would be better to do it with a simple, yet realistic model.

8: Oceans are added. It will start by filling out the lowest placed hexes, and then fill 1 elevation level at a time, while calculating the percentage of hexes being under water. At the beginning of the game the player would choose the percentage of the world he would want to be ocean. When filling the hexes of the world with water, it would continue to check the percentage of hexes being under water with the percentage wanted. Sea level is set where the ocean percentage is closest to the wanted one.

9: Lakes are added via some model (large valleys tend to be filled with water or something) and rivers likewise. Rivers would of cause only run downhill.

10: Temperature is added via a model invluding longitude, altitude and closeness to water.

11: Rainfall and vegetation are added. This is a somewhat tough job, as they depend on each other (if it wasn't for the rainforest the Amazonas would be really dry). It should start by having some wind patterns, rain coming in from the sea and such. This would then create vegetation, which would change rain patterns. This should be done for several "turns" untill a realistic world was made.

We should now have a world!