Having seen the screenshots and the Clash site itself, it occurs to me that there's no real graphic designer in your team yet (gish, I hope I haven't hurt anyone's feeling saying that!). Well, as the web designer I am, maybe I could be of some help here...

I can offer the following:

- Design of the Clash site

- Design of in-game graphics, units, interface etc.

What is VERY important is that all people concerned with the "face" of the game agree on a common line and USE THE SAME PROGRAMS. There must be access to all current designs for all participating in the project. As for the game graphics, you must confess that it is next to impossible to mimick the gfx of, say, CtP. There are 1000s of hours of work in these, and the have eaten up most of the budget for this game (especially animations/videos).

On the other hand, even a single person could accomplish something. For the units, I'd propose rendering them using MetaCreation's Poser3 (the humanlike units, at least). Even animations are possible with that.

For the unit's graphics, I'd like them to actually show the player a unit belongs to by means of the graphics itself instead of a colored shield. So each unit would have a certain part (e.g. a shirt, a helmet etc.) which shows what empire it belongs to.

Mark, I don't know how far your development of incorporating the graphics have gone. I'd say the graphics should be 16-bit and, ideally, alpha-channeled (as opposed to a b/w-mask as it's used normally). Can this be done?

Furthermore, looking at the ease of later modification/extension, standard graphics formats should be used. TIF makes a great format here if alpha channels are used.

Being aware that this might sound like graphics professional gibberish, I propose the following format (for units):

The unit picture itself, one pic for every direction the unit may face (no animations - they eat up development time, hinder modification by players and are simply redundant eyecandy in a civlike game).

A first alpha channel to blend in the unit smoothly with the terrain tile.

A second alpha channel to define the area which are colored in the player's colors.

This is more or less the system the graphically superb Age of Empires uses.

For the interface, a different sets of elements (like screen borders, city graphics etc.) for each culture would be GREAT.

For the terrain tiles, the graphicaly most advanced option surely would be to overlay the graphics, i.e. have several layers:

- basic terrain
- tile improvements
- roads, railroads, etc.
- fortifications

This makes it easier to prgram the code, too - only problem is, of course, that each layer slows down the game. I doubt one can handle that convincingly in Java. I'd rather see a game done in C++, anyway (sorry, can't help here - my programming is restricted to BASIC dialects and Perl/JavaScript).

Okay, just some references so you know what I'm talking of:

http://www.qed.de/Thar/

is a hobby site made and maintained (or not, for the previous 3 weeks) by me and dealing with an Age of Empires clan,

http://www.qed.de

is my own agency's site (it's german, but you can see some figure renderings done with Poser3 here).

Looking forward to your response...

You're dead on! We're completely flying blind on the graphix.

I'm a network programmer. We have no one with any graphix programming experience as far as I know, altho a few artists are signed on. Mark is coordinating them, and perhaps ya'll who know about such things can hash out the specifics.

First, (forgive my ignorance), but what is an 'alpha' channel? The two methods I've used to draw to the screen are 1) pixel by pixel using drawLine, drawRect, fillOval, MemoryImage, etc. and 2) load an image (i.e. a tile) and use drawImage to write it to a screen position. '1' works for simple graphics, and gives you full digital control over the image, which is my personal preference. '2' is okay also, and can deliver AoE level graphics -- esp. with Java2 -- altho I'm personally not convinced that the amount of work required really creates a more enjoyable game. I enjoyed MoO2 and Lords of the Realm II far more than AoE.

Alright - you were asking what an alpha channel is:

You surely know the ability of the GIF format to set one of its maximum 256 colors as transparent, right? So here you effectively have a 1-bit (or b/w) mask where each "0" defines a transparent pixel and each "1" an opaque one. Fine. Many a game is done using this technique - translated for you as a programmer this means you copy (or "blit") a rectangle image to the screen but mask it using a 1-bit layer, so you can easily stamp an irregularly shaped figure (as opposed to the default rectangles drawn by blit operations).

The problem with this technique is that it's "all or nothing", on or off.

