Many modern console titles -- be they first-person shooters (FPS), role-playing games (RPG), strategic games or games of a completely different genre -- present themselves from a first-person perspective. While PC first-person titles are blessed with a mouse and keyboard for input control, console games must make use of standard game controllers which are more naturally suited to different modes of presentation.
This goal of this article is to motivate designers and programmers to make view control and targeting easier for the player, in a way which suits the style and the gameplay of the title. The main body of the article presents some solutions to the problems faced in designing these controls, some of them used successfully today in games such as Halo and Unreal Tournament, and others which attempt to innovate within first-person presentation.
Although the first-person perspective is usually referenced in the text, most of this article also applies to third-person games in which the camera is permanently locked directly behind the player.
View Control, The Lazy Way
Too many games on the shelves today ship with a basic view control implementation which does little to aid the player. A game's control system is extremely important to the user interface design. It is how the player conveys intention to the game. As such, control should not be the main challenge for the player, this should be the game itself.
Typically, the mapping of the two axes of an analog stick to pitch and yaw is done with little thought. It is assumed that the best approach is to apply movement of the stick in a linearly proportional manner to the change in view angle. I shall argue throughout the article that this isn't sufficient. Gamers need additional help if the standard console controller is to become anywhere near as intuitive as the mouse and keyboard solution.
Before I present some solutions which can be applied to the individual components of the control system, I would ask the reader to think about his/her design goals for the controls. Not all of these solutions will be applicable to your game, and you must consider the context -- and thus the suitability -- of the solution.
For example, if the game is essentially an FPS with the emphasis on shooting, your control system will be very different than a role-playing game in which combat is turn-based. For the FPS, your design goal will likely be to make shooting and evading the enemy natural and intuitive. For the role-playing game, you may want to optimize the control set to allow the player to search the environment for objects and clues. Even within a specific game genre, each game has its own needs and emphasis on certain player actions.
Think about your genre, typical level topography, enemy behaviors and game context in general, and design appropriately.
1. Yaw acceleration. The yaw speed, or rate of turn by the player, is an important facet of first-person control design. The player must be able to turn in precise amounts to allow accurate aiming, but must also be able to turn quickly to face an opponent who has outflanked the player, or even surprised the player from behind.
Figure 1. Yaw speed increases until it reaches a maximum.
Many FPS games simply map the yaw speed to the control-stick offset. But there simply isn't enough subtlety in the typical console control stick to give the player both precise and fast turning using this mapping. The solution is make the yaw speed accelerate when the player is pushing towards the extremes in the X-axis, up to a maximum turn speed. This means that the player can have precise aiming, but can turn fast by pushing the stick fully left or right. This is extremely natural and transparent player. With a well-tweaked system, a player may not be aware of any acceleration: all he perceives is that he can turn both quickly and accurately.
It's important to note that the acceleration only kicks in when the control stick is at full tilt. This enables the player to make smaller aiming corrections without acceleration.
2. Reduce pitch sensitivity. There is no reason why the pitch control should be the same speed as the yaw control. In many games, players spend 99% of their time looking at the horizon, within perhaps a 30-degree arc. Compare this to yaw control, where the player needs 360-degree movement, and it is immediately apparent that yaw and pitch control are two different problems requiring different solutions.
A common complaint made by beginners is that they get stuck looking up or down, spending most of a firefight targeting their feet. This is easily rectified by simply reducing the pitch sensitivity. Since players usually target enemies within this 30-degree pitch arc, we don't need pitch speed to be as fast as yaw speed.
Figure 2. Left: a linear yaw response. Right: an exponential yaw response.
3. Non-linear pitch and yaw response. We can further aid the player in both pitching and yawing by applying the control stick offset non-linearly. This is another trick that provides fast and quick aiming. A similar aid is often presented to laptop computer users who have a touchpad in place of a mouse. Quick movement across the surface of the device yields a much bigger pointer movement than a slow sweep across the same distance. Again, when implemented correctly, this should be transparent to the player.
4. Soft lock. Some games employ a locking button, which locks the player's view to center around a specific target while the player is free to strafe and move freely. For a typical FPS this goes too far, removing much of the challenge from the player. Furthermore, in most such games, the player should be rewarded for making head shots, or hits on other critical parts of the enemy's body. A hard-locking system does not allow this.
Figure 3. The speed of turning decreases as the target reticule passes over the enemy's screen area.
Fortunately, there is a less explicit, less limiting option. With a "soft lock", there is no lock button. However, as the player sweeps the target reticule over an enemy, the pitch and yaw rate decreases. This makes the enemy "sticky" to the view control, aiding rapid targeting. This technique doesn't substantially lower the skills required by players -- they must still target the correct part of the enemy for a good take-down. Don't forget that we're playing catch-up with the mouse and keyboard control, and the player is entitled to a little help.
Again, there is an analogy with laptop touchpads. Many
drivers for these devices give a user the option to
make buttons and window controls sticky. This makes
these controls easier to press, much in the same way
as we have made targeting enemies easier.
Besides tweaking the speed reduction in pitch and yaw controls, it is also worthwhile to experiment with the amount of screen area surrounding the enemy that we make sticky. It may pay dividends to increase this area beyond the outline of the enemy.
5. Hard lock with fine control. This is an alternative to soft locking, and it's more applicable to certain titles. The idea is that we provide a lock button, as dismissed in the above solution. However, when locked on, we allow the player to move the reticule within the screen area of the enemy, permitting the player to make headshots and target other strategic points. Again, the context of your game will make your design choice for you, whether you choose this solution, soft locking, or some other aid.
6. Jump pitch compensation. Earlier I mentioned the situation where the beginner player spends much of the fight looking at his feet. Even experienced gamers can end up doing this if they use a lot of jumping in their evasion tactics. They attempt to track the enemy by pitching downwards, but because the speed of the jump is faster than the speed at which they can pitch to compensate, they lose track of the enemy. During the firefight, they can become confused as to where the player is looking, and they end up dying, often while looking at their feet. This can be very frustrating for the player, who knows the problem is the controls, not their skill.
The answer is to auto-compensate. If the player jumps while the reticle is over an enemy, pitch the view automatically to keep the enemy in view. This is much more natural. In real life, we would have no trouble jumping while looking at a target, so why should we face this challenge in the game world?
Figure 4. The auto-aim zone is indicated by the grey box around the body. Left: this will miss. Middle: this will hit, but it may hit any part of the body. Right: this will be a head-shot.
7. Intelligent auto-aiming. Many console FPS games employ an auto-aim system, which is often adjustable in the game options. The idea is that the player does not have to be totally accurate when targeting in order to shoot the enemy. As long as the reticule is within a certain boundary around the enemy, an accurate shot is made. However, as with the hard-locking system, this takes the option of shooting a strategic sub-part of the enemy away from the player.
Let me offer a more intelligent auto-aiming system.
If the target reticle is directly over any part of
the enemy, we don't modify the shooting direction.
If the reticle is within the auto-aim distance but
not over the body, we auto-aim for the player. This
system makes targeting easier, but does not take the
advantage away from the skillful player, who can still
make those headshots unhindered. Auto-aim is a matter
of personal preference, so I'd advocate keeping it
as a adjustable game option.
8. Auto-peek. Some games require a stealthy approach. In these games, it is not uncommon to allow the player to peek his head around a corner, either to avoid raising the attention of the enemy, or if in a firefight, to present a minimal target. Current games employ an extra button for this use. However, it's entirely possible to do this automatically for the player, in a manner which is potentially less unwieldy. Remember that the control system is supposed to convey the intention of the player in an intuitive and efficient manner. We don't need the extra button.
To use our auto-peeking system, the player moves along flush to the wall, approaching the corner which they wish to peek around. Just before they reach the corner, they turn using the yaw control to look in the direction in which they wish to peek. In previous games, this would leave the player looking at the wall, which is not very useful. However, our system senses that the player is approaching a corner flush to the wall and turning to look around the corner, and automatically makes the player's character lean out to peek.
While turning in this context, the amount of lean should always ensure that at least over a half of the screen is taken up by the wall. As the player turns back, the player's character leans in again. The player already has to deal with remembering which button is used to reload, and while under fire, having a second button for peeking is asking a great deal of the player's dexterity.
A further improvement would allow the player to decide to cancel the lean and move around the corner. If the player is peeking around the corner and presses forward on the control stick, we pull the player character's body straight in line with the head's position, and the player can carry on as normal.
Is All This Really Necessary?
While reading this article, you might be thinking that some of these solutions are over the top - design overkill. However, to my knowledge, all except two of them - "auto-peeking" and "hard lock with fine control" - are already implemented in shipping titles. It would be a worthwhile exercise to examine a few console games in your collection and see which methods they use.
When it comes to first-person control using dual analog sticks, we are still breaking ground. In fact, different games require different solutions, and there is no single optimal solution that will work in every game. But hopefully this article will help you consider the many possibilities which are available to you. In time, perhaps we will no longer have to play games where the only control available to the player is changing the sensitivity of the control stick.