Designing from the bottom up

More tips on game design today culled from my and Andrew Rollings's book Game Architecture and Design. (Sure, it was published a whole fifteen years ago and game development has moved on - but hey, some people still get advice from the Bible and the Koran.)

If you throw a ball and take many high-speed photographs of its flight, you'll see that the trajectory the ball took is a parabola. But the ball didn't follow that path because gravity told it to move in a parabola. A parabola is just a symbolic concept in the analytical domain of mathematics, and the universe doesn't know anything about mathematics or analysis or symbols. These are human concepts. In reality, there are just a bunch of physical processes, each of which deals only with the processes and circumstances just before and just after it. So, the ball is at one position, and gravity tells the ball's velocity to change, and the ball's velocity tells its position to change.

This is the opposite approach to that taken in most software applications. There, processing power is at a premium, so the sooner you can go to symbolic constructs, the better. The tradeoff is that software can crash when your symbolic "shortcut" misses something that the one-step-at-a-time approach would have taken in its stride.

Researchers in artificial life have identified an analogous problem:

"The classical AI approach has been criticized because the symbols and symbol structures on which planning and decision making are based are not grounded in the real world. The problem is that unequivocally decoding sensory data into a symbol and turning a command without error into its intended action may be unsolvable."
—Luc Steels, "The Artificial Life Roots of Artificial Intelligence" in Artificial Life (MIT Press, 1997)

Here is an example: suppose you are putting a monster into your new Frankenstein adventure game, and the idea is that it will jump out of its vat when the player enters the laboratory. Instead of putting in a lot of complicated AI to do with detecting humans and having the goal of wanting to kill them, you just choose the shortcut of placing a trigger tile inside laboratory door. When the player steps on the trigger, the monster will appear and attack.

Okay so far, but what if the player manages to get onto the tower roof, jumps down, and, by some fluke, manages to land safely on the balcony of the laboratory? Now he can explore the lab, get all the power-ups, and read the journal about the monster (an entry that is supposed to be poignant if he's just fought and killed it, but is meaningless otherwise). Only when the player goes to leave via the door does the monster climb out of its vat and growl, "You shall not steal my master's secrets!"

When cutscenes were pre-rendered, ones of the purposes of tying events to a trigger point like that is that you could be sure of where the player’s character would be standing (and the state of the laboratory, in this example) when the cutscene began. Nowadays, it is more likely that the cutscene will be generated in the game engine. The cutscene thus becomes an example of “machinema” which can be slightly different every time, depending on the game state at the time it is triggered.

The use of the trigger point illustrates symbolic design. The designer assumes there is only one way for players to enter, and that’s via the door. The alternative nonsymbolic, or equation-free, approach would recognize that the true trigger event is the monster’s awareness of intruders in the laboratory. Whatever way the player enters the lab — even if by teleportation — the game still responds appropriately.

Discussing Deux Ex at the GDCE conference in London in 2002, designer Harvey Smith of Ion Storm cited how nonsymbolic design is changing games. In testing a maze level (the walls of which were set high enough that the player couldn’t jump them) the developers discovered an ingenious way to escape the maze. A player could fix a limpet mine to the wall and use this as a stepping stone to jump out of the maze. Harvey Smith pointed out that old-style designers might have regarded this as a bug, but in fact it was an extra opportunity that enriched the gameplay.

“We need to reward the goal,” he concluded, “and not the method the player uses to achieve the goal.”

In the past, the nonsymbolic, step-by-step approach was not practical. The processing capability wasn't available to deal with that and graphics too. Hence design used a symbolic approach and the idea of one correct solution to every problem became ingrained. But now much of the graphics work is done by the video card, and computers are doubling in power every 18 months or so. At last, it is starting to be possible to create "uncrashable" games by avoiding the need to design using symbolic shortcuts.

Comparing Nonsymbolic And Symbolic Design

In the original Warcraft, peasants collected gold by entering a gold mine and bringing sacks back to your town hall. At the start of the game it was always worth spawning peasants because the more peasants you had, the greater your revenue stream. However, there came a point when the peasants started to get in each others' way. Adding more peasants would then lead to traffic jams as the peasants encountered each other on the streets of the town and would have to back up to let others get past. The situation was alleviated if you planned your town with wide streets. Additionally, it was not a good idea to place your town hall too close to the gold mine — giving a little more space also helped avoid traffic congestion.

Now, an economist could derive an equation to describe the flow of gold to the town hall. The factors would be the number of peasants, the placement density of the town buildings and the distance from the town hall to the mine. We can imagine that it would be a pretty complex equation. The point is that the designers of Warcraft never needed any such equation. They simply programmed in the basic rules and behaviors and the economic simulation emerged directly from those.

Contrast this with a game like Caesar 2, which used underlying equations to create a simulation of an ancient Roman city. This approach is less satisfying because the player is not directly viewing the reasons for success and failure. Instead, when playing a game like Caesar 2 (or any simulation of its type) you are trying to build an abstract match to the game's underlying equations in your head. The simulated economy and the gameplay are less visible, lessening the sense of immersion.