An alpha channel is essentially this same mask, but not 1-bit (b/w), but (normally) 8-bit (256 greys). Thus you still have opaque pixels as well as transparent pixels, but you have semi-transparent pixels, as well, so that any given graphic can really be smoothly blended with the background. The otherwise often clearly visible edges of, say, a unit, become anti-aliased. Another great side effect is the ability to draw true shadows with this technique (not simple black ones, but real shadows which daken the terrain tile colors).

The second use for the alpha channel I could imagine is for the player colors: Let's say you decide to draw a marine unit. The player color should be reflected in that marine's helmet. Simple, boring old method: The marine gets a blue/green/whatever helmet. More elegant method: You draw a fitting alpha mask and now the helm is in SHADED colors (effectively, you tint the image accodring to the alpha transparency).

Now, this is not only a question for the graphics designer, but for the programmer, too: As I some days before wrote to Mark, I once dabbled in doing strategy games myself (none was ever completed ). So I know that each program is effectively a tradeoff between time and space, i.e. memory. Of course, if there could be up to 8 players, one could draw our marine with 8 different-colored helmets... but wait: 8 colors by 8 directions (facing) by (just assuming) 100 unit types... 6400 images. Hmmmm... So what many games I know do (I first saw good ol' Battle Isle using this technique) is using one image only and tinting it, thus using roughly 1/8 of the otherwise needed memory/HD space. I only have to know if this technique is feasable for you and if the screen will be drawn quickly enough using it (we're talking of double-masking a 16-bit image here instead of your copying a rectangle, as is done now). That's why I'm afraid Java is too slow...

As for your comment on great graphics not being necessary - well, that depends on the audience. I consider myself a hardcore civer, and I wouldn't mind playing CIV1 even today. But let's face it, good graphics can add A LOT to the atmosphere! I'm not talking about recreating CtP nor AoE (that's not feasable for idealistic hobby programmers), but I'd definitely like to raise the game far above "typical shareware level". You know what I mean. Clear and simple: CIV2 graphivs level is possible, no problem (only time-consuming, but if a good team gets together...).

Now what?

------------------
Honi soit qui mal y pense

I doubt it - the main performance bottlenecks these days come down to memory access patterns, not code length.

Since memory speed improvement is lagging far behind processing speed, the gap will only become larger.

This fact alone means that the speed losses due to interpreted code are becoming less and less significant, and this is without taking into account the fact that Java compiler / interpreter performance is improving rapidly.

Java2D provides nearly all functionality you'll ever need in terms of image processing, and although it will never match the speed of fully optimized native code (or hardware acceleration, of course), the development time is cut by a MASSIVE amount.

Even the old, bog-standard java.awt.Color class comes with alpha-blending support.

There's several key things to remember:

- Our programming effort is spread across the world, with minimal interaction, therefore simplicity is vital

- We're not aiming at current hardware, we're aiming at hardware (and Java interpreter/JIT software) 1-2 years in the future

- We're not looking for cutting edge performance....

- We're looking for internet-based multiplayer options

Due to all of the above, I don't see how using Java will be anything but an advantage.

Thanx sooo much for putting up with my ignorance!

Okay, I'm not experienced with it, so much of what I say I don't fully understand. However -- Java handles images somewhat differently than C++. You load an 'Image' object, and you then use various methods of that Object to draw it to the screen or crop, clip, filter, color, scale, etc that Image. We'd have complete control over the image thru code. A transparent .gif is handled the same as any other Image. Therefore, one option is to have units with transparent backgrounds written to the screen over a tileset image.

Would this be considered the same thing?

We also have the ability to create an image in memory via a MemoryImageSource (an array of pixel values), and amazing 3D support.

Then there's Java2 -- which adds even more. I know next to nothing about that, tho.

What he said!

But even if what you say about the performance IS true, PLEASE remember that the very poor performance of some of today's games derives exactly from this mentality: "Bah, optimization - we have LOTS of memory and cpu power". Maybe the most important rule in programming seems to be: "Whatever the power of the machine you program for, in the end your code will end up to be 5 times larger AND 10 ti,es slower than you initially expected".

