Category: Random

Posted: 11/23/07 Part 3 in a series of articles describing a system for procedurally generating a game.

As you break down this entire game database into small, individual logical pieces, eventually you've got to stop somewhere. Obviously, it would be absurd to break an algorithm down such that each statement were a card, but you don't want to be so obtuse that introducing new data into the game (like a new tileset) requires adding code to the card engine.

Enter "Data Cards". These are special cards which are NOT Game Object factories. They are not a template or produce unique content each time they are instantiated. Instead, they represent a piece of data (or code) which the engine uses directly. For example, an entire tile set could be represented by a single card. An algorithm, likewise. It isn't a procedure that takes parameters, but a static variable that always points to one piece of information.

These cards are not intended to be used for general purpose design. In a minute, I'm going to talk about control cards which allow you some ability to randomize or otherwise affect a card tree. Data cards are not exactly interchangeable. That is, a castle tile set may not work with a cave generation algorithm. A lizard man sprite set may only have animations for using a spear and none for using a dagger, so using it in a card that could potentially use daggers would likely crash the system.

Rather than creating possibilities, data cards instead create limitations. It says what it possible with each basic element of design. Perhaps only the system designer would work with these cards directly, but they would be visible within the composite cards themselves so that people creating new cards based on old ones know what's going on.

A pool is a set of cards that fits into a single slot. Each time that slot is activated by the algorithm, one of the cards from the pool is selected instead. There are two main ways this happens. The first is that the pool could represent a single card. Thus the pool is activated only once and returns a single card from the possible selection.

The second way is that it can be activated multiple times, returning a different card each time. That sort of pool could even be draining, such that a selection is removed from the future selections until each possible card is used up. Draining and template entries are simply a matter of a binary switch. If it is draining, the card is removed on activate. Otherwise, it is retained. That way, you can have some cards which drain and some which don't. Perhaps a max amount, like 3 of these cards and an infinite number of these other cards.

For example, we can add some control to our random selection. For instance, say you are randomly generating a castle. You can create a pool of potential enemy types (orc warrior, orc shaman, orc elder, orc guy with pointy stick, etc), and the algorithm will request an enemy type from that pool. You could make sure there are only two orc elders possible in a zone and as many warriors and shamans as the algorithm feels the need to add.

And, of course, pools can be nested.

In order to facilitate genre deck construction, there will be certain types of default pools. For example, the enemy pool from the previous example could be made into a global, default pool. Doing this could create a sort of standardization for enemy or item selection, helping create a more coherent design.