When discussing game mechanics we need to remember that there is more to gameplay than just the on-screen interactions.  There is a real-life interaction happening during every single game you play, and it occurs between you and the controller.  When designing a game you can’t just take this for granted, and it is actually an interaction which deserves a lot of thought.  How you want your player to interact with the game world can determine exactly what system your game should be released for as well as whether or not you will need an extensive controls tutorial to educate your players.

Before getting started on your game you should ask yourself, “What control systems do I have access to?”  This is an important question because each controller type places hard limits on potential player actions.  By this I mean that every controller has a different number of buttons which players can press (or nobs/joysticks to fiddle with, but we can pretend they are just a bunch of buttons), and that number of buttons acts as a ceiling value for how many actions you can offer to the player.  On one end of the spectrum we have the single-button, single-joystick Atari, with the Xbox 360 controller being somewhere in the current middle, and near the end the current rendition of the computer keyboard.  To be more specific:  A Nintendo controller has eight buttons (A, B, Select, Start, four directions on the D-Pad) while a computer keyboard can have around 84-102 buttons.  This means that if you were to assign a single action to a single button that the Nintendo can support eight individual actions where the computer can support at least 80 different individual actions.

At first you may think, “Great.  I’ll just use a computer keyboard for everything because it can support the most actions.”  Unfortunately that actually isn’t true.  Some games just require something that isn’t a keyboard.  My favorite example is the Armored Core franchise pre-Armored Core 4.  Moving your avatar in these games requires the use of a D-Pad or an analog stick as well as four buttons.  That’s just for movement!  On a keyboard that would mean eight potential key-presses with the potential for four of them being simultaneous and constantly shifting.  Add in movement augmentation, weapon firing, and weapon shifting and you suddenly have a slew of keys to be pressing all at once.  As it turns out, this movement-control style is much more easily performed when the thumb is allowed exclusive control over D-Pad or analog stick related movement and the index/middle fingers are allowed control over the other four movement buttons.

On the other end of the spectrum are controls that are so simple that they will require you to educate your player in a likely dull fashion in order for them to know what buttons do what.  If your game only uses a button for left movement, a button for right movement, and a button for jumping, but your controller is a full computer keyboard, then how do you plan on your player figuring out which of the 102 buttons actually do anything?  On a Nintendo there are few enough buttons that players can spend the first few seconds of a game just hitting all of them to figure out what does what.  Imagine if Super Mario Bros. were released on the PC.  Either the instruction manual would need to outline the controls (ugh, an out of game tutorial?) or you will need to build an in-game tutorial.  While it is true that in-game tutorials aren’t all bad, and can be done very well, more often than not they break narrative or are completely detached from actually playing the game.  So if you want a player to simply discover your controls, then you would be better served by a simple controller like the Nintendo or Atari.

As I have already mentioned, the number of buttons your controller possesses act as a hard limit on the number of actions your player may take.  But it turns out there are two rather simple ways to inflate this number.  The first is through button combinations and the second is via context-dependent actions.  With button combinations you could make a two-button controller possess three potential actions for the player by making pressing button A an action, button B and action, and pressing both buttons A and B simultaneously an action.  With context-dependent action buttons instead of making actions such as Talk to NPC, Pick Up Object, and Open/Close Door each require a different button you can assign one button to perform all of these actions.  The game, rather than the player, will identify which should be performed via player focus or cursor location.  Unfortunately this context-dependent button has also been used to create quick-time events, which are effectively cinematic sequences that won’t complete unless you press a button at the right time.  No, I do not like quick-time events (for the most part), but I will save discussing them in depth for another time.  Arguably you can also break the hard-limit ceiling with button-press sequences (something almost exclusively found in fighting games), but I hesitate to count these as additional actions since they are almost always a set of small actions leading up to a big action, so you’re not really giving the player an extra action option, but instead giving them a reward for successfully performing many actions in a specific sequence

Beyond the number of potential actions you can program to a controller we need to also take a look at how the player is actually interfacing with the game via the controller. The following may seem like an odd question, but do you want your player to be focusing on the game, or focusing on the controls?  You would think the answer to this would always be “the game,” but I think that isn’t always the case.  My primary example is games in which you pilot something complicated such as Steel Battalion, MechWarrior, Armored Core, and just about every realistic flight simulator.  For these games there is a relatively large learning curve based on how difficult the controls are to master.  Often they’ll actually make non-movement gameplay easier to make up for it (for example: Armored Core performs almost all weapon aiming for the player).  This ends up making mastery of the controls a primary part of the rewarding experience as opposed to mastery of the internal mechanics of the game.  On the other end of the spectrum we have games like League of Legends where the controls are fairly simple, but the within-game mechanics are complicated.  The controls for complex games need to be simple so that the player can focus on actually playing instead of on perfecting finger motions.  Simple controls are also beneficial if you want to create a game focused on just drawing in the player visually/aurally.  Proteus could have been built with complicated movement controls, but then players wouldn’t have been able to absorb the environment in quite the same way.

I would move the discussion to immersion, but that’s not really what this is about.  While you can use immersive controllers (light guns, steering wheels, fixed-cycles, flipper-guitars, etc.), it’s not really economically feasible for an independently-developed game to make such a controller, and you can’t expect your player/consumer to be capable of affording a new controller for every type of game.  Once you’re restricted to standard console controllers and computer keyboards you end up with an experience that rarely truly reflects what is on screen.  Once again I will refer to pilot-sims as you can give them complex-enough controls that you really do feel like you are controlling a craft in a skillful manner, no matter what sort of controller you are using.  But for most other games (specifically those in which you are controlling a humanoid) you can’t really make controls that make you feel like you are the avatar.  When it comes to these situations the best tools for immersion are going to be related to the visuals, audio, and game mechanics; which is also why I am not going into detail about creating immersion.

So to create a skeletal review:

• Be aware of the physical limitations of your controller and the strategies that can push these limitations.
• Contemplate the consequences of your controller choice and how they relate to the control scheme you create (i.e. simple controls on simple controller vs. simple controls on complex controller)
• In most cases you likely want your controller to become an invisible part of the game, but in some cases it is appropriate to draw focus to the controller.
• Immersion is not the objective of your controller in most cases.  For immersion you should make your controls “invisible” so that focus can be placed on immersive in-game elements.

******************************

If you have any questions, feel I left something out, or disagree with me on any of my points, then please bring it up in the comments.