But okay, YOU are the coders - I trust you on this. Concerning coding, I can only give some hints how I dealt with some strategy game-related questions earlier on - but for now, seeing it has been neglected, the graphics are my main concern.

Let's assume I'd like to be involved and let's assume you'd appreciate that - how to start?

From my point of view, first a graphics design team must be assembled, which will then ask you coders what graphics are needed. We then have to settle on a style and who's doing what graphics - you get the best result if e.g. one person does al the units, one all screen elements etc. This avoids any inconsistency in style and quality.

This should start SOON - even if the development of the game takes 1-2 years, it's good to know how much time there is for any given image. As you can imagine, e.g. a unit imatge (animation) can be done really fine if I know I have 2 weeks of time for it. Do not forget the inspiring impact of good gfx on all concerned with the project - good gfx are something like YOUR brainchild coming alive. Wouldn't we want lhem to be great?

One last thin about the alpha channel thing: You mentioned the word "filtering" - yes, essentially that's what I mean.

So, to put this straight:

Is it possible to use the following procedure in Java when putting a unit on the screen:

- fetch a rectangular unit image from memory
- fetch a cooresponding alpha mask and tint some part of the image according to the alpha data (player color)
- fetch a second alpha mask and apply the tinted image as according to mask 2 to the terrain tile on the screen?

Seems to be a freakish detail, but is very important for all future gfx work, so should be decided SOON

A quick example using an old favourite - loop unrolling. These days, unrolling loops could actually SLOW DOWN a program because a small, tight portion of code fits into cache memory far more easily than a huge unrolled loop.

Even though looping introduces branching overheard and possible pipeline stalls, memory concerns are paramount.

For memory access, a cache miss can be up to 50 times slower than a cache hit. The cost of this in CPU cycles increases as the gap between memory and CPU performance widens.

This leads to far more serious performance penalties than anything introduced by Java's bytecodes.

Because cache sizes, mapping systems and replacement algorithms vary so widely, low-level optimization has become a very hit-and-miss affair. It's far more economical in terms of effort to concentrate on high-level algorithmic optimizations.

Anyway, regarding images - I don't really have time to look deeply into the graphics stuff at the moment, 'cos I'm in the middle of exams.

I'm pretty sure that the Java2D library contains all the image-processing routines you'll need. The javasoft website should contain plenty of documentation on the subject.

I'm sure that Mark will welcome you to our team with open arms when he arrives back.

And I agree re: the coordination you seek. This must be done. If you're interested, I'm betting the job is yours . . .

Also, as a 'turn-based' strategic game, we'll probably have a lot of leeway with the performance. For the RT tactical part, we won't be tracking anywhere near as much data as the AoE-type game that can have hundreds of sprites to track. Each side might have at most a dozen 'units'. The size of the units will just change.

But thank you for bringing up the performance question. I believe it is very important also. I've got a reputation for being able to bring in simple, stable code with powerful functionality, and I fight that battle daily. 'Scope Creep'! Everyone wants a chat applet that can make pancakes and do the dishes. Go figure!

Is it possible to use the following procedure in Java when putting a unit on the screen:

- fetch a rectangular unit image from memory
- fetch a cooresponding alpha mask and tint some part of the image according to the alpha data (player color)
- fetch a second alpha mask and apply the tinted image as according to mask 2 to the terrain tile on the screen?

Also, yes -- it is very easy to lay the 3 images over one another. I believe the coding would be to actually load the image into memory (getImage), then create an ImageFilter, then use FilteredImageSource. You can filter parts of an image different colors.

Now you got me thinking -- I'll try and put a demo together tonight.

---------------------------------------------

Of course, agreement on a gfx style is very important - one can change many things later easily, but a change of style means doing everything twice...

Any input?

And, ah, yes, of course one man (never mind my female nick) is just not enough for it - I guess we'd need at least 3-5 commiyted artists.

