3d & Spherical maps discussion

[The Joker]

Nath:

You are right that there would be problems. I just don't know, really. The last time amjayee described his map system it sounded really good and thought through.

The graphics:
Well, I don't think there would be more than 16 of these combos. And I believe that we can find nice colours to fit them all. I don't know if it would be boring. It is possible. I just think that textures has to be done really well, or they will be really ugly. If every hex/area has the same texture it will look really bad.


Amjayee:

Sad about your lack of time. Keep in there, mate! (hopefully)

[Leland]

Even though I never have considered a spherical map to be of very great importance, I am beginning to see the advantages of amjayee's suggested map... anyway, I have some idle questions in mind:

In the old hex-based map the idea was that there are static tiles (smallest "pixel" in the map), which comprise larger areas (for example, populations, diseases), which in turn comprise regions (political entities). Where do these three levels fall in the new system? Are the areas going to be just differently shaped tiles (meaning, they will be static) or will the tiles really be totally discarded in favor of (dynamic) areas and regions?

What kind of data structures will/can/should be used to store areas?

There will be lots of interconnected things that are stores as areas: the operative range of military units, different terrain types, man-made structures (agriculture, industry, roads, pollution, ...), populations, population densities, natural resources, and I am sure I am leaving out a whole bunch of issues. Many of these have some effect on each other but will still be able to overlap, so how will the overlapping of areas be handled? What are the areas that can be formed to regions?

Is the map supposed to be 3d right from the start?

