Game Programming Algorithms and Techniques: A Platform-Agnostic Approach (2014)

Chapter 5. Input

Without input, games would be a static form of entertainment, much like film or television. It is the fact that the game responds to the keyboard, mouse, controller, or other input device that enables interactivity.

This chapter takes an in-depth look at a wide variety of input devices, including those that are predominantly for mobile devices. It further covers how a high-level input system might be designed and implemented.

Input Devices

As shown in Figure 5.1, there is a host of types of input devices, some more common than others. Although a keyboard, mouse, or controller might be the most familiar input device for a PC or console gamer, on the mobile side of things touch screens and accelerometers dominate. Other more recent input devices include the WiiMote, Kinect, guitar controllers, and head-tracking devices for virtual reality headsets. Regardless of the device, however, certain core techniques are applied when the device is queried for information.

Figure 5.1 A variety of input devices.

Most forms of input can be broken down into two categories: digital and analog. A digital form of input is one that has a binary state: It can be either “on” or “off.” For example, a key on a keyboard typically is digital—either the spacebar is pressed, or it isn’t. Most keyboards do not have an in-between state. An analog form of input is one where there can be a range of values returned by the device. One common analog device is a joystick, which will have a range of values in two dimensions.

Whereas a keyboard may only have digital inputs, many input devices have both analog and digital components. Take, for instance, the Xbox 360 controller: The directional pad and the face buttons are digital, but the thumb sticks and triggers are analog. Note that the face buttons on a controller are not always digital, as in the case of the Playstation 2, but it’s a typical implementation.

One other consideration for some types of games is that the input system may need to respond to chords (multiple button presses at once) or sequences (a series of inputs). A genre where these are prevalent is the fighting game, which often has special moves that utilize both chords and sequences. For example, in the later Street Fighter games, if a Blanka player presses forward and all three punch or kick buttons at the same time (a chord), the character will quickly jump forward. Similarly, all Street Fighter games have the concept of a fireball, which is performed with a quarter circle forward followed by a punch button (a sequence). Handling chords and sequences is beyond the scope of this chapter, but one approach is to utilize a state machine designed to recognize the different special moves as they are performed.

Digital Input

Other than for text-based games, standard console input (such as cin) typically is not used. For graphical games, the console usually is disabled altogether, so it would be impossible to use standard input in any event. Most games will instead use a library that enables much more granular device queries—one possibility for a cross-platform title might be Simple DirectMedia Layer (SDL; www.libsdl.org).

With libraries such as SDL, it is possible to query the current state of a digital input device. In such systems, it usually is possible to grab an array of Booleans that describe the state of every key on the keyboard (or any other digital input device). So if the spacebar is pressed, the index corresponding to the spacebar would be set to true. Memorizing which index numbers correspond to which keys would be tiresome, so usually there is a keycode enumeration that maps each index to a specific name. For example, if you want to check the status of the spacebar, you might be able to check the index defined by K_SPACE.

Now suppose you are making a simple game where pressing the spacebar causes your ship to fire a missile. It might be tempting to have code similar to this:

if IsKeyDown(K_SPACE)
fire missile
end

But the problem with this code is that even if the player quickly presses and releases the spacebar, the if statement will be true for multiple consecutive frames. That’s because if the game runs at 60 FPS, the player would have to press and release the spacebar within the span of 16ms for it to only be detected on one single frame. Because this is unlikely to occur, each tap of the spacebar would probably fire three or four missiles on consecutive frames. Furthermore, if the player simply holds down the spacebar, a missile will fire once per frame until it’s released. This might be the desired behavior, but it also might completely imbalance the game.

A simple but effective improvement is to track the state of the key on both the current frame and the previous frame. Because there are now two Boolean values, there are a total of four possible combinations, and each maps to a logically different state, as detailed in Table 5.1.

Table 5.1 Last and Current Key State Combinations

