Among the many modalities of human thought, two are particularly common: verbal reasoning and spatial reasoning.
Verbal reasoning is the process of forming ideas by assembling symbols into meaningful sequences. Human language is the most common medium for verbal reasoning. But verbal reasoning can be used in other mental activities. Algebra is a medium of verbal reasoning. So is programming.
Spatial reasoning is a process of forming ideas through the spatial relationships between objects. Geometry is an example of spatial reasoning at work. Graphs present data in a format suitable for spatial reasoning.
We often use both forms of reasoning. If you want to come to my house, I can give you verbal directions over the phone or fax you a map. Indeed, it is often advisable, when struggling with a difficult problem, to attempt to express it in both forms: "If you can’t say it, you don’t know it." "When in doubt, draw a picture."
But there are also situations that differentiate the two forms of reasoning. Some problems are intrinsically better suited for handling in spatial form than verbal form; others are better suited for verbal reasoning. Try to describe how the parts of an internal combustion engine operate without recourse to spatial reasoning. Or try to explain a syllogism using purely spatial logic. You don’t get far in either case, do you?
There are other differences to consider. Some people are stronger at one form of reasoning. We know that, in this culture, there are sex-based differences. Men are, on average, better at spatial reasoning than women, and women seem to be correspondingly better at verbal reasoning. Presumably these differences will diminish as our culture adjusts its upbringing of children, but the phenomenon is well-documented for the moment.
This has profound implications for computer game design. Think for a moment about how utterly spatial our games are. Almost everything we do is spatial!
Take strategy wargames as an example. Now, strategic warfare is a complex activity involving all sorts of variables, but computer wargames focus exclusively on the spatial factors -- the maneuvering of units. It’s as if the verbal factors (command and control, morale, logistics, etc.) have been sanitized right out of the design.
How many of our games use maps in one form or another? How many show us some sort of positional display? And in how many games is the primary activity of the player the judicious movement of his pieces? To put it another way, how many games can you name that do NOT use a map or spatial movements of pieces? Can you see how completely spatial reasoning dominates our designs?
The most ironic example of this is the text adventure. Here is a patently verbal medium whose inputs and outputs are both verbal. One would think that a verbal medium would encourage the use of verbal reasoning. But look at the structure of the text adventure. What’s the first thing a seasoned text adventurer does? Why, he pulls out a piece of paper and starts drawing a map! Because the central problem of the text adventure is -- you guessed it -- moving around in an imaginary spatial environment. When presented with a verbal input device (the keyboard) and a verbal output device (character-based screen), we still manage to come up with a spatial-reasoning game. Is this craziness, or what?
User Interface Design
This illustrates an important point: it’s a good idea to match the user interface to the game architecture. A spatial reasoning game works better with spatial input and output structures. A verbal reasoning game works better with verbal input and output structures. Some examples of how to do this wrong will illustrate the point:
I had a conversation recently with a fellow who was working on a design problem involving user inputs. The game in question was heavily spatial in orientation (no surprise here). The player inputs were all geared toward moving pieces around on a map. Now, the designer was required to support both keyboard input and mouse input. I can understand the economic factors that led to this requirement; what I couldn’t understand was the designer’s attitude towards the two input devices. He was perfectly happy with the keyboard (verbal) input; it was the mouse (spatial) input that was giving him problems.
He had come up with this clumsy, complex, indirect scheme involving keycodes and tokens and all manner of other arcane verbal commands for handling spatial commands -- and he was quite proud of his system. I have to admit, it was a clever scheme. But what really astounded me was his negative attitude towards the mouse input. It should have been child’s play to devise a clean, intuitively obvious system for moving units with the mouse. Click on the unit you want, drag to the location you want him to go to, and release the mouse. What could be simpler? But this fellow insisted on a scheme that used the mouse to give mousey analogues of the keyboard commands. I am reminded of the fellow who, given a screwdriver, attempted to pry a screw out using the screwdriver like a chisel, and after much futile labor complained that the screwdriver was a poor tool indeed.
What we’re up against here are some common prejudices that we learn as programmers. We speak to the computer through the keyboard, so we are all fast touch typists. We tend to view the keyboard as the primary input device. This problem is especially pronounced with programmers steeped in the folklore of the MS-DOS environment. Despite years of experience that prove the utility of mouse-based input, despite the steady evolution of all systems towards the GUI user interface paradigm, there are still die-hards in our business who insist that the keyboard is the king of all input devices and that the mouse is fundamentally inferior. The keyboard is faster, they insist; the mouse is clumsy.
They are partially right. The keyboard is without question the fastest and cleanest way to input verbal information. But the other side of the coin is that the mouse is the fastest and cleanest way to input spatial information.
At this point, some people will protest that they find cursor keys faster than the mouse for designating spatial locations in, say, a text file. I suspect that these people have lots of experience with the keyboard and little with the mouse. Yes, it takes a little time to become proficient with a mouse. But it takes a lot longer to become proficient with a keyboard. And my own experience as a heavy user of both mouse and keyboard is that the mouse is the fastest way to move around in a word processor.
But I digress from the matter of spatial and verbal reasoning. The important point here is that a good designer will match the input device to the nature of the information being entered. And to demonstrate that this principle cuts both ways, I’ll now present another example.
Another fellow I know recently asked how to use a joypad to enter verbal data. He was adapting a text-oriented game on a PC for a console machine, and needed a scheme that would work with a joypad. Now, I can understand that this programmer’s problem was to make it work, not to ask whether it was right to try to make it work. Still, I have to wonder, wasn’t anybody at the controls here? Wasn’t there anybody in this project with enough sense to notice that a joypad makes a lousy keyboard? Sure, it’s possible to come up with some scheme that allows the user to peck away at a joypad and select letters of the alphabet. But wouldn’t any such scheme be so clumsy as to interfere with the enjoyment of the game?
An ounce of solid understanding of theory is worth a pound of technological cleverness. Knowing which problems to tackle (and which to avoid) is better than being able to devise the best possible (but still inadequate) solution to the wrong problem.
One last point: how many games can you name that rely primarily on verbal reasoning? Combine your answer with the observation that women are better at verbal than spatial reasoning, and what conclusion can you draw?
I am indebted to Dr. Brenda Laurel for first raising the issue of verbal and spatial reasoning in user interface design.