kaioa.com

Speed - we need more of it

Back in the Days

Do you remember those days you started programming? Back then all I had was a Commodore 16, one and a half bad books, and BASIC of all things. The really awkward kind with numbers in front. Incrementing by 10 every line in case you need to insert something later on. Drawing a Sinus curve took bloody ages. You could literally see how it was plotted pixel by pixel.

Later at school I had some C lessons. I liked C a lot. It was fast enough to do draw some odd effects in real time and the code looked so much better than C16 BASIC. Well, big deal. But back then it was truly the holy grail for me. I also got introduced to that odd algorithm stuff. Bubble sort. Gasp.

Just a small change and it ran twice as fast. I was really amazed by the impact. Of course I know now that there are far better solutions for this problem, but back then it was really impressive. I guess that's the point where my perfectionist side started to pay more attention to the details.

Omitting the Reason

Better performance is a good thing, we were told. Of course it is. Everyone could tell that it's clearly better if the program runs faster. There was really no need to tell us about this obvious fact.

The interesting pieces of the whole picture were omitted, however. Optimization takes time - lots of time in some cases. Time is a very valuable resource. There had better be a good reason to do all of this. Otherwise, you'll get a less favorable return/investment ratio.

It's simple math. If your optimization extends the required time by 10% and the result is 9% more sales, it wasn't worth it. You worked harder and lost money (i.e. your hourly wage took a cut). Those resources might have been more effectively spent elsewhere. Marketing or polish would have been good candidates for example.

Performance Goals

It's really odd, but many people don't think about it beforehand. You need a specific set of target requirements from the very beginning. Otherwise, you won't know what you're aiming for. Everyone thinks about platforms and APIs, but this equally important detail is simply left blank. Many simply optimize everything over and over again without a clue why they are doing it in first place.

They simply lack direction. They don't know where they are and where they need to be. The worst part is probably that they can't tell when it's time to call it a day.

The eye-catcher in the upper right illustrates this scenario very well. As you can see there is no x-axis and no goal marker. Was the previous (blue) version already good enough? Nobody can tell.

What's a Good Goal Then?

If you target a fixed hardware setup like a specific console, you already know the answer. Make it run at 30/60fps (or whatever is adequate) and that's it.

With web or shareware games it's more complicated. For the most part it depends on your audience, but fortunately there are a few generally valid pointers:

Hardware is meant to last about 6 years

• PCs are often replaced earlier.
• HDDs typically fail earlier.
• At the end of their lifetime they often die completely.

Those games are typically around for a few years

• Some generate income for over 8 years.
• 3 years appears to be a reasonable guesstimate.
• For web games the first year is often the most important one. (Getting popular, doing its rounds across the web. After that it's old. People will continue to play it, but they won't bring your server down to its knees anymore.)

The percentage of integrated GPUs is rather high

• Old Intel integrated chip sets had very little fill rate to offer.
• More recent Intel integrated chip sets are semi-usable.
• Nvidia and ATI integrated chip sets are also semi-usable. They offer quite a few features, but are also rather fill rate limited.

TFTs run at 60hz

• Being able to render 200fps instead of 80 is worthless if the player will be only able to see 60 of them.

Putting Things into Perspective

The Athlon XP 2000+ CPU for example was released back in January 2002. Well, it was high-end back than, but you get the idea. That CPU was already pretty beefy. About 6-8 times faster than a K7 or P3 500. And such a puny K7 500 together with a Geforce2 MX (classic/400) was already good enough for massive 2D action. Spitting out 2000 sprites in idiotic immediate mode at 60+fps - no problem. Puppygames' smash hit Titan Attacks also ran fine for example.

Some of the shader-less 3D stuff was also fine such as Oddlab's Tribal Trouble. Amazingly even that was playable on that rusty machine. Java 1.6 and an OpenGL binding (LWJGL) made that happen.

Flash wasn't much fun though. No hardware acceleration anywhere in sight except that full screen scale stuff, which didn't seem to have any impact on anything. Things are going to change with Flash 10 though.

However, with an XP 2000+ (or the 1500+ one if you like) things look really different. You get a mind-boggling amount of processing power there. Enough to use some physics or lots of geometry (if the graphics card is up to the task). And even slightly more complex Flash stuff starts to become fun on that level of hardware.

Things to Keep in Mind

1. Pick a target configuration. And keep your goal-distance/buffer-zone in check.
2. Performance is usually the least of your problems. What's far more important are: eyeballs, eyeballs, eyeballs, content, conversion ratio, content, game mechanics, content, replay value, content, USPs, and content. In that order.
3. Nowadays we got great tools called profilers. Use them to identify the actual bottlenecks in your game. Take care of those if you have to, if you want to, or if you can do it quickly enough.