A Crude Map/Army Graphics Proposal - Please Evaluate

[Mark_Everson]

Here is a crude proposal for how the map/army graphics in Clash should work. I have taken ideas from various people and made some tradeoff decisions based on my vision of Clash. I Know I am not qualified to properly balance all these tradeoffs, but some order needs to be brought to the process. It is possible there are even grevious technical errors in here since I haven't had time to research everything. Please criticise what I have here at any level. Make an alternative proposal, or flesh this one out, if you would like. I think we need to have this at least sketched out within about ten days.

Most of the Good ideas are Not Mine. This information has been gathered from many posts by different people in the following threads:

What I could offer to the project...
Graphics style
Terrain and Improvements to it

Ok here it is:

Map/Army Graphics proposal

I think its fair to say that the preponderance of opinion, with some exceptions, is that for the main map and units civ2-ish graphics are the way to go.

First an overview

I propose:
1) 256-color scheme be used for the terrain and army images (with alpha-channeling to give color to flags or shields...)
2) isometric and top-down (diamond shaped tiles) map options. Ideally there would be different zoom levels for the map giving something like graphics at 90x90, 40x40, and 10x10 pixel scales. Needless to say there would be no army counters for 10x10 just a generic our-color shield or something.
3) that there be a limited number of army group, and naval counters that will represent combined forces from different eras and geographic regions.
4) An 'eye candy' graphic that will display the selected army as arrayed for battle using 16-bit graphics at something like 150 x 200 pixel size

Now for some specifics:

1) 256-color scheme be used for the terrain and army images...

Gif is the standard image file type in java so far. GIF can use only up to 256 colors - not a problem as such (AoE is done in only 256 colors!), but MUCH harder to do convincingly for the artist. I have chosen GIF for the game because I'm afraid that higher res graphics might produce problems if we up the turn rate. This could happen in either a time-pressure kind of game, or one where the player only wants to make the broadest decisions and let the rest "play out in front of him". Remember there is a Lot more stuff going on in the background in Clash than any other game in the genre.

2) isometric and top-down (diamond shaped tiles) map options.

To go from isometric to top-down map, we would need to use diamonds rather than squares, or either the perspective of the map or distances would change. But I don't see any problem with diamonds... you can get higher-res figures in them anyway if they are a single individual. I hope we can use the same army graphics for isometric and top-down views. If this isn't true then we need to double the number of units I figured below. My take is that the top-down people won't care that much if the units are slightly smaller than ideal for the map diamonds.

General graphics for the map. Have different zoom levels for the map giving something like graphics at 90x90, 40x40, and 10x10 pixel scales.

As to layering in the display I'd say (and this is subject to change)

-base terrain
-rivers / canals (would like flow direction for rivers, maybe like Civ1 did it)
-roads / RR
-civ borders
-special resources (rare) [maybe 20 images]
-units [see below]
-fortifications (so unit appears in fort...)

Base Terrain Types:
- grassland
- plains
- desert (both sands and ice)
- tundra
- jungle
- woods
- hills
- mountains
- swamps
- lake
- ocean

So we have something like 13 terrain types at 3 resolutions giving about 40 images here.

3) that there be a limited number of army group, and naval counters...

Since the graphical units actually represent MIXED armies, we should stick to a few images representing all the army groups on the map. We could maybe have for each age/region of the world an infantry army counter (used for garrisons too) and a combined army counter. We would then give the different sides distinct shield or flag colors using alpha-channeled techniques. We should flesh it out by drawing several alternatives for different cultures / epochs. The armies would have to have numbers on them since we don't want to need to do 35 distinct army graphics.

Number of army group images would be: 2 (infantry and combined) x 5 (epochs) x 2+ (occidental, oriental, maybe more) x2 (90 res and 40 res) = 40 images.

4) An 'eye candy' graphic that will display the selected army as arrayed for battle

For the battle-line view portraying the selected army I think we can go all-out and do TIF graphics at 16bit.

On the overview map, you have the standard army images. But when you select one, there would be a window giving detailed information and a graphic for the selected army.

I think images of the right number of each unit type should be laid out in a battle line on the appropriate terrain. So an ancient army would be laid out with infantry /ranged units mostly in the center and flanked by cavalry. These unit graphics would also be used in the tactical combat system if / when we do it.

