What's in a Game?

The first thing most programmers think of when they start coding a game is the graphics system. They'll start with a DirectX sample, import some of their own miserable programmer art, put an environment map or a bump map on everything in sight, and shout "Eureka! The graphics system is finished! We'll be shipping our game by next weekend!"

By the time the next weekend rolls around, the same newbie game programmers will have a long laundry list of things that need to be done, and there are a number of subtle things that they will have completely missed. These hidden systems are usually the heart of every game, and you're never aware of them when you play games because you're not supposed to be aware of them. By the end of this chapter, you'll have a brief overview of the main components of game code and how they fit together. The rest of this book digs into the details of these systems and how they are built.

Display Technologies: A Quick Overview of the Issues

Display decisions include bit depth and resolution and the core graphics technology that pushes pixels: 2D, 3D, or a hybrid of the two. The Playstation and Gamecube coders out there can skip the resolution and bit depth section because those are chosen for you. Xbox and desktop coders are still in the discussion because you have some choices about what resolutions your game will support. Only the desktop coders need worry about bit depth. Everyone should worry about the core graphics technology.

Resolution and Bit Depth

It might seem crazy to support a 640x480 8-bit palettized mode in the 21^st century. I can promise you it's equally crazy to assume that everyone buying computer games has flame-thrower CPU/video card rigs that can push 1280x1024x32 at 75 fps. There's really one major question that you need to answer before finalizing on a minimum acceptable resolution/bit depth: What will sell the most games?

The Microsoft Casino/Card projects I worked on at Compulsive Development were clearly marketed at the casual gamer—people like my parents. They have computers that are three to four years old and therefore look ancient to most programmers. The VRAM is 1/8 of what most developers use, 1/4 of the CPU speed, and 1/8 of the system RAM. Face it, these computers are better used as boat anchors than game platforms! Still, there are plenty of those boxes out there if you are going for the Wal-Mart crowd, a lucrative market indeed.

On the complete opposite side of the spectrum, if you are working on the latest and greatest graphics game specifically for the hard core shooter market, you'd be nuts to code your game to the same pathetic standard. Instead, go for a bit depth and resolution that can make the newest and best game rig eek out a solid 60fps. You'll be pretty sure that the early adopters will have the best rig to make your game look completely fantastic at its highest resolution.

Best Practice

