Openciv3 - Terrain and map

[ElmoTheElk]

I really like the way you have such innovative ideas If we can program it this way, that means we can easily save memory. But 1 thing: can we use this method for all map related data we ned to store?

[Leland]

I think it's possible... hmm... needs some thought, however, and I don't seem to have time for anything but to toss wild ideas around . The way I see this, in the game there'll be need for three kinds of spatial information: tiles (units, cities, improvements), paths (roads, trade routes, unit movement) and areas (regions, diseases, AI). The question is to find the most approriate structure for any particular situation. I feel that having a conventional map on top of which different kinds of things are layered is sensible since it's a lot easier to handle and because decomposing different terrain characteristics to areas it becomes really complicated. Areas aren't really the best way to describe mountaintops, small island groups or rivers.

[amjayee]

Hmm... here are some answers to some questions.

I think 20 km tile might be too much. 50 sounds good - if it takes only 240000 tiles to describe the whole earth, it's only good, since the map will be the most demanding thing.

I have also been thinking of ways to make the memory needed by the map smaller. One way is of course simply to reduce the amount of memory each tile requires. But having 256 tile types doesn't sound good - we are not after all having tile types, but several properties for the terrain. Those properties are needed also for modeling climate and environmental catastrophes etc., so we quite can't use simple terrain types - and this wouldn't make the memory usage considerably smaller, since the tile terrain info will be only one small part of the memory needed. The old system shold be better fro this... though I should revise the system soon.

I have also considered compressing the map data somehow; and at least when saving it on the disk it will be compressed. But I'm not sure if it is convenient to have the map compressed in the memory, since the data is accessed millions of times per turn. Old arrays sound the best thing to have - they are easy to use, and also data is stored logically so they are fast to access. And memory usage should not be very problematic when the game is ready. But everything will be considered, it's just that we don't yet know excactly what the map system will be like. But if we can save memory without slowing down the program very much, it would be good. We'll get back to this when we start to implement the map.

About map-based system, I agree it would be good to store everything in tiles. But we'll have to see what's best. After all, there will be less units than earlier, so storing unit (army) id's in tiles would be entirely possible. Same applies with most other things; Simpliness and fast access are good, if the memory usage doesn't increase too much. Once again, we'll have to see what kinds of things are needed.

[ElmoTheElk]

I agree about the terrain issue. I don't exectly know how many properties we got, but let's say there 8, then we already have 8^2=64 differnt terrains.

[Leland]

Actually, that'd be 2^8=256 terrains. Each new preperty with simple true/false value takes another bit.

I can see amjayee's concern about the map size; the proposed > 1M tile maps are BIG, a few orders of magnitude larger than in any competing games. And 256 values for each tile is not enough. However, map is going to be the kind of thing that is used only once, and the requirements won't (hopefully) become any more demanding in the future. According to Moore's law, in two years the average pc will have memory capacity around 512 megabytes, and if the map size is, say, one hundreth of that then it doesn't sound like such a big deal. And it will only become less and less significant when years pass. That's why I'd go for the more detailed map.

I totally agree that more properties are needed. For instance, in addition to basic terrain typ ethere could be information stored, as amjayee suggested, for the existence of unit, cities, certain improvements and whatnot when the actual information about what units or infrastucture there are is stored elsewhere. For example, following flags can be used:

1. units/no units (queried when moving units and such)
2. roads/no roads (movement bonus)
3. agriculture (food production bonus)
4. mining (metal/other resource bonus)
5. city/no city (also fortresses, outposts...)
6. disease/no disease (population is going to be interested in this)
7. inhabited/uninhabited
8. (what else???)

Also there is the issue of different climates and natural disasters... yikes.

[amjayee]

I had once a pretty good view of the map, sad I didn't make any detailed notes. But I do remember most of it. One of my main ideas was to store the key properties for all tiles in a grid, and "compress" the more rarely used ones, like climate and such in some other way. But anyway the map will use much memory. I was once hoping that we could get averagely 10 bytes per tile; so the map would take 5-10 MB, depending on the size; when saving to disk, this would of course compress quite much, I think at least to some 0.5-1 MB. But still this means we can't keep sending all map info around in MP games, but rather the data that has changed.

Another issue is the map drawing thing; when the map is "drawn" to the memory (which will be done since we use DirectX) it will take much more memory than the ordinary map with only the properties saved. So, we simply must draw only the portion of the map that is visible. But that shouldn't be a problem, I have already thought of a way of doing this.

[The Joker]

I'm back. And starting from where I left off.

First, due to my limited programming capabilities I can not say much about Leland's proposed area idea. My initial thought would be, that often using tiles would be cooler, especially for things like diseases, since diseases can't really be said to exist on a regional basis.

Using areas would at least require a lot of work, since the computer will have to be able to create them itself, and do that intelligently. So a lot of grassland tiles right next to each other should be in the same "climatic" area, and therefore diseases should be done on that level.