The graphics proposed as an absolute minimum list are (one oriental and occidental for each in 1-7, possibly allowing for an alpha mask for skin color):
1. stone age warrior
2. Iron age armored infantry (prob need bowmen too)
3. ancient ship
4. ancient / medieval horse
5. musketeer
6. ship with cannons
7. gunpowder cavalry
8. early rifle infantry (probably cannon also)
9. marine
10. destroyer or battleship
11. tank
12. plane
(If we can afford it I would like to at least double the size of this list to fill in some of the big gaps, but this would do as a minimum. Suggestions to add to this minimal list are welcome)

Estimate: 20-60 images depending on how much we can expand the list above.

Number 4 is a Lot of work. Is it worth it? I'm sure it is worth it if we do a tactical combat mini-game.

I Know I havent covered it all, but I haven't done too badly for a lunch hour and a 15min break!

Let me Have It!

-Mark


[This message has been edited by Mark_Everson (edited May 20, 1999).]

[Dominique]

I bet you knew that I'd INSTANTLY reply to that

First the really drastic thing:


>>1) 256-color scheme be used for the terrain and army images...

Hm. For one, if you say the eyecandy image can be 16-bit TIF this means we're working on a 16-bit viewport, anyway. This alone eats into the performance (correct me if I'm wrong, but when I coded myself, several years ago, pixel depth WAS an issue).

The one thing I'm really afraid of is the color palette. This one's scary, believe me. AoE did a miracle here. Remember that using 256 colors only means you use THE SAME 256 colors for each and every graphic element in the game. Believe me, that's tough. Let alone you can simply forget about nice things like shading parts of unit icons to indicate player color etc. - works only in HiColor mode minimum

But, seriously, I rellay don't think we'd have a performance issue here, as you will recognize in the following paragraph:


>>2) isometric and top-down (diamond shaped tiles) map options.

For one, I'd propose parallelogram tiles for the pseudo-3D, for one simple reason: the north direction stays the same as in the flat map.

But you mention drawing all the tiles etc. in different scales - well, CAN be done, but e.g. CIV2 doesn't - the graphics are stored in one size only... if you zoom out, each and every map tile / unit / city / icon is in fact reduced in size on-the-fly. See why I don't see any performance issues in using 16-bit gfx? If even CIV2 could use realtime size variation (quite a complex routine, compared to simply copying double the amount of data), we should be able to do it, easily. And do not forget that the actual DRAWING (i.e. blitting) of the pixel takes only a part of the time of displaying a tile; I think more time is used for the algorithms to look up the map code, check for overlayed gfx etc.

And as for "about 40 images" - hehe, you are a funny guy, Mark - let me do MY calculation:

13 base terrain tiles
mountain ranges need 16 extra tiles
hill ranges need 16 extra tiles
coastlines need 16 extra tiles
larger woods need 16 extra tiles

add to this the graphics for the overlays (typically 256 images for streets...)

no, it's not THAT easy, I'm afraid...


>>3) that there be a limited number of army group, and naval counters...

Sounds ok, only thing I'd propose is that you can optionally show little badges / coats of arms instead of the numbers (not my idea, but I like it - I like EVERY picture that can replace a number).


>>4) An 'eye candy' graphic that will display the selected army as arrayed for battle

I'm afraid I must really make a demonstration model to illustrate my idea of making the "customizable units" - or was what you wrote meant that way? Otherwise, you'd have WAAAY too few unit types!

As for the tactical combat I suggest to forget about it for the moment - just like to mention that the gfx works involved in such a thing takes easily 10 times as long as all of the rest (battle animations, hrmmmm...).

------------------
If somebody asks you "Art thou a god?", you tell him "YES!"

[This message has been edited by Dominique (edited May 20, 1999).]

[Mark_Everson]

Dominique:

Yes, I knew you'd be there... And glad of it.

>>>1)

What we really need is someone who knows Java Graphics cold, to assess the speed thing, and I just don't. So let's table that issue until someone sufficiently knowlegable comes along. I couldn't be happier if you're right and its no big deal to do it the good, easier way.

>>>2) isometric and top-down (diamond shaped tiles) map options.

>For one, I'd propose parallelogram tiles for the pseudo-3D, for one simple reason: the
north direction stays the same as in the flat map.

Agreed, the way it is in civ2.

>But you mention drawing all the tiles etc. in different scales...

