Tweet
I'll simply post my idea of what the map graphics should be like and will wait for ideas / criticism / flames raining down on me 
Whether or not a "tileless" movement system will be used, the map graphics will be tiled.
I propose a tile size of 93 x 47 (at maximum zoom), scalable downwards (I have to rely on you coding cracks for a good, fast scaling algorithm). Alternatively, and with better visual results, all map gfx could be stored at, say, 3 different zoom levels.
Tiles are in diamond shape basically, but they should have some vertical offset so that it's possible to draw some pixels above the upper border, thus creating a 3D effect by overlapping. Problem is that with this either the tiles will have to be masked OR the map has to be drawn top-to-bottom in any case. You coders tell what's feasable (I tend to favor the "top-to-bottom" way, since it's easier to handle units this way, too).
There will be circumstances in which neighbouring tiles influence each other (namely coastlines). There are 3 approaches to this:
a) we have to draw a separate tile image for every combination of bordering tiles (i.e. you need to have one ocean square bordering land to the north, one with north&norteast... all in all 2^8 = 256 tiles for just one terrain combination).
b) we draw only the 8 variations (north, northeast, east...) and layer them. Reduces images to 8 per terrain combination, but uses more cpu power.
c) we build each and every tile in a way that it is actually larger than the diamond and blend it with the neighbouring tiles (once again using an alpha channel). There would be "dominant" tiles which overlay neighbours and "submissive" tiles which only can be influenced but don't extend any pixels to their neighbours (e.g. ocean would be "submissive", so as a result coastal ocean would show some coastline border, while the coastal land tile wouldn't show any water.)I haven't seen this method in any game yet, but I think it would offer the best results because all terrain types could be combined, not only those for which special combo-tiles exist. One would have to check, however, if neighbouring tiles are of same or different type, however, to avoid bad blending between tiles of the same type.
Tiles have to be drawn in a way that even in grayscale, the predominant character of the terrain is clearly recognizable, which would give us a host of possibilities for creating statistical maps (grayscale maps with colors showing e.g. population density).
Units follow the terrain tile layout with basic diamond shape (but a regular (negative) vertical offset so the "stand up".
Cities / Landmarks should be handled as "static units" in respect to graphics routines.
Each tile / unit / city / landmark needs an invisible "hard mask" (1 bit) to determine whether the mouse actually touches it. An optional "soft mask" (8 bit greyscale) would provide smooth edges for all non-tile images.
If I had it my way, we'd use a tileless movement system and optionally show the ZoC of a unit by drawing a translucent disc in player color beneath the unit.
This method of tinting the map gfx could be used to show other data, as well, like:
- accessible terrain this turn
- actual size (power or real volume) of a unit
- support (areas around cities / provinces)
- detection (are in which the unit can see without "fog of war").
Whether or not a "tileless" movement system will be used, the map graphics will be tiled.
I propose a tile size of 93 x 47 (at maximum zoom), scalable downwards (I have to rely on you coding cracks for a good, fast scaling algorithm). Alternatively, and with better visual results, all map gfx could be stored at, say, 3 different zoom levels.
Tiles are in diamond shape basically, but they should have some vertical offset so that it's possible to draw some pixels above the upper border, thus creating a 3D effect by overlapping. Problem is that with this either the tiles will have to be masked OR the map has to be drawn top-to-bottom in any case. You coders tell what's feasable (I tend to favor the "top-to-bottom" way, since it's easier to handle units this way, too).
There will be circumstances in which neighbouring tiles influence each other (namely coastlines). There are 3 approaches to this:
a) we have to draw a separate tile image for every combination of bordering tiles (i.e. you need to have one ocean square bordering land to the north, one with north&norteast... all in all 2^8 = 256 tiles for just one terrain combination).
b) we draw only the 8 variations (north, northeast, east...) and layer them. Reduces images to 8 per terrain combination, but uses more cpu power.
c) we build each and every tile in a way that it is actually larger than the diamond and blend it with the neighbouring tiles (once again using an alpha channel). There would be "dominant" tiles which overlay neighbours and "submissive" tiles which only can be influenced but don't extend any pixels to their neighbours (e.g. ocean would be "submissive", so as a result coastal ocean would show some coastline border, while the coastal land tile wouldn't show any water.)I haven't seen this method in any game yet, but I think it would offer the best results because all terrain types could be combined, not only those for which special combo-tiles exist. One would have to check, however, if neighbouring tiles are of same or different type, however, to avoid bad blending between tiles of the same type.
Tiles have to be drawn in a way that even in grayscale, the predominant character of the terrain is clearly recognizable, which would give us a host of possibilities for creating statistical maps (grayscale maps with colors showing e.g. population density).
Units follow the terrain tile layout with basic diamond shape (but a regular (negative) vertical offset so the "stand up".
Cities / Landmarks should be handled as "static units" in respect to graphics routines.
Each tile / unit / city / landmark needs an invisible "hard mask" (1 bit) to determine whether the mouse actually touches it. An optional "soft mask" (8 bit greyscale) would provide smooth edges for all non-tile images.
If I had it my way, we'd use a tileless movement system and optionally show the ZoC of a unit by drawing a translucent disc in player color beneath the unit.
This method of tinting the map gfx could be used to show other data, as well, like:
- accessible terrain this turn
- actual size (power or real volume) of a unit
- support (areas around cities / provinces)
- detection (are in which the unit can see without "fog of war").
Comment