So if on the last frame the spacebar was not pressed, but on the current frame it is pressed, that would correspond to the “just pressed” result. This means if the missile fire action were instead mapped to a “just pressed” spacebar action, the ship would only fire one missile per discrete button press.

This system also provides more flexibility than the previous approach. Suppose our game allows the player to charge up his missile the longer he holds down the spacebar. In this case, we would begin charging the missile on “just pressed,” increase the power of the missile the longer the spacebar is “still pressed,” and finally launch the missile when “just released” occurs.

In order to support these four different results, we first must declare an enum of possibilities:

enum KeyState
StillReleased,
JustPressed,
JustReleased,
StillPressed
end

Then, when the input is updated, the current snapshot needs to be grabbed:

function UpdateKeyboard()
// lastState and currentState are arrays defined elsewhere,
// which store the entire state of the keyboard.
lastState = currentState
currentState = get keyboard state
end

Finally, a function can be implemented that returns the correct KeyState value depending on the permutation:

function GetKeyState(int keyCode)
if lastState[keyCode] == true
if currentState[keyCode] == true
return StillPressed
else
return JustReleased
end
else
if currentState[keyCode] == true
return JustPressed
else
return StillReleased
end
end
end

With this function, it is then possible to check the KeyState of any key. Later in this chapter, we will discuss an event-based system that builds on this. But for now, let’s move on to analog devices.

Analog Input

Because analog devices have a wide range of values, it is common to have spurious input. Suppose a joystick has its x and y values represented by a signed 16-bit integer. This means both the x and y values can range from –32,768 to +32,767. If the joystick is placed down on a flat surface and the player doesn’t touch it, in theory both the x and y values should be zero, because the joystick is not being touched. However, in practice the values will be around zero, but rarely precisely zero.

Because of this, if the raw analog input was just applied directly to the movement of a character, the character would never stay still. This means you could put down your controller yet still have your character move onscreen. To resolve this problem, most games implement some sort ofanalog filtering, which is designed to eliminate spurious input data. Figure 5.2 illustrates how this filtering might be used to implement a dead zone, which is an area around the center of the joystick input range that is ignored.

Figure 5.2 Joystick dead zone causes input within the inner circle to be ignored.

A very basic dead zone implementation would be to set the x and y values to zero in cases where they are relatively close to zero. If the values range between +/– 32K, perhaps a ~10% dead zone of 3,000 could be utilized:

int deadZone = 3000
Vector2 joy = get joystick input

if joy.x >= -deadZone && joy.x <= deadZone
joy.x = 0
end

if joy.y >= -deadZone && joy.y <= deadZone
joy.y = 0
end

However, there are two problems with this approach. First of all, the dead zone will be a square instead of a circle. This means if you press the joystick such that the x and y values of the joystick are both slightly less than the dead zone value, you won’t get any movement even though you have moved the joystick beyond the 10% threshold.

Another issue is that this approach does not use the full range of values available. There is a smooth ramp from 10% speed to 100% speed, but everything below 10% is lost. We would prefer a solution where the movement can be anywhere from 0% speed to 100% speed. Or in other words, we want valid movement input to start at slightly higher than 0% speed, rather than slightly higher than 10% speed. This will require modifying the range so an “original” value of 55% speed, which is half way between 10% speed and 100% speed, is instead filtered into 50% speed.

To solve this problem, rather than treating the x and y values as individual components, we can treat the joystick input as a 2D floating point vector. Then vector operations can be performed in order to filter for the dead zone.

float deadZone = 3000
float maxValue = 32677
Vector2 joy = get joystick input
float length = joy.length()

// If the length < deadZone, we want no input
if length < deadzone
joy.x = 0
joy.y = 0
else
// Calculate the percent between the deadZone and maxValue circles
float pct = (length – deadZone) / (maxValue – deadZone)

// Normalize vector and multiply to get correct final value
joy = joy / length
joy = joy * maxValue * pct
end

