Mastodon Icon GitHub Icon LinkedIn Icon RSS Icon

Game Design Essentials: Single Button Controls

Header image for Game Design Essentials: Single Button Controls

I hope you agree with me: controls are the true essence of every game. Sometimes, controls schemes are enough to define the game itself: once you decide the game controls mechanics, the rest of the game will follow. So I thought to start exploring controls schemes in a more formal way, searching for a way to analyze games from the user interaction point of view only.

We will start from the simplest control scheme possible: a game with a single button. These kind of games are recently more common than ever: they are easy to implement, easy to play and very suitable for smartphones (touch screens can be seen as single giant buttons). In other words, they are the perfect candidate for a funny mobile game.

Input States of a Single Button

The first thing to do when we are analyzing a control mechanics is to look at the possible way to send information between the user and the game. Each input communicates with the game through some kind of signals. In the case of a single button, this is just a boolean value. In fact, for every button, we can have just two possible states: pressed or non-pressed.

Graphical representation of a button state measurements. We can easily identify (1) press, (2) release, (3) hold, (4) idle and (5) rhythm.
Figure 1. Graphical representation of a button state measurements. We can easily identify (1) press, (2) release, (3) hold, (4) idle and (5) rhythm.

This seems to be limiting but, observing the graph of the possible input over time, we can see that we can obtain information by the time the button is pressed or released, but also measuring the time the button stays pressed or measuring how frequently (or fast) the button is pressed. In the end, we have 5 types of information we can measure with a single button.

  1. Pressed: the moment when the button is pressed.
  2. Released: the moment when the button is released.
  3. Hold: how much time the button is in an uninterrupted pressed state.
  4. Idle: how much time the button is in an uninterrupted non-pressed state.
  5. Rhythm: the (average) interval between two (or more) consecutive pressed state.

Some of these measurements are not really interesting (for instance the Idle measure) while other are meaningful only if combined with some other measure (for instance Released is commonly used to trigger an action afterHold type of input).  This left us with just 3 main input schemes. Don’t worry! They are more than enough for a huge amount of games.

Practical Example

Before we move on and start analyzing more in details these kinds of input schemes, let’s look at some example.

  1. **Pressed - **The pressed state is probably the most common. It is, in fact, the one you will immediately think imagining a game with a single button: press the button to do something. You can imagine an infinite runner type of game in which the user must press the button at the right time to make the character jump an obstacle or swing the sword to kill an enemy. The list of games based on a single pressed button is huge!
  2. **Hold - **Holding is another popular mechanic. This includes all the game in which holding the button is meaningful for the gameplay. Holding can be used to “charge a shot”, select a direction through a moving arrow or to make the character jump higher (in a subtle way like in Canabalt, or in a more evident way like in Spring Ninja).
  3. Rhythm - The rhythm is when multiple consecutive clicks/taps are required to change a game variable. This can be a direct effect such in those sports games in which we need to press rapidly a button to make the character run faster; or can be something deriving from a more complex interaction, as in Flappy Bird where the pressing rhythm affect the height of the bird due to his physic behavior.

User Interaction Analysis

The main parameter for single button control mechanic is the reaction time. This is true in general in every game, but when we have just a single button this is way more important because this is the only interaction the player can have with the game.

Average reaction time is about 200-250ms but this can be influenced (adding up to 50-100ms) by the latency of the screen or the input device. Keep in mind also that reaction time of “key-release” is faster than reaction time of “key-press” [1] and that this value decrease a lot if the user is asked to maintain constant focus (for instance in an infinite runner) or if the things the user have to react is completely unexpected (reaching easily the full second order of magnitude). Keep these values into account when you are tuning the speed of that obstacle in your next game!

An example of “charge bar”.
Figure 2. An example of “charge bar”.

Reaction times can be aided by providing visual clues or by visualizing an indicator that is predictable by the user in order to compensate the reaction time. A classic example is represented by the “power bars” in which an arrow move up and down at a fixed speed and the user is required to press the button when the bar is at its maximum power (or in a specific region of the power bar).

Another important point is: **what is the feeling a particular type of interaction with the button provides to the user? **Let’s see.

  1. **Pressed **- This is the simplest and direct form of interaction and it is the one a new player will try first. This will transmit mostly neutral feeling but, in general, pressing is the way to go for those actions that 1) are many, 2) require fast execution, 3) express the filing of “reflexes” (as avoiding an unexpected obstacle or “shoot at the right time”).
  2. **Hold **- There are different motivations for using an hold-type of interaction. The first one is the simplest one. Holding give the feeling of “continued action”, so it is the way to go for those actions that the user expect to have a continuous “muscular” effort. Charging a power shot, hanging on a wall or a cliff, swing on a rope, press the accelerator of a car. These are action in which the user will instinctively keep the button pressed, so make this count in your game. The second motivation is more technical: use the hold mechanic when you want to use continuous values in your game (for instance, to select the throwing angle of a slingshot). As we said before, a button is just an on/off state transaction, in order to obtain a non-binary value we need to measure something else, for instance, the time the button is pressed (there are other ways though).
  3. **Rhythm **- Pressing repeatedly a button give to the user two main feelings: the experience of physical effort and the anxious “hurry up!” feeling. Pressing repeatedly a button will make our hand tired and, in some sense, we force us to live a reduced version of the fatigue the digital game character is suffering in the game. For this reason, this kind of interaction is commonly used in running games, or when a character is opening a heavy door/chest. Keep in mind that pressing a button as fast as possible is tiring for the user, so use this interaction wisely! There is also another kind of “low pace” rhythm, for instance, pressing a button according to some song rhythm or visual element. This kind of rhythm is neither anxious nor tiring and can be used to give the player the feeling a “continued precision action” such as forging a weapon or playing an instrument.

Mixing Everything

When you are developing a single button game, you are not forced to choose just one input scheme. You can merge everything in a single game! Common examples include press to shot and hold to charge a more powerful weapon, press to jump and hold to aerial perform evolution before touching the ground again, press in order to jump and double tapping (a simplified kind of rhythm measurement) to slide. These are just common examples but you can be creative and combine everything in some novel way!

In the next article, we will look at more complex control scheme: the directional one.

(1) : Reaction Time and Movement Time Measured in a Key-Press and Key-Release Condition - 1991 - Bjørklund

comments powered by Disqus