In the demo screen online now I see lots of little numbers - should these always be visible? Or not better optional or via right click only?

It's not really my concern - my areas of expertise don't require anything specifically from 1.2, so it makes no difference to me.

I've been using 1.2 for my work but it will compile equally easily under 1.1.

I suggest you consult Mark on this matter - he seems to want to use JFC (which requires 1.2).

Re: performance

Mark's AI ideas will be pretty heavy on the CPU cycles, but since we are keeping the RT portion to a minimum, it shouldn't be too much of a problem.

You're completely right on -- the screenshot that you saw was only the background code, with no thought to screen output except for debugging purposes.

The basic layout of the screens will not likely change, but the look and content of each screen hasn't even been considered. All we really have, graphically, is a basic form in early, ugly fashion.

And I didn't do any coding last night. Actually spent some time with the Wife and kids. Tonight, tho, I've already got clearance from her majesty to work on a simple animation demo.

Oh -- as far as 'style' goes, I do have one (probably hopeless) suggestion. I've always dreamed of doing a game with 'claymation' style graphics. Is that even remotely possible?
*********************************************
Jim:

If it doesn't impact you, Mark agreed last week that we can stick with Java 1.1 for now. The JFC/Swing classes are available in 1.1.6, under a different package name (com.sun.swing), altho there really is no reason to use them now. We can change the import line later, if/when we migrate to Java2.

It would just save us some distribution problems, since IE4 doesn't support Java2.

As they said, I'm quite interested to use your skills. Welcome to the project . As you percieved we certainly do need a champion for things graphical on the project. However, I'm sure you realize that we will have to discuss all your proposals and see what everyone thinks. I'm interested to see what F_Smith comes up with for speed for the alpha-channeled images. There is also the big issue of clock cycles devoted to graphics in general etc that we need to address too. As you point out it is easy to be drawn incrementally into something that won't run very well on many of today's machines. I think the focus of Clash needs to be elsewhere than on the graphics, since, as you say, we can't be cutting edge in that area anyway. But with hard work a good implementation that is say 1 1/2 generations behind cutting edge should be doable.

I admit to having been considering basic civ2-style unit graphics as the way to go. I've had some nibbles from people potentially interested in doing units for Clash, but there are no firm commitments as of yet. Mog the Orc is the only artist we have a committment from at this point. Right now he is examining a photorealistic-based tiling concept for the map.

I like your ideas about civ-specific borders, city graphics etc.

