Designing Games Humans Can Play

by Tom McIntire, AKA WhizCat

[WhizWare]

Home

Game Tutorial

Pseudo Menubar

Binary Numbers

Designing Games

API Corner

JPEG.DLL

Graphics Text

Tip Corner

Installers

Demos

Submission Guide

Newsletter help

Index


Designing Games Humans Can Play

by Tom McIntire

Posted:7/13/03

Reprinted with permission from [Basically Programming]

The title above is not a joke. What follows are my thoughts on this subject. No, I am not an expert in psychology, ergonomics, or human factors engineering. Nor am I a student of animal factors, or even animal crackers. Having written at least two hundred game programs in my lifetime, however, I feel qualified to write about what works best. That is my opinion, of course, based mostly on the fact that I have also made a whale of a lot of mistakes. If some of what follows is useful as brain fodder, I will be pleased to have been of help. As for any crumbs about which you disagree, after this you will at least know that your mistakes are not original.

The first design decision about any program ought to be about who it is for. Although this may seem so obvious it needs no explanation, not pondering about such for a few minutes before you start slapping up code can make you wish later that you had. That we must also classify people at this point is an unfortunate but necessary step. My four categories are perhaps rude, but experience has convinced me that a spade really is just a spade. Before writing a new game for humans, do a mental warm up about the differences in kids, adolescents, adults, and elders.

Kids are fun, of course. Moreover, to parents, and grandparents especially, they are bright, lovable, and precious to a fault. If it is your computer they will be playing with, however, bear in mind that they can also be fidgety, boisterous, slaphappy, and even mean at times. Games involving two or more kindergartners sharing one keyboard, one mouse, or whatever, are at the top of my list of bad ideas. While one looks for a certain key, the other will tie knots in your mouse's tail. That's during the first game. During the second, especially if they are siblings, the chaos can reach 911 levels faster than a Pentium can blink. My number one house rule is, no two-player games for players under four feet tall.

While still focused on size, consider another dimension best defined as brute force. A type of game popular with some authors tests a player's reaction times. Typically, the faster a player can hit a certain key after a visual stimulus on the screen, the higher the score. Games that mimic pinball machines fall into this category as well. $12.95 keyboards from Wal-Mart are not very robust, however, and are thus not suitable for excited slapping by heavy-handed fists, or pointed, bone-jarring jabs. Save for very rare exceptions, this author shies away from games of this ilk all together. Computer abuse is not against the law (yet), but it can be harmful to the health of your computer.

That second category of humans mentioned earlier, adolescents, is the easiest group for me to consider when designing game programs: ignore them. Those who are sociable--as most teenagers are, to excess in my experience--play stand-alone computer games only when their ISP is down, or their ICQ partners are away from home. As for those in this age-bracket who are academically driven, warping the design of one of my games for their benefit would be a waste. Several that I have met of this genre can out-program me, anyway.

Adults, of course, can be classified in at least a zillion different ways. For my purposes, only one segregation line is needed, the one that ensures respect for senior citizens. If you are not there yet, use your imagination, and reflect on the sage advice that follows.

It is difficult (impossible, really) to position two wheel chairs such that their occupants can both easily access the same keyboard and a tethered mouse. Thus, two-player games for this crowd are a waste of time, and probably violate handicapped parking laws somewhere as well.

Seniors, by definition, are nosy, and enjoy kibitzing. Most wear bifocals, some even trifocals. Legends, buttons, and icons should be large, and spaced far enough apart on the screen that they can easily be distinguished at focal lengths of both ten inches, and ten feet, on seventeen-inch monitors. The old EGA/VGA, 640x320 graphics mode works great for this crowd. That circles and arcs are so obviously made up of little dashes is not as obvious to these folks. Likewise, 16 colors are ample. The number and efficacy of those little rods in the back of our eyes diminish with age. Past sixty, even sixteen colors tend to blend and bleed if a programmer is not contrast conscious, and careful. We should also remember that 10% of all men are born color-blind, and 50% of all women believe that their husbands are part of the proverbial ten percent.

Once you get to know him personally, Sir Arthur Ritis will remind you constantly that programs requiring double-clicking of Mickey's buttons are not fun. Not at all! Kids who write game programs that expect double clicks are naughty. Whether that accusation is accurate is unimportant, actually, because folks at the Senior Citizens Center simply will not play such games. They don't have to. They can watch Law and Order reruns instead.

Drag-and-drop schemes are also bad for the cane-and-crutches crowd. Holding down a depressed button while sliding the mouse around with the dominant hand is fatiguing. For some, it is morally depressing as well, being reminded that they can no longer do what young folks do for hours on end with nimble facility. Further, assuming that grandma can do it with her other hand while the IV punctures in her good arm are healing is a wishful notion at best. Forget it.

That it took me this long to get to the main group, adults in general, was deliberate. Probably the most important thing that I have derived from hindsight engineering is, principles adhered to for the benefit of the other groups will also work for the majority. Amazingly enough, I am not one of the first genus to notice this. (PS, that was genus--not genius.)

Ever see those "heads-up displays" in fighter planes on the Discovery Channel? Notice how large and strategically spaced the various icons and legends are. Moreover, it is reasonable to assume that the paucity of colors used is not because of cost limitations--some of those planes cost more than Bill Gates made last year.

Oddly enough, to some perhaps, most of my other notions about designing game programs are equally well used, borrowed, and stolen. One of my favorite, personally owned, dusty and dog-eared books is entitled "Human Factors in Engineering and Design," by Ernest J. McCormick, published by McGraw-Hill, Inc. in 1976. I mention this here to prove that the science is certainly not new--this same book was originally published as "Human Factors Engineering" in 1957. Serious game programmers can learn a lot from such sources, by the way, gems of wisdom that are as useful today as they were a half-century ago.

This paper began with the admonishment that the first decision to be made about any new program should define who it is for. Citing one of my own designs seems a fitting way to recap all that I have said since. If my assumption is wrong that all readers of this article have at least seen some version of MS Solitaire, so be it. It likely will not be the only mistake I will make this week.

My first attempt at a solitaire program was in GP-300, a Burroughs assembler language peculiar to their "L Series" accounting computers. It was not much fun to play. The output device was a golf-ball printer. It was noisy and slow, black and white only, and had only sixty-four printable characters. Input was by way of a ten-key pad. That part of my design, however, was terrific. Especially for accountants, bookkeepers, billing clerks, keypunch operators, and programmers like me. And that is my point: it suited a category of people.

Years later, I wrote the same program again, in GW-BASIC, on my first "Color Computer". Truthfully, my old, lousy, golf-ball printer version was better. CGA graphics simply did not lend itself well to this game. Just a couple of years later, however, a complete rewrite for an EGA machine turned out to be my favorite. It is also proof that, for some of us anyway, there is a better way to play Klondike solitaire on a computer than drag-and-drop with a mouse.

My SoliDOS program ignores Mickey and his friends all together. That is also an apt preamble to my closing admonishment: Game programs that are to be sold have to be fancy to be competitive. "We who do it for fun can do it better." That too is a stolen line, by the way--saw it on a bumper sticker in Atlanta one day not long ago. Helps me remember that KISS is still the best rule for all games: Keep It Simple, Stupid.


Home

Game Tutorial

Pseudo Menubar

Binary Numbers

Designing Games

API Corner

JPEG.DLL

Graphics Text

Tip Corner

Installers

Demos

Submission Guide

Newsletter help

Index