Ok, then we only need one set. that's good anyway. I have v0.05 set up for that and the diff size maps are really handy.

You're completely right on the number of terrain tiles. Can I surrender? And I think 16 would be more like the bare minimum for coastlines.

>>>3)
Badges, we don't need no stinkin' badges... Sorry, just a bad joke. Agree completely, get rid of the numbers if possible.

>>>4)
"customizable units" if its as easy as you think it sounds like a natural to me...

Tactical combat would be phase-based and should not take that much more work IMO. Most of the stuff we need would already be in the game. Done cheaply we could use the same tiles and units from the eye-candy view. I am not thinking necc. of real-time units "walking", arrows shooting or crap like that for the first shot. Almost like civ2 combat is now... But with decent AI.

At least we are closer to a spec! I think


-Mark

[This message has been edited by Mark_Everson (edited May 20, 1999).]

[Blade Runner]

(It's a copy from an another thread, but I think this is the right place.)

My idea is the next:

1. We have different pictures only for land, air and sea based units. (If I count well this will be 3*5=15 picture only)

2. We have a military window somewhere on the screen. When the player move the cursor over the unit, this window will show the exact unit mix with type, strength, readiness and anything what we want to include in the game.

3. When the player right click his/her own unit on the screen the military window stay and he/she has a possibility to modify something or start to fight with the enemy. (In the same time the battle screen popup too. )

4. I think we need to change the use of the air units.
a. The player can not mix air and land units.
b. The air units can fly over the enemy cities and enemy or own units. (In the own cities they can refuel and stay)
c. The air units can fight each other or they have a possibility to bombard the enemy units.
d. Special land and sea unit(s) can fight against the air units. (SAM, Air defence canon?, AEGIS cruiser, etc)
e. The bombardment can not eleminate completely land unit mix and the special land and sea units can not eleminate completely the air units.
f. Maybe we can use special air unit to refuel an air units stack on flight?

Blade Runner

[Dominique]

Blade Runner:

That pretty much sums up what I had in mind

[Dominique]

Okay, I did some first very cautious steps towards the interface graphics - please do not be disappointed; as long as we don't have ANY clue as to what informition will be shown in the end, it's simply no use to invest time and work into doing fancy graphics. I only did this so we have a something to refer to, as I will now do - best you open screen1 from www.qed.de/work/clash/screen1.jpg .

Okay, I assumed a resolution of 1024x768 (fullscreen) for this. No doubt the primary object will be the map window, which should be AS BIG AS POSSIBLE. This means we will have to make the navigational and informational elements on the sides / top / bottom as small as possible while leaving their functionality.

A BIG MAP AREA IS OF THE ESSENCE!

In the end, a good overview on what's happening in the game is maybe the most important factor of whether someone will like the interface or not.. Right now you see big borders around the various areas - these will have to be shrunk down to the minimum visually acceptable size.

I assumed a tile size of 48x48 pixels at full zoom, but of course we must discuss what information must be included in this area, so maybe the final maximum tile size will be up to 64x64.

For comparison: CIV2 uses 64x32 diamonds, which have essentially 512 relevant pixels in each (half of the 1024 rectangle pixels being cut away since the tiles are diamonds). With 48x48 = 2304 pixels, we'd have more than 4 times the information per tile PLUS the benefit of a rectangular region (square map only), so we might even reduce the tile size further without losing information. It all depends on what needs to be symbolized within the limits of any given tile size.

I decided to use an odd number of rows / colums so any centering on a tile will actually have a "center".

An important issue is the player's screen size: We certainly want to have a quadratic map, but it might become necessary to have rectangular maps for lesser screen sizes so no room is wasted. Screen size should primarily influence the size of the map window, but you just can't avoid some other regions being influenced, too.

For clarification, look at the right hand side: I amiganed to have a unit picture (upper black area) and a unit's stats (lower black area) there, as well as some buttons / icons. Imagine you now had a 1280x960 screen resolution - this would expand the map area by 4 rows, 4 colums, but what with the freshly gained room below the stats window?

I suggest having several levels of interface functions:

1. core functions, absolutely necessary
2. important functions, good to have
3. advanced functions, for more ease of play

Of course, all must be accessible from even the smallest usable screen size, but with growing screen size more of the elements should be visible / directly accessible at the same time. Performance might be an issue here, but I trus in people having big monitors having good hardware, too J

So, effectively, having more room on the screen would (besides enlarging the map area) make less clicks necessary since more info / buttons are visible at the same time.

Then, we had the issue of colorcoded maps by gerying them out and overlaying color indicators. I've done a quick and dirty example of theis at www.qed.de/work/clash/colorcode2.jpg .

The original map section (snapshot from Colonization) for comparison is at www.qed.de/work/clash/colorcode1.jpg .

First, this shows a map using 32x32 pixel tiles. As Colonization was a game of the DOS era, these tiles showed up pretty large but look ver small on today's screens.

As you can see, the basic features of the terrain are easily recognizable even on the greyscale map - subtle differences like "is it grasslands or plains?" don't matter that much, really, on theses types of maps. Much more important is that you can see the predominant (and strategically important) terrain features like sea, rivers and mountains.

There are two different "peaks" (of whatever this map is to indicate), done with diferent methods:

- the peak in the upper left is done by adding red accodring to the value to be symbolized. This results in a somewhat "faded" image, since the original tile will in any case be lighter than before. The terrain is clearly visible everywhere, but the color levels are not very distinctive.

- the peak in ther lower right is done by actually "replacing" the original tile by pure red, in a degree according to the represented value (filtered).

So, we've a done a first step... comments, plz!


[This message has been edited by Dominique (edited May 21, 1999).]

[Mark_Everson]

Blade Runner:

On the air unit thing. I had in mind having some sort of airbases that don't have anything to do with urban areas. Air range would be figured from the base.

The reason I wanted to allow optional stacking of air units with troups is if their mission is close support it reduces a Lot of micromanagement to just leave them there. Their effectiveness would decline by distance from nearest airbase. Also integrated use of air and land troops produces much better benefits than bombardment alone.

Dominique:

Your stuff looks good! One worry about the two boxes is that we need to think what is in them at all times. Province information and messages about events are other things that could go in these...

I like most of what you've done...
The color code things look very good IMO. I prefer the bolder color scale.

A Good Start

Mark

[Dominique]

Mark:

Hehe, it wasn't supposed to look GOOD - it is AWFUL, in fact. We just need to have a start SOMEWHERE. And, yes, I prefer the bolder color setting, too.

AS FOR THE EMPTY BOXES: For one, we haven't got ANY idea what screen elements we will actually need - but whatever we do, it will consist of boxes and buttons in the end. What's in the "big box" when not focused on a unit?

Well, depends - I have the feelding that the pointer / cursor should have some focus at any time, shouldn't it? Be it a unit, a city, a terrain tile... so there's always some info / image to show here.

If you prefer having "focusless" mode, too, one could still show empire information here or the players' coat of arms / flag, hm?

[Blade Runner]

Mark,

If I understand well you think 2 different kind of air force. The first will do normal air tasks like bombing, supply ground forces, etc. The second will fight together with land units to attack the enemy land units. The first will base at air bases, carriers and the second will stacked together with the land units.
I think it make sense if we mix A-10 tankkillers with the land units. I can not find sense to mix B1-s or B52-s with land units. They have different task in a war then support land attack.
I think you are right with the 4.a, so we can mix a few kind of air force with land units.
What about the movement possibilities? (4.b, 4.c, 4.d)

Blade Runner

[Mark_Everson]

Blade Runner:

4b,c,d are Ok by me. And e is certainly required. F looks ok also for very modern air units.

[Druid2]

Dominique,

Thanks for putting a picture up there for us to take potshots at.

I'd suggest a tabletop background that has a little less contrast. Whether we go with a dark font or a light font, we want it to show up easily.

As for what goes in the boxes... Well, I sure hope there are some buttons for the player to choose what to look at.

...
And I really like the point you make about using squares instead of diamonds. It minimizes pixel loss, so we de facto get better detail.

Btw. I assume we will have an option to show a grid on the main map, so you might include that in your pixellated thinking *s*.

[--------------------------------]

Mark, re: terrain types and layering.

You have 20 now, I think. I'd suggest that you plan on either 16 or 32 different terrain features that would be included in the layering. That way the programming could use 1 bit to indicate each terrain feature, and still stay within "normal" numeric datatype boundries. The less data we have to move around and analyze, the better/faster the program will be.

[This message has been edited by Druid2 (edited May 25, 1999).]