Openciv3 - Terrain and map

[amjayee]

I agree with what you said. If we want natural disasters, we need to use tectonic plates, and more complex climate system. It doesn't need to cover everything, so it will be relatively easy to make, but of course requires more work than civ2 system. If those are made well, it is easy to create more realistic fertility etc. division systems. I also liked the idea of ocean creation. I will consider these things and post some thoughts soon.

[The Joker]

Have we finished a model on this subject? If not, shouldn't we do so? It is, after all, the basics of the game, so in order to give the programmers something to use we should get this one done sometime soon.

Sad that Guildmaster hasn't shown up lately.

[Guildmaster]

i'm still here, just been at work a lot lately.

here's what I was thinking:
i have always favored the continental drift concept of global design, start with plates, move them around a bit and let the world make itself.
Here's how it works creating the world:
start with a plain map grid, then strike it with something, eggshell type impact or something with all sorts of cracks fanning out in every direction, to simulate a cataclysmic collision that began a process of unleashing life-giving gases or something to that effect. Then you figure sub-crustal convection currents moving at one rate at the equator, while moving at another rate nearer to the poles. Assume that all plates will move according to these convection currents. (this same information can be used to great extent with future technologies like geothermal electricity) At the same time, you also figure trade winds will follow a set path and assign a monotonous linear jet stream to the map grid. As the plates collide, dissappear, break into more plates, grow, etc... elevation gives rise to alterations of these wind currents. This becomes the basis for forming the moisture and temperature models.

By determining how the plates collide and using the same magma movement for convection currents as described, we have a solid foundation with which to give certain areas earthquakes and volcanos, and with the weather information in place we can do the same thing with hurricaines, tornados, and etc.
This is why I ordered the stats as I did, because each pair of digits is a determining factor for the next pair. Anyway, the player can decide how long the world-making process has been going on, mich like in Civ2, but with much greater depth. Once time is allowed for erosion and all that jazz, we get to use existing figures on elevation, temperature, latitude, moisture and fertility to decide on vegetation and the rest is pretty much set.

Except for one thing...
minerals.
I would like to propose the remaining bits be used for the storing of raw mineral deposits like coal, ores, oil, etc. Note here, that Fossil fuel deposits are most likely to be located at points that some millions of years ago used to be the most fertile of areas, that's another goor raisin to use the time-growth idea.

Suggested uses for terrain:
Infantry units would incur a defense bonus in terrain similar to the terrain it was trained/grew up in.
Some diseases would have special flags meaning it's only available in certain terrains/temperatures/etc.
Similar growing conditions can be popular among agricultural colonists, that they don't have to abandon foodstuffs they were raised to eat. Sometimes an area might be especially good for X food product, ie. pineapples grown in Hawaii are the best pineapples in the world. =Þ

More later, i didn't mean to abandon you guys

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

[The Joker]

Great to see you back Guildmaster!

