hap.tic (adj.)(1890)
{(haptesthai) to touch}
1: relating to or based on the sense of touch
2: characterized by a predilection for the sense of touch (a haptic person)
3: to be out of haptic with reality

Seven peripheral manufacturers are prototyping and/or shipping more than nine force-feedback game devices for home use, at or under $200. Three companies are supplying the force-feedback technology: CyberNet, Immersion, and Microsoft. With force feedback ramping up and three implementations available,

Some of the companies listed in Table 1 also distribute force-feedback devices for game consoles and arcade machines. Companies such as Happ Controls (the largest manufacturer of arcade force-feedback devices) use technologies similar to those being discussed, but they won't be the focus of this article. For a more complete view of the market, take some time to browse the research sites listed at the end of this article. The Intel site has the specifications for the Open Arcade Architecture Coin-op Reference Platform also known as the Arcade PC standard (which includes force feedback).

Mechanics

Not all force feedback devices are created equal. The more expensive devices are able to produce high-frequency sensations at a cost of a few thousand dollars, compared to a few hundred for the home versions. A hefty portion of the cost difference is spent reducing the compliance (play) between the actuators (motors) and the stick. The following sections discuss the interface between the actuators and the stick.

COMPONENTS. The play and durability of a force-feedback device depends, in part, on the material and tolerance of the machining. Cheaper materials, such as plastic, are pliable, do not hold up to high-tolerance machining, and wear faster. Here, the material limits the performance. More expensive alternatives, such as composites, aluminum, and alloys, can hold higher-tolerance machining. Still, just because quality material is present doesn't mean that it has undergone the costly high-tolerance machining. Quality material has the added benefit of holding up better to general wear and tear. Let's open a force-feedback input device and examine the inner workings.

GIMBAL. The gimbal connects the stick to the transmission. Force-feedback joysticks generally have more play than steering wheels because of their dual-axis motion. The biggest contributor to gimbal play are the slots of a slotted bale. Double-slotted bales (Figure 1) are the loosest. Immersion has patented a slotless gimbal, shown in Figure 2. Keep an eye out for this design in retail sticks over the next year. Currently, it's only available in research-quality devices.

Figure 1: Double-Slotted Bale

Figure 2: Five-Bar Linkage

TRANSMISSION. Actuators are connected to the gimbal by the transmission. Geared transmissions must have play or the gears will bind. Tight gears require precise machining. Therefore, cost becomes reliant on the material and machining commodities. A cable/belt drive is a higher-quality method of transmission. Since there are no gears that can bind, this method has the potential for a very tight force response and much less noise (gears are quite noisy). The counter rotational requirements of force-feedback transmissions are demanding, so either the cable/belt will need to be extremely strong or devices will need easily accessible adjustment screws for keeping the cable/belt tight.

ACTUATORS. Force-feedback joysticks use two motors, which are similar to those found in fax machines and printers. They exert about 1 lb. of sustainable force per motor, peaking at around 1.5 lbs. Force-feedback wheels have one motor that can sustain 3-4 lbs., peaking at around 5 lbs. Cheaper motors normally exhibit higher friction, so they dampen out subtle forces, causing poor or unperceivable response.

Designing Force Effects

The force-feedback element of a game requires aspects of physics and collision detection that should already be implemented and used by the audio engine. When you get down to the code level, force response is very similar to 3D audio. In my experience, piggybacking the audio code helps determine what effects to add, where to add them, and saves both CPU and developers' time by reusing computations. Exceptions to this are effects such as "wheel stiffness," that do not have an associated sound effect, but remain active throughout the simulation.

While Microsoft's DirectX 5 documentation doesn't go into the artistic part of force feedback, the three force-feedback engine manufacturers have a lot to say in their development documentation. I won't cover the design elements in the same manner, so I recommend examining the commercial web sites listed at the end of this article and the books in the "Books On Force-Feedback Technology" sidebar.

The initialization of a force-feedback device is faster with DirectX 5 (if the device is powered), because the device must exist in the game controller's property sheet. Proprietary APIs that don't use this information will search for a force-feedback device on each port and wait for either a confirmation or a timeout before moving on to the next. This can take up to five seconds, which makes automatic detection of a force-feedback device at game start-up less appealing.

Once the force-feedback device is initialized, the user should be able to customize the force settings for the device. At a minimum, users should be able to set the gain, since force-feedback devices tend to vary in the amount of foot-pounds they can exert. (There is a proposal to have this gain setting incorporated into the device's property sheet in Windows, but you'll need to implement this yourself in your game, at least until DirectX 6.) Various types of devices exert different amounts of force (for example, wheels typically exert more force than sticks), but even the forces applied by different brands of joysticks can vary. Gain adjustment may seem like a simple task at first, and it can be depending on how far you take this setting. Gain can easily be applied to Springs and Jolts for example, but Vibrations and custom forces are commonly very temperamental, and adjusting their gain can ruin the desired effect. So, if some effects can be ruined by differences in gain, and force-feedback devices have different force ratings, there's a problem. Basically, each force-feedback device requires some special tuning consideration to get the desired effects just right.

Carefully consider how you allow players to map (or customize) their input controls. When input mappings are altered by the game player, the new mapping should also change the implementation of force-feedback effects. If you don't give adequate thought to how your input device will behave once the player modifies the standard configuration, the player could be in for an unpleasant experience. For instance, imagine that a player is using a joystick in a car racing game. The default mappings have the y axis act as a combination gas/brake pedal, increasing the vehicle's speed when the stick is moved forward and braking the car when the stick is moved back toward the player. If the player remaps the y axis so that pushing forward on the stick up-shifts the car's gears and pulling back down-shifts the car, then a y-axis jolt can cause a problem. A collision to the car from behind would cause a forward jolt effect on the stick, and inadvertently cause the car to shift up a gear.

Allowing the player to turn on or off certain force effects is a nice feature (for example, engine vibration transmitted to the joystick may be annoying in a long race). You could even go so far as to let players customize certain effects. While this may be going overboard, remember that game extensibility is valued by most players. If effects are created with a sensation editor and saved to a file loaded by the game, players may be able to customize these effects with the same editor, and share their customized effects with other players on the Internet.

Switching between various frames of reference in your game is risky. A frame of reference (FOR) is the "who" or "what" to which the force response attaches. You generally only need to consider two FORs, the player's body and their machine (one inside the other, but not rigidly attached). Switching between FORs may confuse the player, making forces appear buggy. For example, forces on a car don't have the same vectors as those on the driver, and switching between the two hurts the realism of the game. Choosing the object that directly interacts with the simulated environment usually provides the best experience. Switching FORs or choosing a bad FOR also complicates development by making it difficult for the engineer to identify and correct undesired feedback loops.

Be careful of feedback loops in your force effects. Feedback loops occur when a force is attractive. A simple example of this is when a car hits a barrier and the frame of reference is attached to the driver of the car, but the collision detection/correction is attached to the car itself (Figure 3).

Figure 3. The forces involved in a car crash

The force response is in the general direction of the barrier, which makes the player hit the barrier again - hence the feedback loop. A feedback loop was not appropriate for the example barrier collision (caused by the poor FOR choice), but in some cases it works out great. Gravity wells, rubber-banding, and tractor beams could all benefit from a feedback loop, which, by the way, can be pulled out of with a little effort on the gamers part.