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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Client-Side Performance
- Tibbo Technology's Tibbo Project System
- Sony Settles in Linux Battle
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- The Giant Zero, Part 0.x
- Profiles and RC Files
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide