Game Controllers

When you drive your car, you don't use a keyboard and mouse ”at least not yet. When you're racing along Santa Monica Boulevard in a round of Grand Theft Auto 3 , you probably don't want to type in commands to mash the accelerator through the floor and hang a flying Louie. You want the experience and the control system to be as real as possible without live ammunition . You want a real steering wheel, real pedals, and the real aroma of searing rubber and SAE30 motor oil flaming out your exhaust pipe.

So far electronic devices aren't very adept at generating odors (although bad software really does stink), but some special hardware can help make you more adept in playing games ”mechanisms that give you better control. Computer people have a clever name for the devices that help you control games . They call them game controllers .

The history of game controllers goes back to the first personal computers and beyond. As soon as computers graduated from the workbench to the television set, people played games on them. For control, they used joysticks . Even the business-oriented IBM Personal Computer made provisions for joysticks and a two-player option called game paddles using a special interface called the game port . But such primitive control systems are as pass as Pong , the first real video game.

Today's elaborate wheel-and-pedal combinations are possible thanks to the architectural changes made by Windows. The game port hardware interface defined the control afforded by joysticks ”two position sensors and a single pushbutton. Thanks to an additional layer of interface abstraction (driver software) and a better connection system (USB), designers are free to create any kind of control system they want when working with Windows.

The essential part of any game controller is one or more sensors or transducers . A sensor samples a physical measurement ”be it brightness, distance, direction, or weight. A transducer converts or translates a physical property or change into an electrical signal. (The line between them is hard to draw ”transducers are sensors, but not all sensors are transducers.) A pressure sensor, for example, is a transducer that varies its output with how hard you press on it (say, by hammering the accelerator). The magnetic or optic motion sensors in mice are not generally considered transducers.

The difference isn't what matters. Rather, the game controller depends on being able to sense what you do ”push a pedal, spin a wheel, pull back on a throttle or stick ”and quantify it. The controller then takes the result of that quantification, translates it into a digital code, packages the information in a data packet, and whisks it out to your computer through its interface. The driver software in your computer receives the packet from the interface and translates its content into a form compatible with your game (or other program) and passes it along through the program's Application Program Interface (API). Your game then decides what to do with the control data.

There's no limit to the number of controls possible using this system. You could have a game controller as complex as the bridge of the Starship Enterprise. (Actually, that's easy because the bridge is just a set, and none of the controls really work.) The controller designer is free to create anything imaginable (but technically and economically feasible , of course). Moreover, the system works both ways, so designers can put feedback mechanisms ”for example, controllers that shake you up so you know when you're really applying power ”to make games more realistic. The only essential element is that the game software understand the information sent by the controller. Controller designers must match the requirements of game APIs. The software driver and interface are simply the glue that holds everything together.