Following the Procedures

Recently, a much-awaited digital game FINALLY hit the market. Spore, by Will Wright, for those who aren't aware of it, is another in the long line of his sandboxes. While these types of games have game-y elements, there is no main goal or story to complete. Granted, Spore does have this in a small amount: the object is starting with a single cell organism, eventually evolve and go off and conquer planets. However, it's really more about mucking about, and seeing what happens.

What makes Spore unique is the way that the data is handled. Instead of having massive teams of artists developing massive amounts of content for the various races, creatures, globs of primordial ooze, etc, all of this is handled procedurally. Basically, creatures aren't defined by what the artists make them look like, but instead, by simple software definitions of said creature, and the program just "figures it out." This allows for immense flexibility, as you just apply a few random numbers to a creature template, and TA DA, you have a living, breathing creature that knows how it's supposed to walk, fight, and otherwise generally behave.

What does this accomplish? Well, for one, size. The game doesn't need to have a bunch of pre-programmed walk motions, designed specifically for a pre-drawn animation cycle, designed by an artist. It just needs to know that the creature has three-legs of X size. Since artwork and texture are generated on the fly from this thinking, there's no need to have to import 100 Megs of texture images. It's just created as needed.

Additionally, this allows the users to make infinite combinations of creatures, without having to deal with creating their own textures and monster-shaped polygonal meshes. And once on the internet, suddenly there's millions of creatures, all defined by users, polluting the in-game universe, with very little "real artists" getting their hands in the mix.

One of the more imaginative side effects of this is the way creature data can be moved from one player to another. Since creatures are defined by various database attributes (as opposed by pre-created artwork), the file size of any creature is REALLY TINY. Sharing a creature is as simple as "taking an in-game picture" with the camera tool, and forwarding that image to your friend. What the game does is store all of the creature attribute data in the alpha channel of the picture; what is amazing about this is that all of the data that it takes to accurately replicate a creature is actually smaller, file-size, than the JPG IMAGE OF THE CREATURE ITSELF!

In fact, it is so easy to move creatures around is that if you want a creature from the Spore website, you simply drag the image from the website into your Spore program. Quite amazing stuff. (I've been amazed at this kind of stuff before, feel free to click this link.)

Anyway, what can we learn from this, in a table-top world. Obviously, when you are talking about player-creation, a few notables come to mind, such as Dungeons and Dragons, or really any game out of the RPG genre. But there's an interesting table-turning factor here; while Spore is a world where users create all of the elements in the world. D&D seems to be, aside from some character creation aspects, where the players create the world, and populate it with pre-designed denizens from a Monster Manual. I'm not saying that all D&D groups do this; I'm sure there are many out there that truly build a complete world on-the-fly; but most of the money made on RPG is based on creating a system, and then having the players buy countless expansions of new content, as opposed to creating their own.

So, where am I going with this?

One of the secrets of a successful print-and-play game (successful being a term that is rather fungible in this genre) is having a tiny component list; the less components that are required to print out and cut and paste and prepare, the better. No one wants to spend 3 hours building a game that isn't potentially fun; but maybe if it took the player 15 minutes, it's worth the risk of the time.

However, typically, a simple component list also waters down the game a lot, down to a simple game (unless it's some wacky abstract, where the depth of play comes from a more analytical nature). So, the question arises, how do you make an interesting, long-playing game with as little components as possible?

A completely viable solution to decreasing the component list is reducing as much data as you can to being procedural, as described above. In other words, the game should not necessarily come with all of the data pieces, but instead should just have the required rules to build the data units as you need them.

Aside from compactness, this also creates a game where each game is unique. You don't need expansion cards later to "refresh" the game, as the game constantly refreshes itself through the building of the data as you progress....

Soon to come, part 2, an example game....