Openciv3 - Terrain and map

[amjayee]

Good to find some agreement. About borders, we can as well have them always between the hexes, so no half hexes occur. About units, I agree with Joker. Some unit (army) types can exist in the same hex with enemy units. Also submarines are added to those mentioned.

About unit graphics: if we have a straight above view of the terrain, I don't think we can have 3d rendered units. What I meant, and what I think also Joker understood correctly, is that we would not have units looking like real men or vehicles etc. Instead we would have small icons representing the units, and describing them, and telling some vital information about them. This is mainly because we use armies instead of individual units; It's easier if we just have an army symbol instead of a stack of unit symbols. Also it's less trouble, since we can have only a few army/unit types, and each one has one simple icon (being simple doesn't mean looking bad, though - up to the artist). I think this could be a very cool feature if done well. It is a real challenge for the artists - to come up with icons, that look good, distinguish between army types, and are appropriate for us... more artistic freedom than dull, plastic-like renderings that look stupid in top-down view of the terrain.

[Guildmaster]

Hmm I wonder if only major important cities should be named, and we can assume that there will always be some sort of city in every single hex, even if it's just a gas station right next to the house of the person who works at the gas station. I agree, the important thing is How much of the population is urban, and how mich of the population is rural.

------------------
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]

Graphics:
I still wonder how elevations will be done with a vertical map...

I agree, however, that we should use sattelite photos as the basics of our tile pics.

Cities:
Yeah, only major cities should be portrayed, and named. All the small ones should just function as rural areas.

------------------
"The future is that mountain."
- Bret Easton Ellis

GGS Website

[amjayee]

Elevations: I think the coloring system used in the latest map demo should be sufficient, ie. higher elevations have darker colors.

About terrain graphics: yes, they should be inspired by satellite photos, but of course they would be more illustrative. For forests for example, we should make green textures that look like a bunch of small trees viewed from above, etc. Mountains are trickier, but perhaps we could come up with something similar to the real mountain-ranges. But I think the map will look quite cool eventually.

I agree about cities etc.

So, terrain issue seems to be settled... what do you think about the unit graphics? Only icon symbols of different army types, and some status data, instead of sprites or rendered animations of men, cannons, tanks etc.

[ElmoTheElk]

I agree with you about the terrain and the names. The unit are a more complex question. I think just square icons won't do in our game. A new game in 2003 just NEEDS more than that. We'll have to find a good way to include a unit graphic and statistics in every army-look. The difficulty here is not only the graphics look, but even more the lots of data we'll have to diplay in order to make clear which unit/army type it is with which strength, health and # of individual units.
I'm not that good in painting units, however I may make some sort of example this week or so to show you the difficulty of making those.
I agree however that we don't nee 3d rendered plastic-like soldiers who 'walk/drive/..' across the map. Hmmm...

[amjayee]

I agree square icons might look out-of-date; but I think it is about the only way we can avoid making it look extremely stupid. Also telling different unit types apart would be difficult. So, I suggest using icons on the map - but we can design them so they seem at least remotaly modern. Then, let's put the photos or rendered images / animations of the units / armies into the info screen or something. Otherwise we almost have to make an isometric map, which is not good.

[The Joker]

I am just not sure how to do this. I just want something that works and looks cool.

I then trust you guys to make something great!

------------------
"The future is that mountain."
- Bret Easton Ellis

GGS Website

[ElmoTheElk]

O Joker, you once again give the hard work to us.... No serious: I agree about the icons, but the icons also need to contain some sort of graphic.

[amjayee]

Yes of course, they should look also beautiful, so I think the icons should perhaps have some kind of cool symbol for each unit/army type. But we'll see later what we need... perhaps someone could make up some concepts?

[Sikander]

I hope that I am not butting in here with a lot of useless blather but..

1) I like the satelite view of the map idea. While showing elevations might be a good idea from an esoteric standpoint, how much will hexes of different elevations really effect game play? If the models for climate etc. are going to make these of some importance, it will be of secondary importance, and should not clutter the map too much. Both elevations and army data can be shown in detail in an information box (like smac) shown when the mouse pointer is on the hex. I like the idea of various filters for the UI which turn off various map data which will tend to clutter the map if they are all displayed at once.

2) A decision should be made whether to make the game more map driven or unit / city driven. If the game is map driven, then each hex will need not only space for it's basic underlying terrain type, possibly including climate data, mineral and soil data etc., but will also need space to hold at least the identification numbers of units and cities it holds, as well as any player modifications such as roads, fortifications etc.

All of this information will make the map a memory hog, but will reduce the number of times that the various game algorithms need to call other tables to determine whether hex XXXX is occupied by an army which can react to or block movement etc., and since most of this data must be displayed upon the map, it will be required by the basic map module anyway, whether it is stored there or not.

Additional information which may need to be stored in a hex might include certain information regarding not only the hex itself, but which hexes it borders (for quick lookup of pertinent ZOC, border, land movement to a sea square conditions etc.) and again since borders and coastlines must be rendered upon the map, it seems logical to include this data in the basic map module.

Thus it seems best to build the game database around the map array as much as possible, as the map will likely have the most points of contact with all of the other data arrays in the game.

[The Joker]

Hey, you're the artist, Elmo.


Sikander:

No, you are not butting in here. Anybody interested are welcome to join the discussion, or post ideas for us. So thanks!

