Designer's Notebook: Cartographic Cartwheels

Regular readers of this column may remember that a few months ago I complained about games that don't provide the player with a map. Blundering around in confusion may lengthen the gameplay, but it's not what you'd call "quality time." There's a difference between the frustration you feel when you're trying to solve a puzzle and the frustration you feel when you're lost. The first is acceptable in a computer game, but the second is just tiresome.

This prompted one of my correspondents to point out that even with the best of intentions it can be difficult to provide a map of a three-dimensional space, especially a space in which there's no conventional definition of "up" and "down." The game Descent, of course, was one of the best illustrations of this problem. When you asked for a map, Descent put up a wireframe of the space you were moving through, but it was often difficult to understand and only added to the confusion. This got me thinking about cartography - mapmaking - as an art form. A well-drawn map is a little masterpiece of functional beauty, immediately and unambiguously conveying the information that is needed. On the whole, we don't know very much about cartography in the computer game business, and there are some useful things we could learn.

(I should add a disclaimer here: I'm no kind of an artist, although I have done decent scientific drawings in my time. Fortunately, accurate technical drawing requires more technique than it does talent, so it's a skill you can learn. This column is about some of the things that have helped me along the way. Serious professional artists probably won't learn anything new here.)

For one thing, not all maps have the same purpose. The map used by a subway system's passengers is quite different from the one used by its maintenance personnel. The maintenance staff requires a great deal of information that the passengers don't need - and which would only confuse them if they got it. When designing a map, first think about what the viewer is trying to do, and what information she actually requires. Don't just dump out data because you have it available.

Secondly, not all maps need to accurately represent reality, either in scale or in the physical relationships of objects. Road maps try to be reasonably precise about these things, and topographic maps even more so, but there are many cases where a map is easier to read if it expresses symbolic relationships rather than physical ones. One of the best of these is the famous London Underground map. Years ago, the map of London's subway system was a set of snaky lines superimposed over a London street map. (You can see it at http://www.dlux.net/~aga/gallery/london-jpgs/aftlu183.jpg) As the system grew, however, the maps became ever larger and more unwieldy. Sometime in the 1930's, London Transport's design department realized that people didn't need a street map while they were underground. The questions they really needed answered were "What lines do I take to the place I am going?" and "Where do I change trains?" The designers removed the aboveground features and straightened out the lines, depicting the subway routes using only horizontals, verticals, and diagonals. They also removed all scale: whether the distance between two adjacent stops was a few hundred yards or over a mile, they were shown as equally distant on the map. You're not going to get out and walk, so what difference does it make? The result bears almost no relation to the physical reality of the subway system, but it is one of the cleanest and most readable maps in the world. (See http://www.dlux.net/~aga/gallery/london-jpgs/aftlu184.jpg for an example from the 1950's.)

When designing your maps, use plenty of lateral thinking. When playing a game, most people need to know "Where am I with respect to important landmarks?" and "Which direction am I facing?", especially in point-of-view games. If you can provide this information, you don't need to give much else. The maps in Interstate '76, for example, looked literally like pencil scribblings on the back of a paper sack, but they were enough to get you oriented and explain the mission. Or think about the maps made by text adventure gamers. These were usually boxes with names of rooms inside them, plus lines from room to room, indicating which direction you go from one room to reach another. (This is called a directed graph by mathematicians.) The size of the boxes and the lengths of the lines were completely irrelevant, as long as the relationships were accurately conveyed.

The other resource I want to mention is a remarkable series of books on graphic design by a Yale professor of political science and statistics named Edward Tufte. To professional graphic artists these will need no introduction, but to a novice like me, they were a real eye-opener. The first has the rather unprepossessing name of The Visual Display of Quantitative Information, and is chiefly about displaying numeric values in tables and graphs. Don't let that put you off; even the most frenetic shooter still frequently needs to display numbers from time to time: hit points, armor strength, ammunition remaining, and so on. This book will show you how to do it clearly and cleanly. The second book, Envisioning Information, describes techniques for rendering "nouns" -- factual, though not necessarily numeric, information about things. The third book, Visual Explanations, is about "verbs," that is, visually describing processes. One of its more intriguing sections is an entire chapter devoted to books and pamphlets by professional magicians, describing how tricks are done.

