textfiles/programming/artnotes.txt

Newsgroups: rec.games.programmer
From: dis6218@ultb.isc.rit.edu (D.I. Seah )
Subject: Re: :Got the programming part down, what about Graphics ?
Organization: Rochester Institute of Technology
Date: Tue, 11 Oct 1994 21:25:07 GMT

In article <76.2787.25.0N966AF2@teaminfinity.com> game.guru@teaminfinity.com (Game Guru) writes:
>We must be missing tools, or some basic knowledge re computer game art
>or both.  For example texture mapping and gourad shading and other
>effects must lend themselves very well to creating realistic stills that
>can then be incorporated into a game.  Some mechanized way of producing
>graphics if you will, because I cannot imagine someone doing much of the
>game art we have examined one pixel at a time, a sort of "Cant see the
>forest for all the trees" problem.

Lord, do people still program entire programs in assembler? Yep, they
do, for similar reasons that computer artists worry about single pixels.

You can think of a paint program (such as DeluxePaint II) as being your
compiler, and single-pixel work as your assembly language optimizations.
Does the pixel look better on THIS side of the curve, or THAT side?
The visual effect may be very small when taking that one pixel into account,
but the same thing can be said about optimizing your loops. It's the
agregate visual effect that will make a difference...it's clean and not
marred with defects that detract from the image you are portraying.
 
>Any direction or principles for making realistic game art would be very
>much appreciated, especially shortcuts and condensed wisdom and tips.
>We are mostly working in the 320x200x256 VGA world currently.

When you do computer art on a screen, you have to be aware of both the
overall look ("the forest", as you mentioned before) and the details of
drawing/implementing it ("the trees.") You have to learn to switch between
the two ways of thinking very easily. 

You might think of it in terms of the implementation of a particular
algorithm. You know what's supposed to happen, theoretically. Now, the trick
is to implement it. If you're one of those programmers who pride themselves
on "good programming practices", you might find yourself constantly
assessing your implemtnation from that perspective. "Am I following good
Hungarian notation?" "Are my variables descriptively named?" "Do my classes
live and breath the spirit of good object oriented design?" These are larger
issues that go beyond the task of just cheesing out something that works. It
can get in the way if you obsess about doing it "right" the first time. So
many programmers implement the algorithm first, then worry about
optimizations and style later. With more experience, a programmer can start
doing it right on the first go. 

This is quite similar to doing the art on the computer...  you may want to
sketch the stuff you're doing first...is it "right" for your application?
Does it look good to YOU? From an overall standpoint, not just from
carefully selected standpoints. It's doesn't help to think, "Yeah...I did a
great job on that glossy highlight on the hull of that space ship!" if the
spaceship itself, and the overall picture looks terrible.  It's the same as
crying, "But I optimized my bitblit routines to be the fastest in the known
world!" when your overall game sucks rocks in game play. You HAVE to consider
the overall package, both in programming and in art.

Philosophy aside, here are a few random thoughts:

Make your lines CLEAN! Use horizontal and vertical lines when you can if
you want something to look high tech and precise.

Curved surfaces should be "smoothly curved", not "dented." (unless it's an
effect that you intended). If you can tell whether the front end of a car
has been in an accident and repaired, you will have shown sensitivity to
curvature. There are an infinite number of curves you could put between two
points...choose one that does what you want.

COLOR has three aspects: HUE, SATURATION, and VALUE. Many beginning artists
think of color as just being HUE (that is, what rainbow color it is). 
Consinder also SATURATION (how vivid it is) and VALUE (how bright).
If your artwork looks flat and uninteresting despite "the number of colors
you used", ask yourself if you used contrasting values (light and dark)
and saturation. It makes a difference.

LIGHT is very important. We don't perceive objects as things with lines
around them as much as we perceive their form as it interplays with the
surrounding light. 

PERSPECTIVE, when screwed up, looks really bad. If something looks wrong
to you, it probably is wrong. This is where you might want to spend some
money on a 3D package, though this won't teach you how to do good 3D
design. At least the perspective will be correct. Then be aware of the
different effects that perspective can have...wide angle, narrow angle
have different effects...the wide angle shots are more dramatic in that
they exagerate perspective. Then, be aware of various perspective cues...
fading light, position in the picture plane, desaturating colors,
loss of detail...

The ELEMENTS of a screen design serve various purposes. Some of them are
meant to be seen first and used. Others are meant as decoration. Treat
the elements visually as they should, depending on their function.
If you have a background that is just supposed to be, like, a background
for the real action, don't make it bright red with blue squiggles on it.
That would distract from whatever is going on that important. Tone it
done, either by dropping its saturation or value.

Creating images requires progressive refinement. React to your work
in different ways. See which parts work for you, and which parts don't.
For example, you might look upon your spacecraft and think, "Man, it's
lame. But I like the engine highlights...it looks cool. It's just that
the ship look so....clunky. It looks like a volkswagon that kissed the
guardrail at 3mph. It's stubby......maybe if I lengthen the nose....hmmm."
Think yourself through WHY you like something or not. 

>We have looked at VanDamme but thought it a little too discrete and
>abstract to be useful to us in an operational/production sense.

"Computer Graphics, Principle and Practice" is way overkill...that's a book
that is more for the programmers and theorists. However, it does have
a good user interface and design section that, while somewhat dry, does
give you a starting point.

Actually, one good one to look at in terms of screen design philosophy
is Apple's Human Interface Guidelines. Some of it is Mac specific, but the
introductory section is a distillation of other sources that is concise
and well-written.

For ideas about process, look for the magazines "Step-by-Step Graphics" and
"Step-by-Step Electronic Graphics."

The key idea, I think, is that you have the power to OBSERVE. Make good
use of that. Make sketches. Take notes. THink up from small details to
large impressions, reflect upon the grand scope of your art, then go back
down to the details. The image will evolve in pieces and in steps...be
patient as you work it out. Be open to detail, but don't be absorbed by
them. Be open to shape and form, but don't forget detail and texture
where it is appropriate or desired.

Then, keep in mind that a 320x200 screen is going to be tough to work with.
You can't draw detail on small ships because the pixels are just too damn
big. However, you can learn to hint at detail (through shadows, perhaps), or
just dispense with it altogether. You WILL agonize over the positions of
individual pixels. You will also have to learn how to ignore the chunkiness
and just see the "impression" of detail. Take a look at the characters in
LucasArt's "Indiana Jones and the Fate of Atlantis" as an example. It's
also interesting to compare those characters with the ones from Westwood
Studio's graphic adventures. The images work not so much on microscopic
detail, but on the impression that it's there. Also, the lighting is
taken into account as textures of clothing and materials are drawn.
The proportion and form of the characters in their surroundings is 
accurate.

Hope this helps getting you started!

-- 
Dave Seah (dis6218@ultb.isc.rit.edu, PCCDaveS@aol.com)