Stephen Morris is the technical director at Greenfly Studios, an independent games developer based in the UK.

Ever cursed a game for being too laggy? Perhaps it was the opposite and the controls were too sensitive? People often talk about intuitive controls but what exactly does this mean?

In an earlier article, current Best of British chief Jake Birkett touched on the pros and cons for various control schemes available to mobile developers.

I wanted to take this a step further and analyse why do particular schemes feel appropriate.

Extending the senses

When a player handles a digital game, their senses become instantly focused on the events within the 4-inch screen to the exclusion of the surrounding environment.

The game acts as a surrogate for our senses: the visuals delivers the environmental details and hazards, the sounds gives us important audial clues, and the rumble motor can give us the required tactile experience of a heavy collision.

All of these senses contribute to delivering full immersion to the player but if the game can't be controlled effectively, the experience is broken.

A broken experience means the player no longer feels engaged and instead switches over to something else. So exactly how does the player control the game and what makes it intuitive?

The best definition for intuitive controls is "the intent of player actions translated into the desired reality."



QWOP - a game that makes a feature of obtuse controls

The closer the game can represent what the player meant to do, the more immersive the experience. If the game is slow or incredibly difficult to control, the more impatient the player gets and eventually gives up the game in frustration.

Some people revel in difficult and obtuse control schemes (see Bennett Foddy's QWOP) but for the majority, they favour clear and easy controls with minimal response lag.

Internal processors

In the 1980s, the human processor model (a cognitive modeling method) was devised to calculate how long it takes an average person to identify, process and perform a mental task.

The research was able to break down human cognition into several key processing areas: perception, cognition and motor.

The perception processor was responsible for taking input from our senses and identifying internal patterns and generalisations. The resultant data would then be passed on to the cognitive processor - this is directly responsible for determining what to do with the information and next point of action. The next step would then be handled and converted into muscle movement by the motor processor.

The durations for each section could be broken down as follows:

• Perceptual processing: ~100ms [50-200ms]


• Cognitive processing: ~70ms[30-100ms]


• Motor processing: ~70ms[25-170ms]

The absolute minimum time in which a player can observe an action, determine what to do and react is 95ms (perception 50ms, cognition 30ms and motor 25ms). This is based on intense circumstances but in reality, the average person would have a duration of 240ms.

This sequence of stages will then routinely loop and create a correction cycle. As your physical movements respond to the actions presented on screen, your physical actions are fed back into your perceptual processor. Alterations are decided upon and then muscles moved to fine-tune and correct the movement.

As an example, lets use Mobirate/Chillingo's recent game Dead Ahead. Visually, we can see our protagonist is heading directly towards the monochrome police car.



We place our thumb on the right hand side and slide upwards to control our avatar out of harm's way. The amount we do so is the result of continually assessing the situation and our intended result.

So if our correction cycle is 240ms, why do games insist on 30 frames per second minimum?

It's because human processors run concurrently. Once the perceptual processor has finished its cycle and passed on the data, it observes the senses once again.

This means the visuals have to cycle at least at 100ms or 10 frames per second - the minimum required for the illusion of movement. 20fps will border on the 50ms boundary whereas 30fps will dip below, making movement seem much smoother.

This processing system also applies to the game. It needs a frame to take input, a frame to process and then a frame to update it's 'motors' - all within the 50ms lower bounds.

At 60fps, this gives us the 3 frames required to provide 'instantaneous' feedback. The longer it takes for the game to respond, the higher the response lag and the more sluggish the player perceives the game.

Mapping the response curve

Now that we have identified the need for, and maintaining, a high frame rate, how do we translate a player's input into movement?

When the player taps the jump button or swipes upwards, does the movement feel tight or floaty? We can represent this movement through the use of a curve graph or, specifically, an ADSR envelope.



The curve can be broken down into four distinct sections: Attack, Decay, Sustain and Release.

The attack is the initial rise from 0 to the maximum value. The decay will drop from the maximum value to a level that can be sustained for a duration of time with the button held down. Finally, the release occurs when the player releases the button or the maximum amount of sustain time has been reached.

So, how do we define tight and loose responses and where would we use them?

Here is an example for Terry Cavanagh's Super Hexagon.



Notice in this example, the attack and release are relatively short indicating a tight yet responsive feel. Due to the nature of Super Hexagon, you would expect a fast attack phase and the movement sustained as you aim to position your ship between the upcoming gaps.

Making the attack and release shorter contributes to a more 'skittish' feel.

A loose response can be shown as thus:



As you can see, the ramp up to the expected maximum value builds up slowly. In a fast, arcade game where reactions are critical, an attack phase this gradual would be detrimental and possibly fatal.

You can sometimes see this in some platformers but you are more likely to have experienced it in games such as Asteroids. When you press the thrusters, it takes a relatively long time to reach maximum acceleration.

Final thoughts

As a developer trying to eek out every spare cycle in the fight against unoptimised assets or lagging hardware, we can now identify how important it is to give players the immediate response they crave for.

More importantly, it is also critical we match the manner in which elements respond to events according to the player's expectations.

This article only scrapes the surface on how controls can make or break a game. In the next piece, I'll dive into promoting the player immersion even further using the underlying control schemes to reach expected goals.

You can find out more about Greenfly Studios on the company website, or follow Stephen on Twitter.