Game Design Essentials


Now that you have some perspective on the types of video games and the viability of each from a development view, you're ready to start learning about designing games. Do you have some ideas of games you'd like to create, or are you clueless about where to begin? Regardless of which camp you're in, I'm here to help. Keep in mind that coming up with a good game idea is often the easy part; taking the concept to reality is where the difficulty arises, and where many of us fall short. As long as you take things a step at a time and don't get overwhelmed by the details, you'll do just fine.

The first step in taking a game from the drawing board to the keyboard is to get a solid idea of what you want the game to be. I'm not saying you have to create an itemized list of every scene and every creature and minute interaction. However, it is very important to establish some minimal ground rules about the big picture of what you envision for the final game. Following are the key items you should focus on when putting together the overall concept of your game:

  • Basic idea

  • Storyline

  • Graphics

  • Sound

  • Controls

  • Play modes

The next few sections explore these game design considerations in more detail.

Coming Up with the Basic Idea

The most important design step in creating a game is to determine the basic idea behind the game. Is it a shoot-em-up, a maze game, a role-playing game (RPG), a driving game, a puzzle game, or some combination of these? Or do you have a truly original game idea that doesn't neatly fit into an existing genre ? Is the object to rescue good guys, eliminate bad guys, or just explore a strange environment? What time frame is your game set in, and does it even have a time frame? These are just a few of the questions you need to ask yourself when developing the basic idea for a new game. Think about it and write everything down. Whatever comes to mind, write it down because brainstorms come and go and you don't want to forget anything. Forcing yourself to formalize your ideas and get them on paper causes you to think about it more and usually clears up a lot of uncertainties.

If you're having trouble coming up with a basic game idea, think about the influences of some of the more popular games around. Many games are based on movies, some on historical events, and others on sports; some games are so popular that there are movies based on the games (Tomb Raider, Final Fantasy, Resident Evil, and so on). Ultimately, most computer games are models of the world around us, whether fantasy or real, so look no further when dreaming up your game. Movies in particular can provide a lot of good creative settings and storylines for games ”just be careful not to " borrow " too much.

Regardless of your inspiration, just remember that your game has to be fun. No matter how fancy the graphics are or how immersive the sound, the overriding design goal of any game is always to maximize fun. Who wouldn't want to spend all day trying to figure out the best way to have fun? That, my friend, is the real allure of game programming. If your game isn't fun to play, no amount of fancy graphics, sound, or celebrity voice-overs will save it. Some of the best games of all time have weak graphics and sound by modern standards, but their fun factor has never diminished.

A good example of a painfully simple game that is surprisingly fun is the classic Atari 2600 Combat game. This game came with most Atari 2600 console systems, so most Atari gamers got a chance to try it out. Combat suffered from the severely limited technology of the time, and its graphics and sound show it. However, the game play of Combat was great, and in my opinion rivals modern games. When you think about it, the one aspect of game development that hasn't changed much over the years is the user input side of the equation. Granted, there are fancier joysticks and some new gadgety features such as force feedback, but at the end of the day it's still just an interface to your hands. This helps to explain why arcade games created in 1982 still can be quite fun even though they are technically inferior to modern games in just about every way. The creators of those games didn't have the luxury of 3D rendered graphics and CD quality sampled sound, so they went to work on the way their games played .

The point I'm trying to make is that you must make fun the priority when designing your game. After you have a basic idea of what your game will be and have decided that you're going to make it fun at all costs, you can then move on to developing a storyline.

Putting Together the Storyline

Aren't storylines just for movies and complicated cinematic games? Absolutely not. Even if your game is a simple action game with a couple of characters fighting it out, developing a storyline helps you to establish the mood and landscape, and also think up creatures to populate the game world. Putting your game in the context of a story also brings the game player closer to your world. Remember the classic Pong game mentioned at the opening of this lesson? Although it succeeded without a good story, it would have been much more interesting if it had been designed with a story in mind. Maybe the ball is an atom bouncing around in a damaged nuclear reactor, and if it goes off the screen the whole thing will melt down. It's up to you and your friend to control the "atomic deflectors" and keep the atom from escaping. Now that I think about it, maybe Pong was better off just being a blip and some lines, but you get the idea.

