This is an excerpt from Game Architecture & Design, an industry textbook I co-authored with Andrew Rollings. (I wrote the game design bits, Andrew dealt with code, tech and development practices.) The book was originally published in 1999 and a revised edition came out in 2004. In the intervening two decades, a lot has changed, but it's also interesting to see what hasn't...
If I throw a ball and take many high-speed photographs of its flight, I'll see that the trajectory the ball took is a parabola. But the ball didn't follow that path because gravity told it: "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. The balance between kinetic and potential energy over the time the ball is in the air gives you what we call a parabola.
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 modelling rather than step-by-step simulation, 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)
One big advantage of the way that reality does things is that the universe, being non-symbolic, cannot crash! Here is an example: Suppose I am putting a monster into my 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, I just choose the short cut of placing a trigger tile inside the 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 that 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!"
In the past, the nonsymbolic, step-by-step approach was not practical. The the processing capability wasn't available to deal with that and graphics too. But now much of the graphics work is done by the video card, and computers are doubling in power every eighteen 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 other's 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 by leaving 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 behaviours and the economic simulation emerged directly from those.
Contrast this with a game like Caesar II, 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 II (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.
And you know what? The same goes for stories. If you construct them from symbolic forms (arcs, paradigms, act breaks) you'll end up with less robust and varied stories than if you allow each micro-event to trigger the next and see where it goes. Which is why in roleplaying terms I'm a simulationist rather than a narrativist. Hey, if it's good enough for reality then it's good enough for me.
Principle of Least Action image by Maschen CC0,
No comments:
Post a Comment