The single most useful idea I got from Tufte's works is the concept of data-ink versus non-data-ink. Data-ink is ink which conveys non-redundant data itself, and cannot be removed without losing data from the graphic. Non-data-ink is ink which serves other functions (gridlines, redundant data, decorations, etc.), or occasionally no function at all. One of Tufte's fundamental principles is: maximize the ratio of data-ink to non-data-ink, within reason.

Several years ago I presented the results of a survey to the Computer Game Developers' Conference, which included a table of benefits available at a number of development and publishing companies. I wish I had read Edward Tufte's books before I printed it up. It looked like this, only much larger (all data now long out of date):

This is a good example of something Tufte calls a data prison, each datum confined to its little cell. There's an awful lot of non-data-ink here. Redrawing the table using Tufte's principles results in something a lot more readable:

There's really no point in putting both "Y" and "N" in the table, and no need for all those gridlines. For long lists, a horizontal line every fifth item or so, or alternate bands of light and dark background shading, are all that's required to keep the eye on track.

For another example, compare the differences between Windows 3.1 and Windows 95. In early versions of Windows, Microsoft copied a lot of the Apple's GUI features, which were originally designed to work on the Macintosh's monochrome screen. But when Windows 95 came along, it was immediately obvious that someone at Microsoft had read Edward Tufte's work. The "current-window" highlight went from being a filled space several pixels wide, with a black border, to a single bright line only one pixel wide. The scroll bars were no longer outlined in black; instead, they became a solid light grey with no outlining at all. Less important buttons got smaller.

You can see this in other Microsoft products as well. Compare Encarta '98 with Encarta '95. The menus make much more use of color than before, and the amount of contrast signifies the importance of the information. Low-importance information is often in brown on white or even brown on black. High-importance information, like the actual text of the encyclopedia, is still in high-contrast black on white. Tufte's books are beautifully designed (naturally!), easy to read, and occasionally rather blunt, including plenty of bad examples. One of the funniest - and also most frightening - is a completely unreadable manual of emergency aircraft procedures. Another is the old Surgeon General's warning on a pack of cigarettes. That solid block of narrow-lined, poorly-spaced upper-case letters surrounded by a box creates a moiré-like visual mess that actively discourages the eye.

How much more readable it would be if it were typeset like this:

Obviously, this is of varying relevance depending on the type of game you're designing, but Edward Tufte points out that computer applications need even more care in graphic design than printed materials, because the resolution of computer monitors is so low. The cheapest ink-jet printer can manage 300 dpi nowadays, while computer monitors are still stuck down around 72-90 dpi. And even though a screen full of numbers doesn't sound much like a game, you might be surprised at how many games have them. Most RPG's have a page full of character attributes somewhere; sports games have player stats and ratings; racing games include a variety of things you can tune about the car, and so on. A business simulation like Theme Park can display large amounts of numeric data.

Tufte's books are large-format hardbacks, and they're not cheap, but they're well worth it. You can probably find them in any college bookstore or art supply house.

Looking back on Descent, I think it made two major cartographic mistakes. First, when you popped up the map, it always appeared with you oriented the right way up, and the world oriented with respect to you. Since the orientation of the world changed every time you opened the map, the rooms were very hard to identify - they all look different when slanted at odd angles. One of the first things we learn about maps as children is that north is at the top, regardless of what direction you personally are facing. Descent's maps would have been much more usable if they had kept a standard orientation and showed which way you were facing.

Secondly, all the rooms were displayed as white wireframes, making very little use of the PC's capacity to display color. As a result, they often looked alike, especially long, narrow corridors. On the computer monitor, unlike on paper, color costs you nothing and contributes greatly to readability. Nobody would buy a black-and white globe; why should you have to put up with a black-and-white map? Obviously you don't want a tacky, eye-popping mishmash, but a sensibly-chosen palette.

I don't claim to have all the answers, and I certainly don't mean to condemn Descent as a game. After all, at least they gave you a map, which is more than I can say for some. But a map shouldn't be thought of as an easy-to-render thing that's slapped in near the end of development. It's a vital part of the user interface, and deserves just as much design attention as any other part.