What I could offer to the project...

[Ladonna of Thar]

Having seen no thread within the last days especially addressing the graphic design, I put this on a new thread.

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


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

[F Smith]

Hi:

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.

Second, Java carries too many benefits to go with the old C++. Connectivity and distributed design are going to be two of our biggest assets. We're sort of leaning towards a Microsoft 'Zone' type setup (or Ultima Online, or Yahoo Games, etc). A perpetual world of worlds, so to speak. Also, I'm led to believe that the performance will be satisfactory, esp when 'HotSpot' becomes widely available later this year.

[Ladonna of Thar]

Hey, that's a quick answer indeed!

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

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

[Ladonna of Thar]

Okay, fine... I tried Java only once, but since I didn't really feel a need to learn the language (most applets on the web are simply redundant, Perl being the solution for most web problems), I stuffed back my Visual Cafe. As for the performance... well, please be patient with someone whose last actual programming was in the days of the Amiga 500 and I had to fight for every byte ad every speed optimization possible...

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




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

[JimC]

Oh, I'm not saying that optimization isn't important, it's just that priorities have changed....

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.

Jim

[F Smith]

Yes -- we would love to have you. I'm sorry if I didn't say that explicitly before. I guarantee you Mark will agree.

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.

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

Jim: Are we planning on sticking with Java 1.1 for now? It would greatly ease our compatibility probs, and it's usually better

[Ladonna of Thar]

Wow! That sounds promising - I can't wait to start

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?



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

[JimC]

Re: Java being too slow....

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.

Jim

[F Smith]

Cool:

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.


And really, the performance speed will not likely be a problem by the time we're done. Current Vm's are almost as fast as native code, and the new JiT Vm's coming out (i.e. HotSpot) will push speeds faster than current C++. Line per line Java will execute at about the same speed, but it only takes about 1/3 the lines of code in Java, hence much faster performance.

[F Smith]

Oh -- just saw Jim's post.

What he said!

Performance is not likely to be a problem. But thanx for mentioning it, we are rather new to all this (at least, I am!).

[JimC]

Re: JDK1.1 or 1.2

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.

Jim

[F Smith]

LaDonna:

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.

P.S. -- I don't know if I've said this before, but the A* applet is sweet. Good stuff.

[Mark_Everson]

Ladonna of Thar:

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


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

[F Smith]

Okay, here's something, anyway:

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.

So -- someone with a brain help me figure out what 'blue' is on this 'RGBImageFilter'!

[manurein]

Hey man! I tired your applet (work on NT4/SP4, Netcape 4.51).
I think u have something with this!