If you get really serious about a storyline for your game, you might want to consider creating a storyboard. Commonly used to pitch movies, a storyboard tells a story scene by scene using rough sketches of each scene. Storyboards are important visual tools because they enable you to visualize a game based on a storyline. Having a storyboard to reference helps ensure that you don't lose sight of the story when you get heavily into development. Figure 1.1 shows a simple storyboard of a popular movie you might recognize. Can you guess what it is?

Figure 1.1. Even a stick figure storyboard can convey a recognizable story.

graphics/01fig01.gif

Give up? This is my stick figure interpretation of the movie Jaws , which is probably my favorite movie of all time. As you can see in the figure, even my limited artistic abilities and love of stick figures can convey the basics of a story. Of course, a storyboard for a real game or movie would likely consist of more than four frames .

Visualizing the Graphics

My stick figure artistry is the perfect segue into the next major component of game design: graphics. Although games can certainly be fun without fancy graphics, you can significantly improve any game by the graphics you use. It's important to select a level of graphics consistent with your design goals and resources. There was a time when you also had to factor in the graphics capabilities of computers, but these days even relatively low-end computers are quite powerful enough for games of moderate to medium complexity. Even so, you may decide to stick with 256 colors for your games just to make it a little faster should it be played on an older computer. Remember, the more colors used in a game, the longer it takes the computer to manipulate and draw images in the game.

graphics/book.gif

Some amazing graphics tools are out there that make it possible to create surprisingly cool graphics without necessarily being an artist. On the other hand, if you have a friend with more artistic ability than you, it might be worth it to recruit him to help you out with your game.


Screen resolution is an important consideration for most games. If you've ever noticed your screen flickering and your monitor making a strange noise when you first start a commercial game, you're familiar with different screen resolutions ; the game is switching to a resolution different from what you were using. The most common resolution these days for Windows PCs is 800x600, which means that there are 800 pixels (colored graphical squares) across the screen and 600 down the screen. If you have a monitor larger than 15 inches, your resolution can be set much higher; mine is currently set at 1280x1024. The significance of resolution is that it directly affects the size of the graphics in games. Most commercial games are designed to run at several different resolutions, but you might not want to hassle with that for your own games. In fact, in this book I opted to stick with a fixed size for the game screen in each example game, which is an approach that works fairly well and simplifies the game graphics.

Another design decision worth considering in regard to graphics is the player's perspective of the game. Will the playfield be 2D, 3D, or some combination of the two? Will the player be able to see his character onscreen or will everything be in first person as if looking through the character's field of vision? These considerations have an enormous impact on the programming complexity of a game and therefore should be decided very early in the design phase.

Developing an Ear for the Sound

Sound is one element of games that might not seem as significant as graphics until you try playing a game without it. Seriously, just turn off the speakers while playing one of your favorite games and notice how it impacts the overall experience. On the other hand, if the game play and graphics alone are enough to make your game appealing, the sound will be the icing on the cake. It's important to use sound everywhere you can; sound effects are a bare minimum, and if you really want to do it right, you'll consider using some sort of music soundtrack.

The first thing to decide regarding sound is the quality of sounds in a game, which can dramatically impact memory requirements and overall game performance. For sound effects, you'll be dealing with sampled sounds in the form of wave (WAV) files. You must select a sampling rate, whether you want mono or stereo sound, and whether the sound uses 8 bits or 16 bits to store each sample. You learn much more about what these sound properties mean in Hour 13, "Getting Acquainted with Digital Sound and Music," but for now just understand that they directly impact both the quality and performance of sounds. For example, CD-quality sound is sampled at 44kHz in 16-bit stereo. CD-quality sound provides the best quality at the expense of a huge storage overhead; a typical music CD holds about 70 minutes and requires more than 600MB of storage space. You will more than likely settle on a lower sound quality in games to minimize storage space and improve performance.

graphics/book.gif

Sampling refers to the process of converting sound waves into a digital format that can be stored and played on a computer. You learn more about how sampling works in Hour 13.