Hex properties:
I know that the 2 byte system sounds more cool, but I just think that with some thought a 1 byte system could be made equally so. For examble, there is no need for all "basic" terrain types (or temperature areas) to have the same amount of subcategories. Arctic terrain should pretty much be limited to a few different altitudes, and a bit about whether it is ice or tundra. Due to the cold vegetation simply does not occur like it does in a tropical hex.

I think that if we think about this we can make it work.

Number of hexes:
I think that having loads of hexes would be extremely cool. I truly love the 1 mio hexes "feel". And so I think having all those hexes would not only make it possible to have more players, it would also set our game aside from the competition. And doing this maybe 20 km hexes might be better.

But on the other hand we could just as well make an earth map a medium map size, with a few hundred thousand hexes, and then have larger ones that goes up around and above the million hex limit.

Could this make sence?

------------------
"Life is a lesson. You learn it when you're through."
- Limp Bizkit

GGS Website

[Nath]

I'm not sure what was finally decided upon, but here's my suggestion anyway.

50 km hexes with these terrain types:

0 00 00 00 0
A BC DE FG H

A:
0 - land
1 - water

----

B, C:
(for A=0)
Elevation
00 - 0-500 m (low areas)
01 - 500-1500 m (hilly)
10 - 1500-2500 m (mountainous)
11 - >2500 m (mountainous)

(for A=1)
Depth
00 - 0-200 m (continental shelf)
01 - 200-2000 m (partly open sea)
10 - 2000-6000 m (open sea)
11 - >6000 m (deep)

----

D, E:
(for A=0)
Rainfall
00 - 0-40 cm (desert)
01 - 40-100 cm (land)
10 - 100-200 cm (rainy land)
11 - >200 cm (often flooded)

(for A=1)
D:
0 - freshwater
1 - saltwater
E:
0 - calm
1 - stormy

----

F, G:
Temperature:
00 - <10 deg. C. max
01 - 10-25 deg. C. max
10 - 25-40 deg. C. max
11 - >40 deg. C. max

----

H:
(for A=0)
0 - normal land
1 - forest
(exact nature of land decided by temp., rainfall etc.)

Alternatively, H could be used for rivers and currents.

[TempLeland]

Hmm... I'm not so sure if anyone has thought about these issues since last year, so no decisions to any direction have been made. All we know for sure is that the tiles are hexagonal and that there are a lot of them. Thank you for yoru input, I think it's nice to open this thread as well, especially now when there is a remote chance for someone to finally get the time to start programming the map...

I think your proposal is appropriate for one year turns, but if we're going to support shorter time frames (winter/summer, four seasons, bimonthly turns...), we're going to have to separate terrain and climate models somehow. The temperature, for instance, would change every year (climate) whereas forests are an example of a more permanent map feature (terrain). But, for the time being, at least I'm going to use your proposal as the basis of what I think of the map. We can probably revise the whole terrain stuff later when we need it for other models (so far, I don't see much connections... the resource production, for example, has hardly been discussed from this point of view).

By the way, how will different natural resources fit into this model?

L

[Nath]

By the way, how will different natural resources fit into this model?

I hadn't thought particularly about resources... I guess they could be placed on the map in suitable areas after the terrain itself is generated, and be treated as a separate object. Maybe the programmers ought to decide that.

Will there be different levels of resource richness (i.e. some areas rich in a particular resource, some moderate and some poor) or will they be present only in some areas (some tiles have an unlimited supply of copper or whatever throughout the game while others have none at all)?

[chrispie]

I like this idea, we do need to generalise at one point or another I think, having seperate bytes for things like temp seem like massive overkill on such a huge map.

When thinking of seasonal changes, I'm not sure how that'd fit in - but terrain doesn't change based on the season, and the change in temp in most places won't go outside of the scope of the set nath described I don't think - that is it's unlikely any location will actually change from one set to another.

It's more likely I think that the amount of food produced would be the thing that'd vary, maybe a set varient throughout the world.

So, if a hex in USA produced 10 food in one season, and a hex in Russia produced 5 in the same season, they'd change to say 7 and 2 respectively.

Yes/No/Crap/Good/Cool/Bad?

[Darkstar]

Ok, I want to clear up a few misconceptions you guys seem to have... At least from what I read... maybe it's me that's the misunderstanding...

If your map is 1M in BASE size, that means you are going to be using that in chunks, lots. Everytime you recalculate the climate, you are going to need another 1M. Every time you do any modelling, here comes that 1M size. And when you are DONE, then you copy back the finished product to your master. Since you were modelling an aspect, you are going to run code to look up the right master hex, change that aspect, and move to the next. That's a LOT of calcs...

