Game Control Design
Sweets are first tasted by the eye, but flavour is the heart and soul of all confectionery. --John Millar (1826-1896)
It's called a joystick because games are fun—or at least they're meant to be. Of course, I doubt this is the real reason. Nevertheless, I stand by my reasoning as the definitive one. It may not be true, but it makes sense.
Although there are several books available on the market about game programming, there are very few about game design. The few that are available tend to be either very brief and shallow, or they're not really geared towards video game design, instead covering the intricacies of board or paper games.
To me, it seems obvious that there is little point in writing a game that no one wishes to play. There are certain guidelines that can be followed in order to make your game more appealing.
Graphic and sound content obviously play a big part in making your game enjoyable, but these areas are covered amply elsewhere. This article covers the lesser known basics of playability: the control system and level design. Along the way, I'll make the occasional reference to a D*S game I wrote about a year ago called Teardrop Explodes. If you wish to try it out, feel free to download it from http://www.geocities.com/SiliconValley/Heights/2276/.
In any game the control system should be kept simple. Why use four different buttons when one will do? An example of this syndrome appears in most of the new 3D soccer games. Here, 3 or 4 buttons are used just to kick the ball in a variety of manners (pass, shoot, etc.). Older soccer games used only one button. Why? Well, that's all that they had, and the action performed was dependent on how long you held the button down. Perhaps this is why the so-called “next-generation” fail to match the playability of the older titles.
Similarly, if the control system isn't intuitive, players will not enjoy playing your game. One simple reason that may happen is that they may not be able to use the keys you chose for the game; therefore, your game should allow the user to redefine the controls. Incidentally, I failed to follow this practice in Teardrop Explodes. I later discovered that it was not playable with keyboards on which the cursor keys are laid out differently than my own—a lesson learned the hard way.
Another reason for this is that the controls go against the player's expectations. For example, I recently played a game where I used a joystick to control a spaceship. I naturally expected the craft to bank when I pulled the stick left or right—wrong—instead, this action caused the craft to rotate. Needless to say, I didn't enjoy playing that game.
Arguably, this is the single most important section of any game production. The player has to be drawn into the game, and immersed in the atmosphere. There are various techniques to gain his interest, such as lighting and ambient sounds. However, it is also the most difficult area to find any guidelines, since all games differ in their level structure.
Ambient sounds can be used for such trivial things as a pipe dripping or the growls of monsters. These sounds should be used with care; otherwise you could end up swamping the player and ruining his game experience. If at all possible, they should be used only when other sounds are not being played. One way to do this is to use “trigger points” in the level, which are similar to invisible tiles that play the required sound when the cursor passes over them.
The player should be surprised once in a while. For example, how many times did you jump the last time you played Doom? There you are, cautiously stalking along a corridor, when suddenly a crowd of demons charge through a hidden door behind you—this is exactly the kind of effect you should aim to achieve.
You should also allow the player to interact with the environment. If the player sees or tries something he can't get or do, he becomes frustrated. In arcade games, this generally involves wanton destruction of the surroundings. In the case of your game, let it happen in some fashion. Even if the scenery doesn't actually change, use big explosions—big explosions always satisfy a player's thirst for destruction.
Finally, and this is the big one, play test. Play testing your level designs and game in general is very important. Things to look out for include the general “flow” of the game, difficulty levels and the balance of the control system. I talked about control systems earlier, so let's consider the other two points.
In order for a game to “flow”, all the disparate elements of your game should come together and mesh seamlessly. This is a harder objective to achieve than it sounds, so it helps to decide on a common theme for the game. You may want to come up with an intricate story line or a particular graphical style. Whatever you choose, just make sure that it remains consistent—that nothing seems out of place.
The difficulty setting of a game is, again, quite hard to balance exactly right. Obviously, the game should start easily and get progressively harder. What's the best way to go about this? Well, the most effective method I have come across is to have a fairly simple starting section fpr the game, which allows the user to experiment with the control system and use different abilities of their on-screen persona. After this, you can throw some harder game elements at them. However, don't be relentless in this action; slightly. The easiest way to do this is to have a “pause game” option. You could also have bonus levels or hidden games. The best way to judge where to use one of these lulls is, of course, to play test.
|PostgreSQL, the NoSQL Database||Jan 29, 2015|
|HPC Cluster Grant Accepting Applications!||Jan 28, 2015|
|Sharing Admin Privileges for Many Hosts Securely||Jan 28, 2015|
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
- PostgreSQL, the NoSQL Database
- Sharing Admin Privileges for Many Hosts Securely
- HPC Cluster Grant Accepting Applications!
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Designing with Linux
- Wondershaper—QOS in a Pinch
- Ideal Backups with zbackup
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Slow System? iotop Is Your Friend
- January 2015 Issue of Linux Journal: Security
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane