How To Win A Demo Compo

Note: All my previous articles, including this one, are also available as a formatted, hypertext documents at http://www.mcs.com/~trixter/html/demos.html#editorials.

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.