(I'm still in favour of discreet map, but that preference is based on superstition and guesswork rather than hard evidence, so perhaps discussion on this topic will clarify my mind to one direction or the other...)

"Leland"

[The Joker]

Good questions.

The way I think the map will be is that:

The areas are static. Their specs can be changed, but they can not be moved, combined, split or anything.

The regions would consist of certain areas. Therefore the regions will be dynamic - players can change them by different methods, although most would have some penalty.

Hopefully population, and perhabs some parts of economy can be handled via areas. This way players can not manipulate the game just by changing regional borders.

So each area has a population and is one terrain type. Therefore production for all the people in the area working with one thing (it is possible for some to work in mining and others in farming) will be constant. Likewise with many manmade structures. Although some things - like taxes, politics and research - should be handled at a regional level in stead.

I think military units will be handled pretty much like they would in a totally gridless map with no areas. The deployment range and operating range are circles around the unit, their areas depending on the units movement points. Only here each terrain type consumes a different amount of these points. So in stead of a circle it will be some kind of odd figure, based on the terrain surrounding the unit. I am sure there is a rather simply way of programming this.

But yet, let's have a discussion!

[Leland]

Having thought this alternative some more, I suppose I can hop back in to this lively discussion...

First, I don't think areas can be completely static. Terrains do change from deserts to forests, from land to sea and so forth, both by natural means and via human intervention. The map will have to incorporate this by changing the properties of the static areas, or by altering the boundaries of areas accordingly. for example, when a desert from southern areas expands to north it can be done either by decreasing the vegetation and humidity attributes of northern areas, or by making the southern area larger and the ones in the north smaller. My opinion is that former is less realistic and defies the purpose of having areas instead of tiles (because if you don't know e.g. the position of the desert, you can't lump it into one big area instead of a lot of smaller ones), and the latter pretty much requires the areas to be dynamic.

Not that it matters much: I think that the concept of areas itself is complicated enough and making then dynamic is trivial once you get this idea working in the first place.

My main source of skepticism is in the tradeoffs that have to be made to achieve this map. Yes, I acknowledge the advantages involved. We'd have a much more generic system that I believe will stand the test of time pretty well, an inherent support for all sorts of map topologies, memory saving in the sense that we would not need as many tiles/areas, as well as graphically more "natural" looking view. But there is no such thing as free lunch. I did some hasty back-of-the-envelope calculations, and it seems that the memory consumption of this kind of map will reduce the number of areas with at least one order of magnitude:

• At least 2 bytes (numbers between 0-65535) for each coordinate axis, making 3d coordinates 6 bytes each. This gives the map roughly a granularity of about 1 kilometer/pixel. For more fine-grained map, more bytes have to be used of course but in this example I am trying to approximate the smallest possible space required.
• Minimum of three vertices for each area, though only the smallest areas can actually be simple triangles. So, let's make a rough estimate that an area has approximately 4 vertices, like a rectangularily tiled map.
• That makes 24 bytes per area. We need one more byte to tell the number of vertices, so just the geometry will take 25 bytes.
• A 3d wireframe alone won't explicitly tell which areas are adjacent to each other, but we need this information for immigration and trade. Let's assume that each area has a unique number by which they are referred to. Since there has to be support for at least 100 000 areas, we'll need 3 bytes for this (I am not getting into individual bits here, but 2 bytes would set the upper limit to 65536, whereas 3 bytes can represent a positive integer up to 16 777 216).
• Each area has 4 adjacent areas (except for poles, but I'll skip those as special cases), so we'll need 3*4=12 bytes per each area.
• Then, we'll still need the terrain properties for each area. I don't remember anymore how many bytes we thought we could spend on terrain and climate, not to forget vegetation and domesticated plants/animals, but off the top of my head let's throw in 4 bytes.
• 25+12+4=41 bytes per area. Multiply by 100 000 areas and you have 4 megabytes of terrain data. In comparison, if we used simple tiles we could skip all but the four bytes reserved for terrain. Conclusion: areas take at least ten times as much space as a conventional tile-based map of a same level of detail.

In addition, if the populations (whose number I used to imagine to be thousands, but not tens of thousands) are tied to areas that also increases the memory consumption, though it makes the population system more simple than our old workaround would. The computing power needed to process areas is also higher than the power needed for equal amount of tiles (because tiles are easily fit into 2-dimensional arrays), and this may force us to simplify the rest of the game. This is a design issue, of course... I am most fascinated by areas, but if we decide to use them then I think it has to be a conscious choice and we need to be aware of the tradeoffs that we'll be making. Is three-dimensional map really worth it?

Would it be possible to just combine point-based movement with tile-based production etc.?

On another note, I don't think cities should have a radius at all. I think that is ridiculous, cities do not accumulate resources just from the nearby areas but all around the world via trade. That's why I think cities should be just point-based population attractors and not have any shape on the map.

[The Joker]

Sorry for my absence the past week. I was on vacation.


Leland,

you do make sence. I have to say that. Although again I do not know enough about this to say whether you are right or wrong.

I do hope some one else with more knowledge than me will pick up this discussion. I can not.

So I have come to the conclusion that I will only follow the advice of whoever makes more sence. So for now I think Leland is right - perhabs the tileless map isn't worth the effort.

But I sure don't hope that this is the last thing said in this discussion.

[VetLegion]

the really funny thing is, we have discussed tileless map a long time ago shortly (I found the log) and unanimously decided that it is too much work for us. Now that amjayee brought it up again, I personaly think it is pretty neat idea. my conclusion is that we are evolving our opinions as time passes

now, I am not sure what amjayee meant with his ideas about this. here is what I think about the rationale behind it.

We have all been witnesses to long discussion about regions
As correctly pointed out (by Leland I think), regions with variable (dynamic) borders can not be used as containers for any other data, like population numbers and population properties. Instead we need some smaller entity with permanent shape and location, so that we could use that shape as basis for logical organisation of the mentioned data.

The intention was to use small tiles for organising it. So each tile would hold information about population density and population properties, together with elevation and vegetation data.
The number of tiles was never precisely established since it would depend on map size, but it would range from couple hundred thousand to more then a million.

There is no evidence or calculation to prove that it is impossible, but it feels a bit wrong to me. I think a lot of small tiles is somwhere between no tiles and few big tiles, but does not have advantages of any of those two systems.

Now, the tileless map.

How I see it, there would not be any tiles at all, and areas would be dynamic.

area - a closed shape of voluntary borders which may be regular but dont have to be, can be urregular. Areas show an area of the map with homogenuos properties.

area border - a continuous line that encloses the area. can be irregular

layers - a way to divide areas. important to note, that there would not be religion layer for example, but instead a layer for islam, a layer for catolicism, etc.

area intersections - areas do not intersect

all these layers would be 'above' the elevation layer (which is a basic map layer)

the number of layers will be relatively small, until the population properties set of layers, where we may have quite some of them.

still, I do not think it will be a memory problem.
amount of data needed to store areas will depend on area complexity or iregullarness of area borders. the more funny border is the more memory it takes to show it. for example, norway with all the fjords will take more space to show then Italy when it comes to elevation layer.

that is how I imagine the logical organization of the game data.

now, the map data is also represented this way. Map (visible) consists of elevation layer, vegetation layer, structures (human, alien, etc) layer.

to draw the map, we draw the elevation layer, on top of it we draw vegetation layer and on top of it structures layer. If map is 3D then there is tecnique to convert a 2D map (layers are '2D' so to speak) to 3D. actually there are many techniques, depending how complex do we want to have it. If simple area data in elevation layer is not enough for the 3D draw, we can have additional data in another layer. I d prefer to extrapolate 3D map from some data then to have 3D map stored, like structures are stored in quake or something.

on this map, we would use coordinate system to locate stuff. Instead of absolute system of meters, we can use a relative system, like meridians and parralels, which are angles from a point in the center of the earth.

for example Zagreb is on 45 nor., 15 east. and some city is on 45. nor. 25 west. the distance between them on earth is X km, but on a smaller planet it would be smaller and on a larger, larger.

units would have a center and a radious said before.
cities would be areas of highest population density (from the population density layer)

I think this is not what amjayee originaly had in mind but it is my addition to the discussion.

there are problems with some of the population stuff here, but I think I know solutions to them

[ElmoTheElk]

Well, all I can say is that this desciption looks the best I have seen so far. It's clear, makes sense and covers about all the features I (and if i am not right, we all) want to see in ggs.

Unless there are real objections, we could use this system. I also think memory usage will not be a real big problem, since the amount of memory will expand enormously the next few years. When ggs beta 1 playable will be released, a normal computer will have loads of memory, I think 512mb or 1gb will be the minimum for new pc's then. Also, cpu speeds are increasing rapidly...

That all I can say about it. The same as Joker had, I can't say anything more usefull..

Gr, Elmo

[Leland]

With the pace we're having now, when a playable version comes out, we'll probably have holodecks and quantum computers to toy with...

Anyway, a few things that I'd like to get a clarification to from Vet:

• The elevation would be a property of an area, and not a property of the vertices defining the area?
• When you say "areas do not intersect", do you mean "areas in the same layer do not intersect"?
• The difference between this latest suggestion and what amjayee said previously is that amjayee apparently intended the map to be real 3d, as opposed to just a 2d mapping on 3d sphere. But doesn't this mean that we'd need whole different algorithms for terrain generation and such, because we can't use the same coordinate system in both flat and sphrerical maps? In other words, this would not be as general as amjayee's proposal, or am I mistaken?

Now, back to my usual rants. The main issue about memory consumption is that there will be a lot of information stored just about the geometry of areas, and this information could be used for something else. And I am not at all convinced that the geometry data will be of much value to the player, compared to a tile-based variant which would use the memory to get a higher level of detail in other respects. To me, the oddly shaped areas just seem awfully confusing... perhaps due to my lack of imagination, I grant you that, but still I feel that it would be more clear for the game to have a bottom layer which is simple, uniform across the map and sets a clear "resolution" for the whole game. There would have to be regional system on top of that to hide the underlying tiles from the player, and furthermore an administrative provincial system on top so that the player can meaningfully manipulate the world.

Relating to this discussion, I've started wondering why can't we call regions provinces, like everyone else does? I believe the word "region" is closer to what we call "areas" (more or less "natural" areas) than what is meant by provinces (administrative areas).

Just to clarify my own stand a little but, what I am advocating is a three-way distinction: tiles-regions-provinces (or tiles-areas-regions, depending on what kind of terminology you prefer, I would gladly change mine). Tiles are the basic building blocks and they hold layered information on terrain, climate and population density, among other things. Cities, armies and human built structures are done on tile-level. Regions/Areas are collection of tiles that share certain properties, and do not overlap. Populations, diseases and perhaps the military presence could be stored in this level. The regions/areas would interact, however, and act like living organisms in a sense: this would be the level that makes the map dynamic to the player, and corresponds to areas in the continuus map. Regions/areas would be kind of like living organisms which the player tries to control. On top of them, there would be the provincial level which is directly imposed by the player and represents the political and military power of players. Provinces would comprise of areas, and their number would thus be another order of magnitude smaller.

With about 1M tiles, there'd be maybe 10 000 regions/areas, and maybe a couple of hundred provinces. Or that is what I would imagine, off the top of my hat. I think that if there are ten thousand anything in a map, the player will have little concern of whether they are free-form polygons or not.

(Hmm... I wonder if I made any sense... this was written in pieces during the course of 4 hours)

[Leland]

Okay, that wasn't probably very informative.. anyway, my opinion in a nutshell is:

Vector-based layered areas are bloody confusing from player's point of view: The relations between different layers are obscured because they lack a common ground, apart from the coordinate system. And I think it is cooler to have areas as an emergent property of a tiled system than to make them the fundamental property of the map.

There.

[VetLegion]

Originally posted by Leland
With the pace we're having now, when a playable version comes out, we'll probably have holodecks and quantum computers to toy with...

you uncurable optimist! we will simply have to do something about the tempo. will anyone come to the meeting today?

The elevation would be a property of an area, and not a property of the vertices defining the area?

yes, if I understand what 'vertices' are correctly. whole area has only one homogenous property. it can be '50m elevation' or 'pop density of 150 persons/ square km' for example

When you say "areas do not intersect", do you mean "areas in the same layer do not intersect"?

yes.

The difference between this latest suggestion and what amjayee said previously is that amjayee apparently intended the map to be real 3d, as opposed to just a 2d mapping on 3d sphere. But doesn't this mean that we'd need whole different algorithms for terrain generation and such, because we can't use the same coordinate system in both flat and sphrerical maps?

2d vs 3d map is always about tradeoffs, that is why there are so many earth projections used for the world maps, depending on what do you use them for.
in GGS, our zoom level would be enough zoomed in so we can play effectively. This means pretty zoomed in, enough that earth roundness is not observable. hopefully, this will make distortions that have to happen when you show 3D earth surface on 2D coord system unobservable.

We may use same cordinate system, though some alterations are needed to cover for the distorsions.

That is assuming we go full 3D (amjayee clarification needed! ) with round spherical earth as a base.

I believe that this would not bring that many gameplay benefits. What I was thinking is to use 3D to show elevations on a basicly 2D map, on an earth that is flat and carried by turtles standing on an elephant, or a cylinder, like civ 2

then we could use that simplified earth surface to generate a sphere to be used for a radar (civ2 ToT has this) or something else. This way we would have distortions on sphere instead of play map ( : ) and sphere would be much less used in gameplay. for a radar or some other unprecise thing.

it is important to note that projection difficulties with 3D->2D and 2D->3D are not introduced with using areas to represent data. These problems are still there with tiles, or with anything else used to logicaly store data.

I really dont know what amjayee meant by saying the switch between the two things is easy. actually it is ugly

I think that there are two discussions here: 'tiles or areas for data storage', and 'full 3D or not'.

The main issue about memory consumption is that there will be a lot of information stored just about the geometry of areas

this may be the case, but it depends on the resolution we use. it is tempting to have resolution increased with system as felxible as this one. For example, if we have 3x3 squares on the map and the central one is mountain, it is a square. But if we use this areal representation, it is tempting to have that mountain more irregular to look more real. the more irregular (and realistic) it is, the more resolution of the whole game is increased, and more memory is used.
I said that in a meeting, with higher resolution, it may take more space to store areas then tiles. But then again, we can increase resolution with tiles too, by adding more tiles, but that is not as intuitive as with areas.

We seemply have to keep resolution in check

And I am not at all convinced that the geometry data will be of much value to the player, compared to a tile-based variant which would use the memory to get a higher level of detail in other respects.

Terrain geometry data is connected to all other data in the game, as layers are above the map and in a way 'follow' the map. so all layers would have to have same resolution as terrain.

tiles are not holding any more info then areas. I think player does not think about specific tiles anyway, instead of thinking '30,25 is grass', '30,26 is grass' etc, we zoom out a little and say 'this area between the lake and the mountain is grass.

To me, the oddly shaped areas just seem awfully confusing...

world is confusing. having a world map with all the layers: terrain, population, climate. it is a complex map with lots and lots of info that you need to think of. I dont see why it is more confusing then tiles, considering the resolution of tiles we were going to use anyway.

but still I feel that it would be more clear for the game to have a bottom layer which is simple, uniform across the map and sets a clear "resolution" for the whole game. There would have to be regional system on top of that to hide the underlying tiles from the player, and furthermore an administrative provincial system on top so that the player can meaningfully manipulate the world.

"resolution", without quotes actually is very important. you mention a few times that tiles are 'hidden' from player. what do you want them for then?

Just to clarify my own stand a little but, what I am advocating is a three-way distinction: tiles-regions-provinces

ok

[quote]Tiles are the basic building blocks and they hold layered information on terrain, climate and population density, among other things[quote]

ok. this is as in standard civ games.

Regions/Areas are collection of tiles that share certain properties, and do not overlap. Populations, diseases and perhaps the military presence could be stored in this level. The regions/areas would interact, however, and act like living organisms in a sense: this would be the level that makes the map dynamic to the player, and corresponds to areas in the continuus map.

well, if we have 150 lake tiles for example, then you would have also a 'region/area' that would have info about which tiles it consists of and what is the property they share (water in this case).

so the question is, why have tiles, if the 'region/area' info is enough to represent both the location of tiles (enclosed within area borders) and their shared property (color of the area)?

think of an elevation map or a pop density map. different colors of areas on elevation map show their shared property (altitude). areas are enclosed shapes and they dont intersect, like something cant be both lake and mountain.

Provinces would comprise of areas, and their number would thus be another order of magnitude smaller.

I agree.

With about 1M tiles, there'd be maybe 10 000 regions/areas, and maybe a couple of hundred provinces. Or that is what I would imagine, off the top of my hat. I think that if there are ten thousand anything in a map, the player will have little concern of whether they are free-form polygons or not.

if the player does not use the tiles in his everyday action, do we need to have them for storing info? the less diverse an area is, the more memory advantages we get from 'areal' storing of info as oposed to 'tiled' storing. if some space is extremely diverse then there may be equal number of areas in it as would have been tiles, so there is no gain. but there are very few so diverse places, and I cant think of an example either.

Hmm... I wonder if I made any sense... this was written in pieces during the course of 4 hours)

you did. as always

Relating to this discussion, I've started wondering why can't we call regions provinces, like everyone else does? I believe the word "region" is closer to what we call "areas" (more or less "natural" areas) than what is meant by provinces (administrative areas).

ok with me.

[VetLegion]

Originally posted by Leland
Okay, that wasn't probably very informative.. anyway, my opinion in a nutshell is:

Vector-based layered areas are bloody confusing from player's point of view: The relations between different layers are obscured because they lack a common ground, apart from the coordinate system. And I think it is cooler to have areas as an emergent property of a tiled system than to make them the fundamental property of the map.

There.

well look at it gamplay-wise. you can see all of terrain this way as you see it with tiles.
on the other hand you dont always 'see' all the layers on terrain. so for gameplay purposes you can turn on/off different layers at will.

[Leland]

Before I proceed with anything more detailed, can you elaborate the following:

Originally posted by VetLegion
Terrain geometry data is connected to all other data in the game, as layers are above the map and in a way 'follow' the map. so all layers would have to have same resolution as terrain.

The terrain would, in essence, be the "tiles" in this system, and the above layers would always follow the edges of the terrain (i.e. areas in other layers would correspond to a group of terrain areas)? If so, what is the big advantage of having the terrain layer stored as free-form areas instead of uniform tiles? And if not, well, I suppose that is the reason why my little brains think that vector-based layers can get really confusing.

I'll try to hang around in #ggs sometime tonight, but I'm not so sure if I can make it.

[VetLegion]

The terrain would, in essence, be the "tiles" in this system, and the above layers would always follow the edges of the terrain (i.e. areas in other layers would correspond to a group of terrain areas)?

in a way. this is what I meant: you have an elevation layer showing an island in an ocean. the population density layer in a way 'follows' the elevation layer, because there are no people living in the ocean, only on the shore. or another example, pineaple forrest layer would ne 'adjusted' or 'follow' elevation layer up to 2000 meters (I am making it up) above which it can not grow.

If so, what is the big advantage of having the terrain layer stored as free-form areas instead of uniform tiles?

I can think only of few advantages. Lets see if they are good

one advantage is the memory, which would likely be less used if resolution is keept within reasonable limits. It is possible to use a pseudo random algorithm to show non-existant resolution for cosmetic purposes.

another advantage is that I think areas (of tiles or no tiles) are more intinuitive way of thinking about the map. even with tiles, we would have some way to enumerate simmilar ones and show them in a layered way. for example when player wants to see islam coverage, an algorithm has to go through all the tiles, check their properties and display them if there is muslim pop there. having data grouped by areas instead of tiles means that effectively we have already calculated this information, and do not have to do it every time a display is required.

so processing power may be saved because instead of updating lots of tiles each turn we have to update areas which are likely far less in number.

there must be other advantages I am blind to

[The Joker]

Gee.

I've got a lot to read suddenly. GREAT! Looking forward to it!

Right now it's too late for me to read all that.

I promise I will keep my promise and work seriously. Especially now that it seems the rest of you are as well!

[VetLegion]

hi Joker, good to see you here.

Leland, I ll do a calculation as I promised... I havent had time yet. Although I was thinking about it