What s Missing?

What's Missing?

The scene graph in this chapter is a fun toy. It's not nearly ready to install into a real game engine. You'll want tons of new nodes, articulated figures, and other visible objects. There are also a few other things you'll need to add to this system. The first and foremost is a better way of creating and editing your world. I'm pretty sure I mentioned somewhere in this book that any good game engine is a data driven creature, and then I show you a completely hard coded scene graph! No, I'm not a slacker—I opted for the cheap and easy route because it's also easy to understand. If I were to continue playing with this simple design, the first thing I'd add is an XML-based scene definition language.

The XML scene definition would only be used for development, of course, since the current XML implementation doesn't have a binary standard definition. By the time this book is in your hands, that will probably be fixed, which will boost XML from its current popularity into a staggeringly powerful data file standard. Then you could use it for a game.

In any case, your game needs a way to load and save this data. Each of the SceneNode descendants need a stream constructor to hook into a save game system. I'm going to make a broad assumption that whatever game in your head is going to have at least a few dynamic objects. After all, there aren't too many games based on a vacant art museum. Even if your game were a vacant art museum, the paintings, walls, and lights still need to load somehow.

Probably the most serious missing component to the scene graph is a collision system. No 3D game is complete without one, and believe me they are extremely complicated. To get an idea how complicated, go check out the latest work at the University of North Carolina, Chapel Hill's site devoted to the study of this problem: www.cs.unc.edu/~geom/collide/index.shtml. I've used ICOLLIDE in the past but I'm very interested to try VCOLLIDE and SWIFT++. When you look for a collision system, make sure that one of the features includes temporal coherence, which is a fancy way of saying that the system remembers the positions of geometry from frame to frame. Games typically have tons of static geometry, and a much smaller number of dynamic objects. If the collision system takes advantage of this fact, your game will run a lot faster.

The most trivial collision systems use axis aligned bounding boxes (AABB), and nothing more. These provide the most basic collision detection, and you've probably seen them installed in the nastier of the coin-op video games that have very fast moving objects that bounce around for a moment before they disappear. That's because they won't look right when the bouncing objects always seem to land right side up. Believe me if that worked in real life I'd be at the craps tables in Las Vegas.

More complicated systems seek to break objects down into their convex components, and perform collision detection on each of these components. These are probably the most common solution in games, because they provide a very realistic simulation. The only problem is creating and maintaining the collision geometry separate from the visible geometry. There are tons of tools to do this—rather I'm talking about the logistical problem of keeping all this extra data straight. Automatic tools are the key here. Don't assume that artists working in 3D Studio Max will always remember to create the collision geometry, save it to the right file, and keep everything organized.

Some of the most advanced work cares nothing for the geometry: convex or concave is just as good as anything else. These systems work on polygon soups and have the ability to determine which polygons are intersecting with each other, sometimes what forces are involved, and what your simulation should do to resolve the movement of the objects. Lucky for you there are some very smart people, and smart companies, working on this problem so you can spend more time on the important bits, like making a fun game.