(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Monday, July 19, 2004
Chris Crawford on Game Development
Chris Crawford is a game developer. He created many of my favourite Macintosh games, including Balance of Power, a sophisticated game of geopolitics. He later wrote a book about Balance of Power, explaining the game's creation and mechanics.
I re-read his book over the weekend, and was struck by Chris' insights into software design. First person shooter games are all about rendering and trajectories. But Chris' games perform the difficult feat of modelling "soft" subjects like geopolitics, trust, or economics.
His perspectives struck me even more relevant today than they were in 1986 when he wrote the book (not to mention 1984 when he began work on the game). Today we are obsessed with "styling," animated menus and translucent interface elements. But where is the "Knowledge Navigator"? How much progress have we made getting computers to help us with our lives or jobs?
Of course, computers are pervasive. That's a measure of economic success. But to be honest, I'd say that computers in the office spend most of the time solving problems that other computers have created. I recently made a presentation with animations. But is there any content in that presentation that wouldn't have been just as effective if I'd written things out with Word 2.0 for DOS, my editor in my University days?
So back to Chris. His perspectives on turning soft concepts into games apply directly to developing software for helping people solve problems. The problems we want to solve are incredibly soft.
Take software development itself. Do you really believe it's an empirical science? That we just assemble the estimates, draw some pretty diagrams, follow the ISO something-or-other standard, and software emerges from the process? Software development is a soft science. And I hope that some of Chris' principles for developing games around soft concepts will apply directly to developing software to assist software development.
I captured some of Chris' words from the book. I hope he doesn't mind my sharing them with you here:
Simplification to achieve clarity is the essence of my work; clarity can be extracted from a muddy reality only by denying some of reality's richness.
A game is to a simulation as a painting is to a blueprint. A painting of a house gives you an emotional impression of the house; a blueprint of a house tells a carpenter where to put the windowsill.
What is important is the principle, not the instance, and principles are processes. The actual amount of the GNP of Ghana is less important, for the purposes of a game on geopolitics, than the manner in which that GNP changes over time... This concept—which I call *process intensity*—is the organizing principle of [my book]... I give the facts themselves short shrift. Facts are transitory, while processes are the enduring truths.
You can't interact with a fact. It's like a dead fish—it just lays there. But you can interact with a process. You can shape it, change the parameters that affect its behaviour. Ultimately, you can learn about it. facts are best relegated to books and other static media, and computers are best applied to problems involving processes, for computers are not *data* processors, but data *processors*.
I did not start out with a fixed set of notions and then express those notions directly through the computer. Instead, the attempt to express my thoughts on the problems of geopolitics helped refine and correct them.
Verbs are all-important in game design. They are the allowed actions, the permissible commands that are available to the player. A good set of verbs allowes players to do everything they would need or want to do. A poor set of verbs will either confuse them with its arbitrainess, or lock them in a frustrating straightjacket. The game designer spends a great deal of design effort worrying about the verbs to provide in the game.
A programming tool is like a freeway: It takes you somewhere in the universe of results. All programming tools are to some extent generalized to handle the needs of a large number of programmers. They are like freeways that take you to the most popular beaches or the most crowded resorts. He who would climb the remote peaks must forsake the freeway and make his way by foot. The exertion of a week's simple sweat can place the programmer on a mountain peak from which are visible new territories of creative opportunity invisible to those who veer away from steep grades.
And my favourite quote:
Using paratroops is like putting yourself into a deep hole to see if you can dig yourself out of it. I did much the same thing with Balance of Power, setting a goal for myself that I had no reason to believe I could attain. Then I publicly and financially committed myself to attaining that goal... It was a tough, frightening experience. When it was over I was physically and spiritually spent. But what is the point of undertaking anything less than the most demanding of efforts?
Chris Crawford is a game developer. He created many of my favourite Macintosh games, including Balance of Power, a sophisticated game of geopolitics. He later wrote a book about Balance of Power, explaining the game's creation and mechanics.
I re-read his book over the weekend, and was struck by Chris' insights into software design. First person shooter games are all about rendering and trajectories. But Chris' games perform the difficult feat of modelling "soft" subjects like geopolitics, trust, or economics.
His perspectives struck me even more relevant today than they were in 1986 when he wrote the book (not to mention 1984 when he began work on the game). Today we are obsessed with "styling," animated menus and translucent interface elements. But where is the "Knowledge Navigator"? How much progress have we made getting computers to help us with our lives or jobs?
Of course, computers are pervasive. That's a measure of economic success. But to be honest, I'd say that computers in the office spend most of the time solving problems that other computers have created. I recently made a presentation with animations. But is there any content in that presentation that wouldn't have been just as effective if I'd written things out with Word 2.0 for DOS, my editor in my University days?
So back to Chris. His perspectives on turning soft concepts into games apply directly to developing software for helping people solve problems. The problems we want to solve are incredibly soft.
Take software development itself. Do you really believe it's an empirical science? That we just assemble the estimates, draw some pretty diagrams, follow the ISO something-or-other standard, and software emerges from the process? Software development is a soft science. And I hope that some of Chris' principles for developing games around soft concepts will apply directly to developing software to assist software development.
I captured some of Chris' words from the book. I hope he doesn't mind my sharing them with you here:
Simplification to achieve clarity is the essence of my work; clarity can be extracted from a muddy reality only by denying some of reality's richness.
A game is to a simulation as a painting is to a blueprint. A painting of a house gives you an emotional impression of the house; a blueprint of a house tells a carpenter where to put the windowsill.
What is important is the principle, not the instance, and principles are processes. The actual amount of the GNP of Ghana is less important, for the purposes of a game on geopolitics, than the manner in which that GNP changes over time... This concept—which I call *process intensity*—is the organizing principle of [my book]... I give the facts themselves short shrift. Facts are transitory, while processes are the enduring truths.
You can't interact with a fact. It's like a dead fish—it just lays there. But you can interact with a process. You can shape it, change the parameters that affect its behaviour. Ultimately, you can learn about it. facts are best relegated to books and other static media, and computers are best applied to problems involving processes, for computers are not *data* processors, but data *processors*.
I did not start out with a fixed set of notions and then express those notions directly through the computer. Instead, the attempt to express my thoughts on the problems of geopolitics helped refine and correct them.
Verbs are all-important in game design. They are the allowed actions, the permissible commands that are available to the player. A good set of verbs allowes players to do everything they would need or want to do. A poor set of verbs will either confuse them with its arbitrainess, or lock them in a frustrating straightjacket. The game designer spends a great deal of design effort worrying about the verbs to provide in the game.
A programming tool is like a freeway: It takes you somewhere in the universe of results. All programming tools are to some extent generalized to handle the needs of a large number of programmers. They are like freeways that take you to the most popular beaches or the most crowded resorts. He who would climb the remote peaks must forsake the freeway and make his way by foot. The exertion of a week's simple sweat can place the programmer on a mountain peak from which are visible new territories of creative opportunity invisible to those who veer away from steep grades.
And my favourite quote:
Using paratroops is like putting yourself into a deep hole to see if you can dig yourself out of it. I did much the same thing with Balance of Power, setting a goal for myself that I had no reason to believe I could attain. Then I publicly and financially committed myself to attaining that goal... It was a tough, frightening experience. When it was over I was physically and spiritually spent. But what is the point of undertaking anything less than the most demanding of efforts?
Labels: passion