Of cause your idea would be ideal for the map generator (although I don't really understand why it should start with a major impact on earth - could you explain, please?). Unfortunately it is pretty hard to make.

Therefor I think that we should start the design process of the game by simply completing the map system, so we can actually make a map to play with. The complex and brilliant tectonic plate map generator can wait a while.

------------------
"It is only when we have lost everything
that we are free to do anything."
- Fight Club

[Martin the Dane]

Sounds good, but I don't think having an ice terrain (T=10) is necessary, this should in stead be part of the (M)temperature (it almost is with the tundra, and sub arctic anyway), Temperature should be climate in my opinion.

As for gas, it's a good idea, but on solid planets this would be over the surface, and on gas giants surface would have no meaning anyway, so why waste one bit for each tile one something that should be part of a header.

quote: Originally posted by The Joker on 07-30-2000 11:12 AM 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

Why does the seasonal rain only apply to icy terrain?

I just realized that my minor change will have significant impact on whole map system, but it would make it lighter.

My proposal would then be:

The file header should contain the following:
An identifier lets say "OC30" for OpenCiv3
Gas or Solid
Elevation multiplier - mostly cosmetic, but nice to have
Hex size - tells the game how large the map really is, this will allow the creation of more detailed maps.
An index of the last 15+ bits of the hex. This could also be laced in a separate file.

Each hex would then consist of 24-32 bits where

The first bit (0) determines the exact type (referred to hence as T) of terrain.
0=Water/Air
1=Land/Cloud

The next three bits (1-3) would then be relative elevation.
Level 0-7
For the programmers this will simplify the matter as the first bit is the sign of a signed integer.

I have not thought the rest through, but I don't think the exact values of the remaining bits should be hard coded into the game. This would leave the next section looking like this:
Bit 4- 5 Features or roughness.
Bit 6- 8 Temperature or climate.
Bit 9-10 Precipitation.
Bit 11-12 Vegetation.
Bit 13-15 Fertility.
Bit 16-18 Base population limit. The number of people that can inhabit the undeveloped hex at no tech. (could be determined by fertility, climate, etc. instead)
Bit 19-21 Disaster code. (fault lines volcanoes etc. Two bits might be enough)
Bit 22-31 Special features, natural resources, etc.

BTW who's the programmers?
[This message has been edited by Martin the Dane (edited July 30, 2000).]

[amjayee]

Hi Guildmaster. What you said about map creation sounded good. Joker; the "impact" is needed to crack the Earth's crust into plates. Though I'm not sure was this caused by a meteor crash, or simply by the convection currents themselves; the currents could have been so strong, they cracked the crust. But anyway, we need a system to break the map into plates. That, like the whole creation system, will be rather complicated, but as Joker said, we will create a map drawing and storing system, then a map editor, then an automatic map creation system.

About mineral placing, they exist usually at mountaineous areas, or in areas where mountains have once existed. Some randomness will of course be used in this.

The uses for terrain sounded good.

Martin the Dane: I agree with you about that ice is not necessarily needed. About gas, that is also no needed; each map will have a "tileset" variable, which will tell how the tiles look like, and how the details of the map system works with that tileset. That allows us to create more varied worlds with simpler map system. The gas was used also in climate system, but I just realised, that we can simplify the map system by creating a separate "climate map"; we don't actually need to store the climate info for every tile, since it is quite global, involves latge areas at a time, and is always calculated according to certain rules. If we store all climate, wind, temperature and rainfall info in a separate place for the whole world, I think we can compress the space needed for it to at least one tenth, possibly even more. The map file would store only the info about drawing the map, and how it looks like on screen.

Same with resources; how much each tile can produce certain goods, depends greatly on certain set rules. We could compress the resource info a little - not as much as the climate info, but still - by having it in another file.

This system would also result in that it would be easier to model more complex rules to let the climate and resource production change depending on situation, if all that info would be inter-connected. This would also make the map creation system easier to make. I'm sorry I can't explain this better right now, I will elaborate on this later.

One more usage for the terrain system; ships could sail faster in ocean currents, and planes could exploit winds.

PS. Martin: I will be programming the map.
[This message has been edited by amjayee (edited July 31, 2000).]

[The Joker]

Hej Martin! Det er godt at høre at du er interesseret i projektet.

[heardie]

^Bump^

The thread is working again.

[ElmoTheElk]

Wow, how can this be the first post here since 31 July? Well anyway; there was a discussion the last meeting about the map and how to implent regions. Because I think this is rather confusing in the meeting log AND to give my own ideas about this I made some graphical examples og it. There are 2 'turn on the map' I made. The first pic shows us the first turn, x, and the second pic shows the new situation, some turns later. (This could be about 10 turn if you want some sort of indication.) There is a pic with the explanation of the colors located here.

Hope you understand what I made. Now open the discussion. To give some first things to consider:
- Should the regions be flexibel (as in this example)?
- Should the cities and fortifications be user build?
- What about the other civs regions? Are they visable?

I'll give my own opinion later when I have more time.
Elmo

------------------
Guns, Germs & Steel homepage
[This message has been edited by ElmoTheElk (edited December 12, 2000).]

[Guildmaster]

Hmm
I think we should at least have the possibility of more than one city in a hex, expecially in ancient times. I mean, the largest modern cities may be some 50 miles across while two of the largest ancient cities wouldn't even be 50 miles apart.

I think that a player who controls a piece of land should be able to decide how to divvy it up into provinces, and ought to be able to change the provincial borders without too much hassle.

Thirdly, I think it should be possible to have a national border split down the middle of a single hex. That would make that hex a hot-zone for future conflict, much like East and West Berlin during the latter half of the 20th century.

------------------
He's spreading funk throughout the nations
And for you he will play
Electronic Super-Soul vibrations
He's come to save the day
- Lenny Kravitz

[The Joker]

Interesting pictures. It is a bit hard to imagine it all, though. Hopefully when we get a UI we can make real maps and turns!

But to answer your questions:

quote: - Should the regions be flexibel (as in this example)?

Yes. Completely. But there should be limitations. First hexes far from the regional capital would give increasing corruption and waste (in some form). Second larger bodies of water should limit regions seriously. I think 2 hexes of water should be the max over which a region could span.

quote: - Should the cities and fortifications be user build?

Cities? No. At least not very often. A player could order a city built, but he could not decide whether people would move there. He could give them reasons to do so, either by giving them money or by forcing them, but this would be costly. Fortifications? Yes, I believe so. Fortifications would mostly be on city hexes, since these would be the ones most important to defend. But also for military bases etc.

quote: - What about the other civs regions? Are they visable?

Yes, I think they should be. In the UI I think we should have a lot of easy accessible buttons (maybe located at the left end of the screen), with which the player could turn on and off different map modes. There would be economic map, which would show all trade routes and other econ things, a military map, which would show armies and other units, a political map, with which each civ's area would have a coloured filter on top of the terrain (like the colours used in your map pics), and then provinces would be divided by lines, but would all have the same colour, a demographic map, where nationalities could be seen, a pop map with pop density, a terrain map, which would toggle terrain on and off, a raw materials map, which would show the raw materials and animals on the hexes etc etc.

Generally having all maps turned on would make the map impossible to view. So the player would turn maps on and off depending on the situation.


Besides all this I think that when the UI has come a bit further we should "reopen" this thread, and the whole map discussion. The map is a truly important aspect of the game, and it is the thing we should be working on after the UI. And if it is possible to trim down the hex properties, even if it's just a few bit, would be pretty good, since we will have over a million hexes in the game.

------------------
"Damn those nazicommunists."
- McBain

GGS Website

[amjayee]

Interesting pictures, Elmo, much what I think the thing should be! Good! As soon as we get somewhat finished with the UI, I will make the map drawing thing compatible with it, and then we can make the final map system. Shouldn't be very long until that, if things go well... During January some results be at hand.

About the map and regions thing, I agree with Joker. About the region border, I think usually they should be between hexes, but as Elmo pointed out, if two factions are arguing about some land, the border could be in middle of a hex - or in some other special case. And about fortifications, there could of course be also fortification lines, long chains of fortifications, but those are quite modern things.

I'd like some agreement on the map graphics; I have become to agree that we should use the straight above view of the terrain, it is better that way, and easier to make also. If this is agreed to by everyone, then there are some further things as a consequence of this; we could not use similar isometric tile, city and unit graphics as in civ2, if the terrain is looked straight above. I suggest therefore, that we use "satellite photo" style graphics for terrain and cities - of course more beautiful, but not like earlier. For units and fortifications etc. we could use small icons instead of isometric images of the units, or animated images. This is more simple, more realistic looking and since we will use armies, also more clear. The icons would be made so that they tell as much as possible about the armies they represent.

This would decrease the amount of work, and clearly put the game graphics apart from other games; in my opinion, the traditional civ style graphics are quite out of date, and quite stupid looking sometimes, even more so if 3d rendered units are used. With good design and artistic vision, our graphics would look beatiful and stylish, the terrain would be much like a satellite image, though more illustrative of course, and warfare would be more clear and strategy-game like - it is after all most important that the situation looks clear and doesn't have any extra things to distract the attention.

So, what do the people think?

[The Joker]

Having borders between hexes would propably be a pretty nice feature for certain troublespots. But wouldn't it be a bit hard to implement, with production, population etc?

Graphics:
I think that will propably be the best. It would make it a bit hard to see different elevations, but we just have to find a way to do that. And I think using unit icons would give the game a cool, chess like feel. We just have to make it all look nice, and make everything easy to distinguish, or the game will be too hard to play.

------------------
"Damn those nazicommunists."
- McBain

GGS Website

[The Joker]

With elevations I meant land elevations, that is whether it is by sea level, or high up in the mountains. The units don't really have anything to do with this. Although I think it should be possible to have several units on the same hex - first air units would not even be on a hex. They would just go from their base (airfield or carrier) to the place of action, do what they have to do and return home all in the same turn. So there wouldn't be any air units on any hexes, at least not other than where they are stationed.

Other unit types, however, could be on the same hex. I think with normal units you are propably right, there should only be 1 per hex (although allied civs could share hexes as in SMAC). But if we have spies or terrorists they should be able to be in a hex where an army is also present. There should then be a certain, small chance of them being discovered, in which case they could be killed or sent back to the home civ, or exchanged for other stuff or something. And the whole concept of guirrella (I don't think I've spelled this right) warfare would be lost if such units couldn't occupy the same hex as another unit. They would just be hidden, and like with spies and terrorists there would be a chance of them being discovered. This would, like spies and terrorists, depend on the terrain. Guirrella units would be least detectible in jungles and mountains, but easy to detect on grassland. Spies and terrorists could easily hide in large cities.

And actually I was not the one bringing up the idea of divided hexes. It was Guildmaster. Like you I like the idea for it's gameplay possibilities, but I fear it would be too hard to program. Couldn't we have border conflicts without splitting up hexes?


Guildmaster:

Since we Europeans have a majority here, we will be using kilometers in stead of miles.

But anyway, I can see your point in having more than one city per hex. But I don't think it would be required much. Basically the hex is the smallest entity we have in the game. So what is important is, how many people live in it, and whether it is a city or not. So there might be two cities in a hex, but we wont have to model it as more than one city. It could just be made like one larger city.

And I totally agree that for gameplay issues province borders should be easily changeable.

[ElmoTheElk]

I agree wit most of the things you say.
joker: it's a very important thing you say there. everything has to be distinguished easily. very important because of the playablility of tha game, escpacially for new tbs-gamers.
elevations are a whole new thing I don't think we have discussed troughly. I personnaly don't like the idea of having mutiple elevations other than sea/land/air/etc units. So no unit can cross an hex already occupied by an enemy.


amjayee:
joker was the one who gives the idea of seperated hexes, not me, but however I also like the idea. BUT it will be very weird to program because of the pop and econ models (and the others as well). 2 civs in 1 hex isn't a good thing...
3d rendered units are a good way to make the game look good. also it is a pre that all the army icons have some general information. this should include 'health', 'power' and '# of units'. the look of the map is a total other point. the terrain should not be as boring as it was in civ1/2, however it isn't a good thing when there is no structure in it. whenever we should render, draw or photograph the map, it should not distinguish the player from the real gameplay, what's most important.

more later.