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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- RSS Feeds
- New Products
- All the articles you talked
32 min 34 sec ago
- All the articles you talked
35 min 41 sec ago
- All the articles you talked
37 min 1 sec ago
5 hours 1 min ago
- Keeping track of IP address
6 hours 52 min ago
- Roll your own dynamic dns
12 hours 6 min ago
- Please correct the URL for Salt Stack's web site
15 hours 17 min ago
- Android is Linux -- why no better inter-operation
17 hours 32 min ago
- Connecting Android device to desktop Linux via USB
18 hours 1 min ago
- Find new cell phone and tablet pc
18 hours 59 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?