A Brief Warning: This article is meant for the fledgling (or confused
:-) demo group/coder, and assumes the reader has a basic understanding
of demo terms, slang, and demo effects. If you do not have this
understanding, or are a little rusty, check out the URL
http://www.mcs.com/~trixter/html/demos.html
before you read this article.
NAID was certainly one of the most surprising demo compos, and I was
very glad to have been one of the judges. Since NAID, I've been asked
by many of the people who entered the demo compo how they could have
placed better.
Without going into a technical list of things immediately, I'll offer
the most obvious answer right now: Design.
First, let me explain this rationale. Sure, optimizing effects is
important, of course, but every year we keep hitting the upper limit of
what our PC's can do. It's getting to the point where previously
original effects are now becoming commonplace, like Gouraud shading,
environment mapping, texture mapping--even Phong shading is becoming
common. We need something *original*. We need something *different*.
After all, aren't demos really a sophisticated art form?
Design is the number-one factor that will ultimately impress the
audience. Everyone has seen 3d cubes rotating on the screen, but how
many have seen 100 or so cubes slowly combining to form a larger,
complex object? Everyone's seen a 3-D ship flying through a 3-D vector
city, but what would happen if the ship flew inside one of the
buildings? What would it see inside? It's that original
quality--style--that demos are missing and need badly.
What if you already have design, but the audience or judges didn't rank
your obvious Second Reality-killer number one at the compo? Well,
there's many things that factor in a lower or higher score--follow this
checklist before you submit any demo to a compo:
Try Bezier curves for object movement/paths. Many objects in demos
today either don't move at all, or they start/stop/turn "on a dime".
Jerky movement looks hurried; smooth movement looks professional.
Code for faster framerates, even at the expense of *less* objects.
Use ModeX (or a derivative) if you have to. The audience is used to
seeing stuff running in either one or two frames, which is more pleasing
to the eye anyway. While the coders in the audience might appreciate
all the hard work involved with trying to display 1000 texture-mapped
polygons, the frame rate can never go faster than about 15
frames-per-second doing computation intensive effects. The result, no
matter how optimized, has the *appearance* of slow code, and might not
please the audience.
Make sure your demo has a consistent look and feel. Try to keep the
style of music and graphics along the same vein of style or thinking.
For example, if your demo has a techno-part at the beginning, that's
fine, but don't have the harsh, pounding techno music still playing when
you display your soothing, peaceful voxel landscape. (An exception to
this would be something like the landscape accelerating up to warp
speed, where it would match the frenzied pace of the music.)
Try to sync the graphics to the music whenever possible. It's usually
simple to do, and heightens the overall effect considerably. Look at
Second Reality and Tome of Opticron for some examples.
Never assume your audience won't notice anything. The audience, a
pack of demofreaks, is looking at your demo very intently for two
reasons: 1. They've never seen it before, and 2. They're going to award
the best three (or more) a prize. If you have a small flaw in your
z-buffering routines, for example, and part of a solid object goes
hollow at some point during the demo, the audience will most likely pick
up on it and remember the flaw, even if it only happens once.
Do not rip ideas, music, graphics, or code. It doesn't matter if you
are paying homage to the original author or mocking him--do *not* rip
anything. Ripping is nothing but plagarism, and coders in the audience
who are fluent in democoding and demos can spot this a mile away.
If you absolutely have to use a standard effect, do not try to emulate
the original. The audience doesn't want to see another texture-mapped
dolphin, Gouraud-shaded duck, or "Intel Outside" logo spinning and
zooming. Besides, if your effect is too close to the original, the
audience might think you ripped the code (see last point).
Don't brag. Even if you are a widely recognized group, it might be
advantageous to wait until the end of the demo before announcing your
group. This way, the audience won't be dissappointed if the demo
doesn't live up to their initial impression. (I'll explain a little
further: Let's say you're, oh, Future Crew, and you announce that fact
right at the beginning of the demo. Already, your audience has in mind
all the good connotations, feelings, and experiences associated with
Future Crew. As rewarding as that is, it's also a major strike against
you, because now you've got to beat your previous efforts, or else the
audience will end the demo feeling dissappointed--because you didn't
meet *their* expectations.)
Granted, some of the above might seem like common sense, but it helps to
review. Keep in mind the above knowledge when coding or designing your
masterpiece, and your 6th or 5th-place demo could place 2nd or 3rd next
time. Good luck!
Comments or Suggestions on these WWW pages? Email Trixter.