1: Yes, elevations may not have too much gameplay importance. But they are still giving some flavour to the game. But it should propably just be shown as different colours for different elevations, as amjayee said. Or, alternatively, only as stats in the bottom of the screen.

2: Since we are going to have a lot of hexes in the game, and a limited amount of units it would propably be much simpler to simply know what hex a unit is on, than to store information for all hexes on whether there are units on them. Propably the same thing with roads and such, since there will be many more hexes than there will be roads.

But I am not really sure here. You do have some points, and maybe making it mapbased would be simpler and easier. I think I will step back and let the programmers answer this in more detail, since I can not do it sufficiently.

------------------
"The future is that mountain."
- Bret Easton Ellis

GGS Website

[The Joker]

After the meeting and a talk with Harel I think that the 2 byte terrain types would just be way much more than we need.

Think about it: how would 60,000 terrain types improve the gameplay? So I think that 1 byte (256 types) could do it, if we give the thing some thought. I can't give a complete list right now, but I think to make the map file smaller (without really making gameplay weaker) this should be pretty good.

Second we realized that 50 km hexes would not give 1,000,000 hexes on an earth map. It would only give around 240,000. So what about to give us larger, cooler maps, the hexes would be reduced to 20 km? This would give 1,460,000 on an earth map. Something that is highly possible if we make the terrain just 1 byte.

------------------
"The future is that mountain."
- Bret Easton Ellis

GGS Website

[cavebear]

Please forgive a non-programmer question, but is it possible to have multiple levels of graphics to simplify things? A first general layer of basic terrain, a second with overlaid resources (like wild and domesticated plants/animals), and a 3rd with armies, cities, and terrain improvements?

If that is possible, it would eliminate (or at least vastly reduce) the need to have each tile uniquely described.

It's OK to smile tolerantly and tell me not to worry about it.

[ElmoTheElk]

I don't think I 100% understand what you mean, but:
1. Graphics are always layered. The new graphics are drawn on top of the basic or lower other layer.

2. The descripsion of the layers is not graphicly but is in the hex vaiable. Let's say the max characters used in the varaible is 1 byte->8bits->8 spots->XXXXXXXX. Every spot contains an value that is refered to an specific feature of that hex. So if we want to reduce the map size, we have to reduce the size of this variable (like used 1 byte in stead of 2).

The graphics are only drawn if there are 'in the screen' (visible player area in the map window). This is not the memory-cruncher.

I hope I am right baout all this AND explaned it enough.

[Leland]

Another crackpot idea for you guys to shoot down:

Because of the scope of the game and the focus on regions and large scale phenomena, there is a demand to have data structures and algorithms for handling large areas of land instead of individual tiles. Regions are of course one example, but also diseases, possibly populations (at least in my wet dreams ), lines of sight, resource extraction, continents, islands et cetera are also covering large areas in the map. If all these things are done tile based, it means an overwhelming number of calculations per each turn, not to mention the memory requirements. I propose that tile-based information is banished with the exception of the map altogether.

Instead there could be a class for handling an area, long with methods to see if two areas overlap, are disjoint or share a boundary. A single tile would of course be a special case of an area. The advantage of areas would be especially emphasized when there is a need to deal with large, contiguous tile groups: areas can be difined as a closed path of tiles, and as such it is only proportionate to the square root of the number of tiles inside the area. Furthermore, a path can be compressed to considerably smaller size than a set of tiles because a tile needs to be identified uniquely, but a path only has tiles that are adjacent to another and after the first tile the rest can be referred with a relative value.

For instance, consider the following area:

map:           tiles in row:

         b     1 

        bbb    3

    bbbbbbbb   8

bbbbbbbbbbbbb  13

 bb   bbbbb    7

       bbbbbb  6

         bbb   3

There is a total of 41 tiles in that area. I can conceivably see three basic storing schemes for it:

1. have the areas be referred to in a map. With a 1000x1000 map this means that each combination of overlapping areas must be stored as well. Therefore, the map needs to store one extra byte of information to know whether there is a "b" in that spot or not. Memory requirements in bytes would thus be

map_width * map_height / 8 = 1000 * 1000 / 8 = 125k

2. store the coordinates of the tiles somewhere else. This is fine with small areas as you only need a few values, but the number of values grows geometrically. The game is likely to have map coordinates expressed with two 2-byte numbers (with compression you could probably lower this number), and in addition you need to know the number of tiles as well. So, we get

number_of_tiles * x_coordinate_size * y_coordinate_size = 41 * 2 * 2 = 164 bytes

3. define the area by storing the path of the borderline. If I calculated it correctly, there are 28 tiles in there. Now, however, we know that each tile is adjacent to the other, so it's possible to store only the first absolute coordinate and the direction where the next tile is. In this example I've used square tiles and allowed diagonal movement, so there are 8 possible values to go and one value which should be reserved to mean the end of the path. In hexagonal case there woudl only be 7 values and they'd fit into 3 bits, but since four-bit representation is easier to handle we'll use that in the estimation:

starting_point_size + length_of_border / 2 = (2*2)+(28/2) = 16 bytes!


I know there are ways to alter methods 1. and 2. to be more convenient than it was in above examples, and that the calculations with areas require more computing than simple tile based system, but I still think there could be some point in having an abstract notion of "area" in the design and implement various entities as such. But remember, I am not a very experienced programmer (more like a groupie ) so there are possibly some other ways of doign things than the ones proposed above. Please comment.
[This message has been edited by Leland (edited January 01, 2001).]