The reason you can't use your MASTER directly, is that it's a cellular automata, whether you know it or not. You can't start moving people from starving city a to happville... it all has to update at once. That means copies... Make a copy of your model, recalculate, and then boost the results in your copy back to when you were done. If you are efficent, you just use master and copy of results. Inefficent, you copy your master, recalc that, and then go and update your master when done. That's 3 meg versus 2 meg.

Second... in most OOP, putting a unit in an Army doesn't get rid of the unit. That unit has properties you need, and is built/designed specifically for that. So you are not GAINING memory. You lose it. By the amount of the container (in this case, the Army), and any other possible overhead to track your "army" containers. Plus, your Army is going to be a command object. It does more then just hold the units. Heck, brand NEW units will be in their OWN Army, until they "join" (move unit ownership from old Army owner to new Army owner, now deallocate the old Army object as we are done with it) the "Army" you are integrating them with.

And that is just off the top of my head. The MAP is going to be your most used object in the game... thanks to display, if nothing else.

If you are going for a top down view... give up on the gorgeous graphics. How much wargaming experience do you guys have? That's the view and presentation you are talking. You can have gorgeous maps, but the Army icons aren't going to be that great. Get used to it. (You artists may consider that a challenge from the peanut gallery. Not an insult. Thank you.) Citys from the top down aren't gorgoes. Modern cities are ugly gridish things. At least most of them.

Why can't hostile units occupy the same hex? Heck, if a hex is 50km... that's a lot of room for ancient armies. Depending on the particulars. Maybe they are drawing up for battle. Maybe they just have lousy scouting and having lousy visibility. But even 50km on the open sea... heck, until radar, it wouldn't be unusual for navies not to see each other at that distance. And they don't have anything but a bit of haze between the two.

Second... you guys aren't keeping in mind high techish possibilities. Why COULDN'T I have my SF dirigibles floating over your armies heads for seasons? Right NOW, NASA has research planes that can stay aloft for 100 DAYS. Their goal is 2 years. Over the same piece of land... They aren't that far out, either. So you are ruling out sky bases, sea floor bases, and sub terranean units. Didn't sound like that was what you wanted ruled out earlier.

And yes, there ARE aspects of realism to this. For instance, American and Viet Cong units often occupied the same "hexes" in Nam... just the American's didn't know it. VC was underground. Had regiments living down there... under American fire bases! That wasn't the first time in history. Wasn't even really an exception. Tunnelling and underground construction has been used by many cultures, throughout history, as a means of procuring security from hostile forces, from man to the weather.

You can IGNORE this "height" factor. That's all it is... height. But it makes the game less "realistic". Especially navally... if I've gotten very advanced submarine techniques, compared to others, my subs can go deeper and stay down longer. So you could have.... my subs (deepest z), opponent subs (deep z), neutral ships (surface), and long duration air unit(high z) at one time.

If you DON'T ignore height, you gain a "map" for every height level. That's not 1M model... have 16 height levels, and you had just made made 16M, if you model is 1M.

Resources can be happenstance scattered about, or you can actually model their formation as we now understand. But that's more "height" information needed, so you know how deep it is, and how it moves over time, I would think.

Consider this though... wood is one of man's earliest utilized resources. And we have wiped out a great deal of that. If you are going to model the effect vegetaion has on climate, then you will be forced to recalculate the climate each time a hex of trees disappear... which is only "realistic". Timber was one of the primary reasons England was interested in North America. She had very little of the stuff left to make her wooden ships, and the truly good stuff was gone. It takes many ACRES of wood to make a wooden ship... or heat a town's homes... or fuel it's fire using artisans/craftsmen hearths, furnaces, and kilns. Let alone to build homes and tools...

Ok... I want to know something...
what is the difference between urban and rural? And why?

Any TOWN should be named. Doesn't mean you need to clutter the display with it's name all the time though. People have a place to call home so that other people know where that is.

I had some other thoughts, comments, and questions... but I've lost track of them at the moment. If they were important, I'll think of them again...

Be careful you aren't over analysising yourselves. It's better to get something and discuss changes (and make them) then to sit idly by and not do anything until real life drags everyone away.

[Darkstar]

Oh yeah!

Actually, you should find making your tiles diamonds easier. The isomorphic view is really an easy to use computer adaption of hexing. Trust me on this. You can still use top down, but it makes the graphic tiles meeting easier. I've got a play project that demonstrates this. You also get the full range of movement, and players familiar with Civ2 will intuitively pick up cursoring.

[Darkstar]

And the other question I've been meaning to ask... is the world map a globe or cylcinder?

[TempLeland]

Interesting comments. I'm just as eager as you are for someone to answer your questions, especially that thing about rural and non-rural hexes. I never figured out the distinction myself. I'd also like to hear more about your rationale for the diamond shaped tiles... "Trust me on this one" has never quite convinced me. But, real life is dragging me already, so enough for tonight.

The map is supposed to be cylindrical, BTW.