Frankly, what the project needs right now is someone with good organizational skills to start bringing a group of artists and graphical design people together. I am too occupied with other things to be able to do this job even Vaguely properly ;( . From a graphical team we should have fairly soon some samples of different broad styles of units etc for the whole Clash team to look over and make a binding decision on. If you would like this job we would be very happy to have you in it. I just want to make sure you know at the start that many great ideas you have may have to be shelved due to other constraints... If you're interested in this job I have some names I can pass you.

If you would like a more modest job, that would be ok too, and the hunt for someone to organize the graphical design will continue . Just let us know the case.

Regardless, you should probably read as much as you can of what's up here. For instance the mil/combat system mentions that we are headed more for army groups rather than individual units. This has ramifications on the importance of individual unit design vs having many images for armies the player can select.

Everyone:

We also need to discuss the java 1.1 vs 1.2 issue soon. I'll start another thread on that soon.

-Mark

Grafix Try #1. I was able to filter the image (the greyed one is the same image). Also, click on the screen and use your arrow keys, the original image should move around the map.

But this is over my head, because the RGBImageFilter class uses the 'default color model', which is a 32 bit integer -- 8 bytes for the 'alpha component' (something to do with transparency/opacity) and 8 bits each for red, green and blue. I found code for grey, but I'm really chomatically challenged, guys . . .

I've got code samples for fade in/fade out, sharpen/blur, resize, rotate, and crop.

Well, before we get to the organizational stuff (erm... I'm not THAT great an organizer...) let's get the alpha thing done - I'll send you some small gfx as I intend them to be in some hours, so we both know what we're talking about, ok?

Btw, am I right in the assumption that the gray landscape in your applet is a plain JPG file? It's no calculated image, I mean?

Later.

First, the image of a valiant warrior (just a quick'n'dirty sketch)

Then we have a genercic backdrop ("terrain")

To blend or warrior onto the terrain and make his shadow not black, but only darkened, we apply this mask:

So this is the result:

We have another mask for the shield only, the color of which should show the player our warrior belongs to:

...and by applying a color change to the original warrior according to this mask, we get the warrior for player blue:

So, that's the "alpha thing"

[This message has been edited by Ladonna of Thar (edited May 17, 1999).]

No worries on the org thing. Glad to have you with us.

-Mark

Thx for the warm welcome

Alas, I wouldn't call myself a "champion" - I just know to use the tools of the trade - certainly I wouldn't compete with a Doc Ozone or the like...

As I already said, first a general agreement on how the baby should look must be made. My personal opinion is that we should strive for something in between CIV2, CtP and AoE, but maybe that's only because of me liking those "antique" gfx so much.

And as for "cutting edge" - is it necessary? Just don't let it look old-fashioned, that's all. I mean, you can only do so much realism, right?

As for the artists: While I certainly can do some gfx myself (and planned to do so, anyway), we need more people with defined areas of work. Just so that we talk about the same thing: If I know there will be, say, 100 different unit types in the game, and we have a team of 4 people doing the gfx (for the units only), let's say one for antique units, one does ships, one cannons & tanks and one jets and spaceships, this leaves 25 units for each artist. Now, let's say we aim at June 2000, so we have roughly 2 weeks for each unit, right? I can assure you, even nonprofessionals can get VERY nice results in 2 weeks. E.g. the little warrior on this page (bearing no real clothes, armor etc.) took me half an hour...

About the organization: Frankly, I suck at organizing - I'm just too chaotic, really. While I'm quite good in planning and designing, I wouldn't trust myself with the organization of a dinner party

Well, maybe we should get the gfx team together first; everything else might simply develop, hm? You planners / coders simply have to inform us on what has to be drawn.

I have read many things here in the forum - frankly, I doubt if even 1/10 of all the ideas can (or even SHOULD) be implemented, making it WAY too complex (and slow?). But it already seems next to impossible just to get all the info. Maybe the best start would be to set up some HTML pages which define

- what is fact now?
- what is planned?
- who does what?

What information that exists right now is on the status link off the main Clash web page. The page is at: people.mw.mediaone.net/markeverson/clash_status.htm

Its not completely up to date. We are still refining what exactly goes into Clash. The target is to have all the Big issues figured out by 5/31/99.

I think its fair to say that the preponderance of opinion is that civ2-ish graphics are the way to go.

I can organize a dinner party with relativelly few fatalities , but organization ain't my strongest area either.

BTW I like your quickie demo images, but am a little concerned on how a style like that will scale down by arbitrary factors. (Of course in civ2 its not perfect either)

-Mark

Yes, we can easily do that layering. And yes, the background was just a simple .jpg I grabbed off the web.

The warrior is excellent. I'll try putting him and his layers in the graphix demo next (maybe tonight?), and use the terrain tile you have there to generate a map.

But can I make one little suggestion? For the turn-based portion, we only need one graphic per civ for 'armies', don't we? Since an 'army' will be a combined group of thousands or tens of thousands of men, using an abstract graphic might be best?

LOL. I think from one to several armies per civ is more like it for the ancient period. And also there'll be individual garrison units here and there to deal with barbarian incursions and such. As you get into the modern age and troops are much more dispersed along fronts I'd imagine we'd have a mixture of individual units and armies.

I'm sorry about your Grandmother. I hope everything went well.

Just thinking out loud, but what if we simply used one graphic per civ to represent an 'army'? Like board games use to do?

Or, at most, one graphic for a mobile army and one graphic for a non-mobile 'garrison'?

But, okay, if I take the "gfx demo" as a first assumption regarding the dimension, there's of course simply no use in trying to depict even half a dozen tiny warriors on 40 x 40 pixels... although... one could at least TRY do do some "Fields of Glory"-like gfx.

I propose to have strategical icons for the overview scale but some "eyecandy" gfx for detail scale. What of the following:

On the standard overview map, you have icons. But there should be a small window giving away detail information on that army (stack(, including a representative ("eyecandy") image of either the predominant unit type in that army or simply a scrollable list. This image, reduced in size, could be used as icon in a more detailed (zoomed) view of the map.

Please do not forget that while you may be hardcore strategy gamers and can pretty well get along with simple, numbered counters (I know I can), most people want some visualization of what they are commanding. Remember the beautiful, very detailed images of the "General" series? That's the way to go, I think.

Btw., think about it whether you REALLY want to have a flat square map. CIV2-like isometric view is lower standard today, I'm afraid.

Like I said, most people seem to agree that civ2-like isometric view is the way to go for Clash. The top-down map was an easy thing we did early on, but I think we need to change the demos etc over to the isometric style asap.

Gif is the standard image file type in java so far, although the newer 1.2 image capabilities may be more flexible I just don't know for sure...

One suggestion, Civilization and its brood are springboards for your design, don't feel limited to making "Civ the way it shold've been.". You're proposing a better reasoned game, right now, already.

Would it be possible to place the cursor over army group icon for a moment and have a box popup with the grapical picture of the units in the group and their vital statistics? That would be very useful. Also, I think that the icons should be somewhat different for each army group and be in the color and style of the players nation. For example, a blue lightning bolt, a blue flaming sword, a red wolf, whatever - not a little figure, but a stylized counter with something immediately recognizable on it.)

Glad to have you. Post away!

I agree with both points. We will have 'tooltip' type info on units. And I *love* the suggestion of identifying a unit with a province -- esp. the history of the legion concept.

***************************************
LaDonna:

Not off topic at all IMHO (btw. I just changed my nick from "Ladonna" back to my REAL name ).

Now, the idea with the little badges / logos looks most intriguing to me - that way each army group could have it's own "coat of arms", something that was true in history and still is today (over here in Germany, those divisional badges were scoffed at because they looked like the old Wehrmacht badges to some radical renewers... about 15 years ago they were re-introduced because intelligent people had recognized how important it is to identify himself with his unit, which is easier having a badge or the like).

So, I fully support this idea - makes you, the leader, having a more "personal" relation to your units. Not simply "some knights" but "the Most Noble Order of the White Wolf". Sounds great, doesn't it?

And, in game terms, it's certainly helpful to be able to identify a certain formation on the first look, especially since we are considering using the same all-around army image for all units of a nation.

Great input, Xiane, I love it!

F_Smith (btw., what does the "F" stand for?):

As I said to Mark, neither GIF nor JPG are the ideal formats:

JPG is lossy at for this reason alone a no-no. Furthermore, it's quality lessens with each "load-change-save" procedure, and you never know when you have to edit an image for the xth time (let alone making it harder for the players to edit their images).

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 - especially in a situation like ours, who are spread all over the world.

Isn't there any way to import TIF or TGA? I'd even settle for BMP or IFF (both should be easy to use in your code).

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

A little positive re-inforcement and I'm back for more. First if you could pick a target hex/square for your army group and one of those impresive looking arrows like you see on maps in war movies would appear in your color on the map leading to the destination (semi transparent maybe?). It would be big or small depending on the size of the force.

sorry to disappoint you, but compliments from ME don't count as much since I only joined the project some days before - wait for Mark's or F_Smith's comments...

Anyway, your idea of those "impressive arrows" is not totally new; the computer version of Axis & Allies uses them, and they slow down the game considerably...

Anyway, I agree with you that these look quite good, and since we do not have an irregular map (like Axis & Aliies), but one in square / diamond tiles, this should be feasable whit much less computing power. Would be nice, I think.