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").

Your proposals seem quite good to me. I like your suggestion c with coastal squares handling and square border blending.

Two points:

I think if practical we should also allow for a top-down 'diamond-shaped' view as an alternate, as we discussed before.

I believe we should at least start on the first alpha version using a per-square movement basis rather than tileless. We can put in the tileless info, but restrict movement to the center of each square until we're sure how to handle all the issues that come along with a tileless system.

It it a bit tricky to make these borders fit but it look very good and is very simple for the game engine.

Peter

Peter

I'm assuming that Dominique is no longer the Duke for graphics since he hasn't posted in months, so I'm not sure who to address my questions to. I'll simply post them here:

1. Are we creating the graphics (map and units) in Java or is there some GUI that we can use to make the job easier?

2. I see from earlier postings that TIFF format seems be the way we were headed, but the large number of threads makes it difficult to determine what the final specifications were re: graphics. Any comments on this?

Yep, Dominique is toast as far as I can tell. I, however unqualified, appear to be the
default sucker for this at the moment. Volunteers?

1. Designers can use whatever toolset they like to do their images. We won't be making
anything special for it.

2. Yeah, I think Tiff is still the concensus. If you have any strong opinons speek up

I found a Sun API, the Java Advanced Imaging API that looks, upon cursory inspection, to
handle 24-bit tiffs. The main page for it is at http://www.javasoft.com/products/java-media/jai/index.html
A piece of the manual that shows the tiff stuff is at: http://www.javasoft.com/products/java-media/jai/forDevelopers/jai1_0guide/ Acquisition.doc.html#61287 .

I haven't had time to check it out in terms of speed etc. But I think its safe to just go with TIFFs as the standard at this point unless you or someone really raises serious objections. Dominique seemed to know this stuff pretty well.

On your doing part of the job... Just let me know what you need and we will bumble through as usual . I think with some sexy graphics in a demo and on the web page we will be able to suck in some graphical artist types. Your thoughts on this appreciated too.

If you would like to be provisional duke for graphical stuff until someone who really wants the job shows, you're Very welcome to it.