In games, music is often handled differently from sound effects. Although it is possible to record music as a sampled sound, this can take up a lot of space. For this reason, a good alternative to sampled music is MIDI (Musical Instrument Digital Interface) music, which is the standard for arranging and playing musical compositions on computers. Unlike sampled music, MIDI music involves specifying the individual musical notes in a piece of music and associating them with virtual musical instruments. Creating a MIDI soundtrack can be difficult if you have no music background, but you might be able to find existing MIDI music to meet your needs. Fortunately, all you really need to know at this stage of a game's design is that you should consider developing programming code that can play a MIDI soundtrack.

Dictating Game Play with the Controls

The controls used to interface with the game player are an extremely important part of a game's design, and they shouldn't be taken lightly. It's important to support as many input devices (mouse, keyboard, joystick, and so on) as possible so that people with a preference for certain devices can use them. Game players use a wide variety of controls, and it's your job to decide which ones you think are worth supporting and how they will be used to control the game. It never hurts to support extra input devices.

At the very least, you can count on supporting the keyboard and mouse. You might as well plan on supporting joysticks in most games too, providing it makes sense to use a joystick in the context of the game. Beyond those three input devices, it's up to you to decide whether it's worth the extra effort to support other devices. Some input devices might not even be applicable to your game; in which case, the decision is easy. Between steering wheels, virtual reality helmets, and touch sensitive gloves, there are plenty of advanced input options if you want to go the distance in supporting input devices. And who knows what other kinds of far-out input devices are on the horizon.

graphics/book.gif

Game pads work similarly to joysticks, and therefore don't usually require any special design considerations; a game that works with a joystick will likely work with most game pads.


Deciding on the Play Modes

The last consideration to make in regard to the overall design of a game is that of play modes. Will the game be a one-player game, a two-player game, or will it be networked to allow a lot of players? If it supports multiplayer mode, is it competitive play, cooperative play, or some of both? These important decisions can dramatically impact both the fun factor and the technical difficulties of developing the game. For one thing, networking a multiplayer game presents some pretty serious technical hurdles at the programming level. I'm not trying to scare you away from networking: I just want to point out that it's a fairly advanced area of game programming.

To better understand the considerations that can go into determining play modes for a game, allow me to give you a practical example. I once developed a simple combat game called Combat Tanks that was along the lines of the old Atari 2600 Combat game. When designing the game, I initially envisioned two players fighting each other head-to-head. At the time I had no interest in adding networking support, which was very difficult to program at the time, so the players played at the same computer using keys on different sides of the keyboard to control their respective tanks. After some testing, it became apparent that a one-player mode for the game would be fun too. I mistakenly thought it would be easy to design a computer tank that could think and react like a human player. I was seriously na ve about that idea.

I learned pretty quickly that adding intelligence to computer opponents is a tricky business; all the little strategic decisions we make as humans while playing a game are very difficult to program into a mindless computer opponent. So, I figured out a workaround. Rather than have a single intelligent computer opponent , I opted for an army of stupid computer opponents. The resulting game played as a head-to-head tank game in two-player mode, and as a one-against-all shoot-em-up in one-player mode. It still turned out being quite fun as a one-player game, and I didn't have to deal with the complexities of "teaching" the computer tank how to be as crafty as a human.

graphics/book.gif

Although my tank game is now close to ten years old, it's still kind of fun in a nostalgic kind of way. If you'd like to try it out, you can download it from my Web site at http://www.michaelmorrison.com/compgames.html. I actually co-wrote Combat Tanks with my good friend Randy Weems, who I gladly credit for a great deal of my knowledge of game programming.


Please understand that I'm not advocating taking the easy way out when it comes to determining the play modes of your games, like I did. I'm only trying to make the point that there are many ways to arrive at a desired result. For me, the simplest solution ended up working out great because it allowed me to inject some interesting enemies into the game, such as foot soldiers, bombers, and helicopters. A little creativity can often go a long way toward overcoming technical hurdles.



Sams Teach Yourself Game Programming in 24 Hours
Sams Teach Yourself Game Programming in 24 Hours
ISBN: 067232461X
EAN: 2147483647
Year: 2002
Pages: 271

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net