Let’s test out the preceding pseudocode. The midpoint between 32,677 and 3,000 is ~17,835, so a vector with that length should yield a percent of ~50%. One such vector with that length would be x = 12,611 and y = 12,611. Because the length of 17,835 is greater than the dead zone of 3,000, the else case will be utilized and the following calculations will occur:

After the analog filtering is applied, the resultant vector has a length of ~16,404. In other words, a value that’s 50% between 3,000 and 32,677 was adjusted to be the value 50% between 0 and 32,677, which allows us to get the full range of movement speeds from 0% all the way to 100%.

Event-Based Input Systems

Imagine you are driving a kid to an amusement park. The kid is very excited, so every minute she asks, “Are we there yet?” She keeps asking this over and over again until you finally arrive, at which point the answer to her question is yes. Now imagine that instead of one kid, you’re driving a car full of kids. Every single kid is interested in going to the amusement park, so each of them repeatedly asks the same question. Not only is this annoying for the driver, it’s also a waste of energy on the part of the kids.

This scenario is essentially a polling system in that each kid is polling for the result of the query. For an input system, a polling approach would be one where any code interested in whether the spacebar was “just pressed” would have to manually check. Over and over again on every single frame, and in multiple locations, GetKeyState would be called on K_SPACE. This not only leads to a duplication of effort, but it could also introduce bugs if the state of the keyboard changes in the middle of the frame.

If we return to the amusement park analogy, imagine once again you have that car full of kids. Rather than having the kids poll over and over again, you can employ an event-based or push system. In an event-based system, the kids “register” to an event that they care about (in this case, arrival at the amusement park) and are then notified once the event occurs. So the drive to the amusement park is serene, and once you arrive you simply notify all the kids that you’ve arrived.

An input system can be designed to be event based as well. There can be an overarching system that accepts registrations to particular input events. When the event occurs, the system can then notify any code that registered to said event. So all the systems that must know about the spacebar can register to a spacebar “just pressed” event, and they will all be notified once it occurs.

Note that the underlying code for an event-based input system still must use a polling mechanism. Just like how you as the driver must continue to check whether or not you’ve arrived at the park so you can notify the kids, the event-based input system must be polling for the spacebar so it can notify the appropriate systems. However, the difference is that the polling is now being performed in only one location in code.

A Basic Event System

Certain languages, such as C#, have native support for events. However, even if events are not natively supported by your language of choice, it is very much possible to implement an event system. Nearly every language has support for saving a function in a variable, whether it’s through an anonymous function, lambda expression, function object, or function pointer. As long as functions can be saved to variables, it is possible to have a list of functions that are registered to a particular event. When that event is triggered, those registered functions can then each be executed.

Suppose you want to implement a simple event-driven system for mouse clicks. Different parts of the game code will want to be notified when a mouse click occurs and in which location on screen. In this case, there needs to be a central “mouse manager” that allows interested parties to register to the mouse click event. The declaration for this class might look something like this:

class MouseManager
List functions

// Accepts functions passed as parameters with signature of (int, int)
function RegisterToMouseClick(function handler(int, int))
functions.Add(handler)
end

function Update(float deltaTime)
bool mouseClicked = false
int mouseX = 0, mouseY = 0

// Poll for a mouse click
...

if mouseClicked
foreach function f in functions
f(mouseX, mouseY)
end
end
end
end

Then any party interested in receiving a mouse click would be able to register a function by calling RegisterToMouseClick in the following manner:

// Register "myFunction" to mouse clicks
MouseManager.RegisterToMouseClick(myFunction)

Once registered, the function will be automatically called every time a mouse click occurs. The best way to make the MouseManager globally accessible is to use the singleton design pattern, which is a way to provide access to a class that has only one instance in the entire program.

The event system used for the mouse manager could easily be expanded so that it covers all button presses—it wouldn’t be that much more work to allow functions to be registered to every key on the keyboard, for example. But there are a few issues with the approach used in this basic event system.