One of the sure fire signs of an amateur game developer is a badly thought out control scheme. Seemingly minor decisions can drastically alter the gameplay experience. Be deliberate in your control choices, as it is one of the most fundamental reasons for creating a frustrated and dissatisfying gameplay experience.

An invisible control scheme is our goal as a game designer. We want the experience to be so intuitive that after a minor orientation the player is never thinking about the control scheme. It has become invisible to them. It is serving its primary purpose, and that is to facilitate your player’s interaction with your game.

There is only one design rule that we need to keep in mind when trying to develop an invisible control scheme, and it comes from Mr. Einstein himself:

Make everything as simple as possible, but no simpler.

The control scheme should be one of the first things you start consciously thinking about as you are developing your game. You should constantly be striving to simplify the control scheme. The simpler the control scheme is, the easier it will be to pick up and the more likely it is that it will stay out of the way of your player. At the end of the day, though, as Einstein points out, it cannot be oversimplified. Ultimately, you cannot compromise your player’s ability to express themselves in the game. It’s a fine balancing act. Approach it with as much care as you do everything else.

We’re talking about Flash games, so our primary input devices are the mouse and keyboard. That gives us three main categories of control schemes: Keyboard only, mouse only, and hybrid keyboard-mouse.

Keyboard Considerations

Players have two hands. Players can comfortably use three fingers on each hand (pinkies and thumbs are out), and a thumb can be used to press a space bar. That leaves 7 possible points of control on the keyboard in a keyboard only scenario. Ignoring the space bar (we can assume it’s always easy to hit), we cannot expect the hands to have to move in order to interact with the game, except in very slow paced games, therefore we need to pick two areas where players can rest their hands, and we must pick keys in these areas that are easy to hit. The two most obvious options, likely the first ones tried by any experienced gamer are the WASD and arrow keys. This is followed by IJKL. I’m willing to give ZXC a nod. There are no other options, though, so don’t even bother.

The arrow keys are a good choice in general mostly because of transparency and ease of use. If someone is shown a game and not told any controls, chances are the first thing they will try and do is move the character around with the arrow keys (or the mouse, but we’ll get to that later).

WASD’s strength is that it is generally the second thing people will try (thanks to conventions established by first person shooters), and it gives the hand access to a few extra cursory buttons. WASD gets you space bar without inconveniencing your player, and Q and E with relatively little extra effort (so long as these keys are not needed very frequently, like perhaps for interacting with an object or triggering a super attack). If you really must, there are other options (like shift), but I think at this point you are better off re-evaluating your control scheme.

IJKL carries many of the benefits of WASD but suffers from less popularity and therefore less transparency. I know some lefties that live by IJKL. A keyboard-only solution could do worse than picking WASD + IJKL for its control options.

Mouse considerations

The most important consideration when determining if mouse control is appropriate to your game is your target market. Who do you expect to be playing your game? Yes, “Everyone will love my game!” is the answer our ego shouts out, but ignore it. Who is going to be playing your game? Is it Grandmas or 14-year-olds with lightning fast reflexes? This is a vital question to ask about every aspect of your game (genre, theme, constraints, etc.), but it is equally as important here.

It is safe to assume that even the least technologically capable individual is able to effectively use the mouse for interactions (they do every day as they browse the web, so this is experience you can build upon). Are they as deft with their keyboard? Probably not. This doesn’t mean that they wouldn’t be able to handle a game that was keyboard only. As long as the game isn’t too frenetic, a novice computer user should be able to use a very simple (single-handed) keyboard-only control layout.

Two-handed keyboard layouts, and mouse-keyboard hybrid layouts should be reserved for games that will be played by experienced gamers. If you are making a really fun and exciting game about fairies or matching colored blocks, you really ought to spend the time to rework your control scheme to use only the mouse. If you are making a bad ass zombie beat em up, then it is probably safe to assume the player has the ability to dedicate one hand to the keyboard and one to the mouse, if that is what your gameplay needs.

Don’t make the player move their hands

With very few notable exceptions, once the player’s hands are settled don’t force them to move them!. If your game is keyboard-only, then I should be able to play it completely with the keyboard. If your game is mouse-only, then I should be able to play it completely with the mouse. If you are using the arrow keys in a single-handed keyboard layout, don’t force the player to press “Enter” to start the next level, or to click a “Continue” button. Their hand is on the arrow keys, so make the arrow keys the interaction to start the next level.

Once you have determined what your layout is, assume that your player’s hands are glued in position (to the mouse, to the WASD keys, or wherever). Anything that would force them to move from those positions should be avoided like the plague. It cannot always be avoided, particularly when you’re on a tight development schedule and don’t have time to polish your UI, but you should at least try. Remember that forcing the player to move their hand position breaks the immersion and makes the player aware that there is a control scheme, and that it is not doing what they want.

Processing Input

This discussion dealt with most of the physical aspects of an invisible control scheme, specifically the keyboard and mouse devices. Processing the input received from those devices can be as important to the success of your game as the physical layout. Once you’ve made the conscious decision as to how players will send signals to your game, you need to make some difficult choices about how you will interpret those signals. Input processing will push back on your physical choices, constantly making good and bad suggestions as to how the two can work together more effectively. The physical location of your control scheme is easy, the devil is in the processing and something we will discuss in more detail in future articles.