For the longest time, Ultima fans had to upgrade their computer every time the new version was released. Look at these minimum specs: Ultima I-IV: Apple ][, Ultima V: IBM PC/CGA, Ultima VI: IBM PC/EGA or Hercules, Ultima VII: Intel 386/VGA, Ultima VIII: Intel 486/VGA, Ultima IX: Intel Pentium 233Mhz/VooDoo 3Dfx. Having worked on many of these games I realized that the programmers would always get the latest and greatest hardware at the beginning of the project and write the game to work well with that technology. The problem was that after 18 months of development, the code was already slow enough that the programmers were already screaming for hardware upgrades; after all those compile times were going to cut the company's productivity in half! It seemed that every Ultima was shipped requiring hardware that was considered bleeding edge only six to twelve months before. If you have a game that has a wide hardware requirement, make sure that at least one programmer has a second machine on his desk that matches the "dirtbag" minimum spec machine.

By the way, I think it is crazy to support 8-bit palettized displays in any game. This includes kids games or casual games. You can make a safe assumption that if a piece of hardware was bleeding edge five years ago, you'll find it in wide use in any casual gamer's hardware profile. Since the release of Windows 95, 16-bit displays were common, so I think it's a safe bet you don't have to support 8-bit displays. It's a good thing, too, because it's a real hassle to support 8-bit modes in a Windows compatible game.

Leaving 640x480 in the dust is a slightly harder decision if you are going for the low-end market. The two things that will limit you here are the ability to push pixels from system RAM to video memory (VRAM), and how much VRAM you have to play with. You'll find that low end machines with a 2Mb video card simply can't draw 800x600x16 screens with anything more than 35% overdraw before the frame rate will drop to the dismal teens.

Best Practice

Set every display related technology decision to meet your minimum frame rate goals. Consoles will require a minimum frame rate of 60fps, which is extremely difficult. Desktops can get away with much lower, but try to hit a minimum frame rate of 30fps.

To find your maximum theoretical frame rate, you first have to know how your game draws pixels: 2D, 3D, or a combination of the two. A sprite game generally copies memory from system RAM to VRAM, or from VRAM to VRAM, sometimes accomplishing some interesting blending tricks on the way. 3D games use software or hardware to fill a series of triangular areas of the screen with shaded color or texture data. Just in case it isn't completely obvious, these two methods are completely different and you have to use different methods of calculating your maximum theoretical frame rate.

A 2D sprite engine is easier to estimate. You can calculate your maximum theoretical frame rate by knowing something about your hardware and how you'll fill up the VRAM and system RAM. First look at the video hardware and find out the maximum transfer rate from system RAM to VRAM. There can be some tricky caveats to that, too, since some video cards transfer memory over different bus architectures (PCI, AGP, and so on), so be sure you have the proper transfer rate. Take a look at the transfer rate both directions, since you'll use a VRAM to system RAM copy to perform some of that interesting blending.

Once you have the transfer rates, take a look at your screen designs and try to estimate how much of the screen is going to be drawn every frame. You might discover that this figure exceeds 100% of the pixels. For example, if you have a multi-layered side scrolling fighting game, you'll be redrawing the background every frame as well as anything on top, such as the characters or special effects.

Take special note of anything that will use alpha blending or chroma-key. A completely opaque sprite, a rectangular shape that has no transparent or semi-transparent pixels, is essentially copied from memory to VRAM, an extremely fast operation. A sprite that has some completely transparent pixels must check the source sprite for a particular color value or chroma key before copying each pixel value. This is much slower, as pixel-per-pixel operations/comparisons use more CPU horsepower. The worst case, of course, is any sprite that uses semi-transparent pixels. This case requires both the source and destination pixels to have a blending calculation or lookup, which is much slower than a simple comparison and branch.

Clearly if your game design requires multiple layers of semi transparent sprites with an average of 180% pixels drawn per 800x600 frame, you won't accomplish this on an old Pentium 133Mhz and 2Mb video card. In fact, you'll find that 130% screen overdraw with simple chroma keyed sprites will still kill the frame rate of this old beast. If you are unlucky enough to be in the middle of this problem, you only have one reasonable solution: find a way to draw fewer pixels per frame. A good suggestion here is to attempt a dirty rectangle solution, where you draw only those parts of the screen that actually change.

Figuring your maximum frame rate on 3D games is a much trickier business, since there are many variables to consider. I'll start by making the assumption that your game is using VRAM intelligently for texturing and you are not thrashing textures into and out of VRAM. I'll also make the assumption that your rendering engine has a nice tricky way of skipping all hidden polygons, minimizing pixel overdraw. The big variables then become your polygon fill rate and your vertex transform rate. The fill rate is a measure of how fast your rasterizer can fill a polygonal area with the proper pixel values using lighting and texturing sources. The transform rate is how fast the rendering engine can message 3D world data and camera position into a list of 2D screen polygons with appropriate lighting data. Finally, many renderers put a reasonable cost on switching rendering states, such as loading new textures.

The thing that makes estimating these two variables and how they will affect your frame rate difficult is that most games don't have a scene that can be considered a standard benchmark. Good game and art designers will recognize that different scenes need varying levels of geometry and texture density. So what do you do?

If you are using an off the shelf renderer like Renderware or Intrinsic Alchemy, you've got excellent reference material in the games that have already shipped with the most recent version. Every middleware company out there will constantly improve their technology, and you can also count on getting some one-on-one help to get you over a frame rate hump. If set your game technology to target the upper end of the resolution and scene density of the top end of current games on the market, you'll be in good position to hit that target. If you happen to have someone like John Carmack on your team, of course, you can go a lot farther than that! The bottom line is you must take your team strength into consideration when choosing how far you want to push your maximum resolution.

~ Sumber : Mike McShaffry, 2003, Game Coding Complete. ~