Spore – It’s not that scary!

I just finished reading an article over at Bona Fide Reviews and I simply can’t keep but smiling. You should read the actual article for yourself and then consider my reply. Enjoy:

OK, let’s start one by one. First of all we should clarify if we’re talking directly about programming or rather some greater logic that is the basic for the whole program. In this case this is almost certainly the logic behind the programming, not the actual language itself. In fact, it’s not even the logic behind the whole program: It’s the logic behind one subsystem, namely the model generation.

The point is that Spore simply adds a whole new level of abstraction for generating and maintaining models. Notice that the system itself is nothing new… it has been around since the first days of game programming. But maybe it’s easier to explain it using a well known example.

Consider the model generation in Half Life
You see a guy lifting his arm… what data is actually stored and which one is generated on-the-fly by Half Life, DirectX or your graphics card?

What you see is a two dimensional raster image, so does Half Life come with a image of that guy from every imaginable angle?
No, it doesn’t. This would either require a huge amount of memory or limit the number of angles. However, this was done by older games like Doom to save processing power… as a result no matter from which angle you would look at a monster, it was always one of four images (Left,Right,Front,Back).

So, we’ve established that the guy isn’t stored as a 2D raster image, so what is he made of? What data is processed into the image we see? Well, it is a vector image… an image where points and the areas between them, together with a number of parameters like the color of a area make up a description that can be used to generate a bitmap. But this doesn’t really solve our problem, there are still way too many angles.

We really have to abstract some more. What data can be used that when combined with a particular angle results in a 2D vector image? You’ve got it: a 3D vector image! We just spread the points along an additional third axes and suddenly we can generate a 2D vector image from every imaginable point. Hurray!

But wait, the guy is lifting his arm! Uh… do we have to store a 3D vector image for every single point in time while he’s lifting his arm? Well… this was done by the game on which Half Life is based (Quake) and it wasn’t a very good system… In order to keep the size of all these models down, they had to remove precission resulting in a very strange effect where parts of the model would appear to change shape. Luckily, there’s an alternative! We can use yet another form of abstraction! We simply divide the data up again, in this case in the static 3D vector image and a skeleton that defines which parts of the 3D vector image belong to which bone. So now we just have to store the 3D model of the skeleton and in order to for example lift his arm, we simply move the arm bone, and all points in the 3D vector image that belong to the arm bone will move the same way.

But this isn’t enough! There may be hundreds of guy in the game and most of them lift their arm in a similar way. Since we separated the skeletal animation data from the 3D vector image, we can use it for all guys, not just this one!

But we still have to define all individual states, so let’s abstract some more! We can simply define a number of points along which the bone should move, and voila, we only have to save two or three states and interpolate between them.

———–

This is where it ends for Half Life. But wait! There’s more!

Unreal was one of the first games to dynamically generate images to be used as textures for the areas in a 3D vector image: They would for example specify a image and then generate a whole series of images where water was flowing across it.

Quake3 brought parametric skeletal animation to the masses. There would only be one animation for walking which was modified to make it appear as if different characters walked differently. Some would spread their legs more, others less and so on.

Others, like the famous N64 game Waveracer, would generate models for a whole see using a set of rules that formed a simplistic physics model.

And finally we see games like World of Warcraft creating a near infinite number of models by combining parts of different models.

———–

But there’s one gap. We always end up with a static model that’s being deformed in various ways. And this is where Sporn offers (or appears to offer) something new. We can create arbitary models from a simple model (in this case a ball). In fact it’s not new at all. We’re simply adding better deforming algorithms and give them more freedom in that we not only allow them to not only move existing points, but also add new ones. We add routines that we’ve developed to simulate physics to make it appear a if we were actually sculpting. Then we apply all the techniques mentioned before.

It’s a great example of evolution, but it’s not a revolution.