Volume #1 Issue 5 December 1987
In this essay I shall present my case for greater use of arithmetic methods in computer game design.
The conventional style in most computer games makes heavy use of Boolean methods. Many of the critical variables are Boolean flags, and many of the central calculations are Boolean in nature. You can sense the Boolean components of a game when events are triggered by some condition, or when game behaviors turn on or off in reaction to your actions. A good game designer can feel the IF-THEN statements crunching away in somebody else’s game.
There’s a perfectly good reason for the emphasis on Boolean operations in computer games: many computer game designers were trained as programmers, and programmers quickly learn a great deal about Boolean thinking. The more highly-trained the programmer, the more comfortable he is with Boolean operations.
Boolean operations do not mirror the world very well. They are a grand artifice, an intellectual crutch distantly removed from the operations of nature. They have only two saving graces: they work well on computers, and they are easy to understand.
Arithmetic methods rely on the four elementary arithmetic operations: addition, subtraction, multiplication, and division. The fundamental difference between arithmetic and boolean operations lies in the fact that Boolean operations are single-bit operations, while arithmetic operations are multi-bit operations. (I concede that most CPUs can perform the Boolean operations on all the bits in a word, but argue that in practice, most Boolean operations are performed on single-bit Boolean variables.)
Because the arithmetic operations typically involve more bits than the Boolean operations, they tend to be "crunchier". That is, arithmetic operations make greater use of the processing power of the computer. They make it easier for us to realize the potential of the computer. A computer programmer whose programming style is primarily Boolean is like a car driver who never shifts out of first gear.
At this point a comparitive illustration of Boolean and arithmetic styles might help. Consider the following situation:
We have three actors, A, B, and C. Actor A is about to perform some action towards Actor B. Actor C will observe. Now, the Actor A’s action may be either beneficial to Actor B or hurtful. Actor C may either like or dislike Actor B. We need to calculate the nature of Actor C’s reaction to Actor A’s action. Will it be approving or disapproving?
The Boolean solution to the problem is certainly simple:
C_Approves = C_Likes_B EOR A_Hurts_B
Here the symbol "EOR" refers to a Boolean exclusive-or operator.
The arithmetic solution appears to be simple, too:
C_Approval = C_Like_for_B x B_Benefit
Here the "x" represents multiplication.
Now let us compare these two calculations. The Boolean one is simpler to understand. It may take a moment to work out the significance of the logic table for the calculation, but it is still easy to understand.
The arithmetic calculation takes a little more time. There are more assumptions built into the equation, such as the notion that the value of C_Like_for_B will be positive if C likes B and negative if C dislikes B. Similarly, B_Benefit will be positive if A’s action helps B, and negative otherwise.
A simple way of comparing the two calculations is to tote up the number of separate cases each can generate. The Boolean computation yields exactly four cases, so it doesn’t take long to verify its operation. The arithmetic computation, though, yields 2**32 cases, if we assume 16-bit words. You cannot possibly walk through all these cases verifying their function. And this is one of the causes of our reluctance to use arithmetic methods. The Boolean methods are so easy to check out, so reliable. The arithmetic methods require us to use our intellects to imagine results without directly confirming them.
But this wide variability of the arithmetic methods is their strength. They allow us far greater range of algorithmic expressiveness. We can say and do more with arithmetic operations.
How does a designer make greater use of arithmetic operators in his programs? This is largely a matter of style and outlook. Reliance on arithmetic methods is not a matter of grabbing tools from a pile; it is part of a person’s worldview. Certainly the intellectual tools at hand are simple enough. Arithmetic is taught in grammar school, and the algebraic notions required are really just first-year high school algebra. Surely none of us have problems understanding the basic tools.
The difficulty, I think, lies in the generality of approach that is necessary for proper use of arithmetic methods. Consider the example I used earlier. It is a simple matter to express the relationships in Boolean terms ("If you hurt someone I like, I will disapprove.") But the more general arithmetic form defies clear verbal expression. ("I will approve or disapprove of your actions in proportion to the amount of help or hurt those actions create and the amount by which I like or dislike the object of your actions.") Arithmetic expressions are more abstruse than boolean expressions.
It is the abstruseness of the arithmetic expression that repels the incompetent and attracts the perfectionist. Yes, arithmetic methods are more difficult to use. They are more difficult because they are more powerful. Yes, we have to think harder to use them. Isn’t that our job?