If you’re an avid game player, you might already know the answer to this question, but it’s worth asking anyway: Why are video games so popular? And why are so many people interested in learning how to create their own? I think it has something to do with the allure of creating a little world all your own, where the limits are only your technical skills and your imagination. The goal of this book is to strengthen one while sparking the other.

To better understand why so many people gravitate toward video games, consider how popular movies are in modern cultures. Few of us are able to watch a great movie without at some point envisioning ourselves right there taking part in a scene. Video games enable us to step beyond the role of an audience member and become a participant in an interactive story. Essentially, all video games enable you to step into a world and take part in it, even if that world consists solely of an outer space background and a few aliens. When walking through a video game arcade, it’s as if each screen is a window into another reality just begging you to come inside and see what’s going on.

Enough of the dreamy talk—what do video games mean to the would-be game programmer? From a development perspective, video games are quite interesting in that they require such a wide range of talents. Video games provide us with all the usual technical challenges associated with software development, usually more, along with illustration, animation, sound effects, and music. And that doesn’t even touch on the story aspect of games—where entire screenplays are often developed. By developing a video game from start to finish, you’ll practically become a modern renaissance person, acquiring some degree of expertise in many disciplines. You’ll also successfully merge many divergent interests into a greater medium enjoyable by others. It’s for this reason that so many of us are intrigued by the endless possibilities associated with video game design and development.

Speaking of creating your own games, you might be wondering why I keep referring to “video games” when the games created in this book are played on a computer. Although I hate to split hairs over terminology, it’s worth pointing out that a video game is an interactive electronic entertainment medium that uses a video screen as its primary display. In other words, the term video game applies to all games with a screen and a joystick or some other controller. Contrast this with a traditional pinball machine, for example, which can certainly be played but doesn’t rely on a video screen for output. Video games can be further classified into three categories: arcade games, console games, and computer games.

Arcade games are video games that are built into hefty cabinets with payment mechanisms that require you to pay in order to play the games. Arcade games represent the birth of video games, and are responsible for separating quite a few 80s American youth from their hard-earned (or hard-begged) quarters. Arcade games often rely on custom hardware components and unique physical controls to separate them from other types of video games. Although arcade games certainly still exist, they are a minor component of the video game market, and aren’t the bastion of innovation they once were. Don’t get me wrong, there are some really cool new arcade games out there, but you have to look beyond arcade games to get to the really active portion of the video game market.

Console games followed quickly on the coattails of arcade games, and they represent home gaming systems from the classic Pong and Atari 2600 systems to today’s Sony Playstation 2 and Microsoft XBox. Console game systems are designed from the ground up as consumer game machines and rival arcade games in terms of game quality. We are currently in the midst of a convergence of digital entertainment technologies that is quite capable of placing console games at the center of the home entertainment equation. In fact, Microsoft already has long range plans for its XBox console game system to become an all-encompassing digital entertainment device. The next few years should be interesting in terms of seeing how console games merge with traditional entertainment equipment.

Computer games were last to the video game show simply because it took longer for personal computers to become technically capable of doing enough interesting things with graphics and sound to make good games possible. Computer games now represent a massive segment of the video game industry and rival console games in terms of popularity and sales. Interestingly enough, most popular games are now available in both console and computer versions, so you have the option of deciding whether to use a computer or a dedicated console gaming system to play games. The XBox console system is somewhat unique among console systems in that it shares a software game development platform with computer games. I’m referring to DirectX, which is Microsoft’s game development toolkit that originated on PCs, and now carries over to the XBox.

Note

Unfortunately, this book doesn’t cover game programming using the DirectX game development toolkit. The reason for this is because DirectX is a complex technology with a steep learning curve. Rather than spend half the book on the basics of how DirectX works, I decided to spend the entire book teaching you how games work. If, after reading this book, you decide to move forward and learn DirectX, I highly recommend Clayton Walnum’s Teach Yourself Game Programming with DirectX in 21 Days.

I want to clarify the different types of video games because there is a great deal of difference in developing each type. For example, arcade games rely on specialized hardware and proprietary development tools that are expensive and difficult to obtain for a startup game programmer. Console games run a close second in terms of presenting a significant barrier to entry for new game programmers. Not only are the tools expensive and difficult to get your hands on, but also they often require a very specialized set of programming skills that are usually learned on the job while working for a game company. Computer games are really the only type of video games that are accessible to the individual from a development perspective. Tools for computer game programming are readily available and are either free or relatively inexpensive. Not only that, but you can leverage existing knowledge in a mainstream programming language such as C++ to develop computer games. This book focuses on the development of computer games using C++, although most of the concepts and techniques also apply to arcade and console games.

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.

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.

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.

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.

Note

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 800×600, 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 1280×1024. 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.

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.

Note

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.

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.

Note

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.

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.

Note

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.

The idea behind OOP is to make programming more akin to the way people think, as compared to the way computers think. People tend to think in terms of meaningful things (objects). As an example, if you were to describe a hockey game, you might talk about the rink, the players, the nets, and the puck. From a computer’s perspective, a computer hockey game is no different from any other program—it’s just a bunch of ones and zeros. Programming languages free programmers from having to think in terms of ones and zeros. OOP languages take things a step further by allowing you to think in terms of objects.

Classes of objects are an important part of OOP. A class is a category of objects. Another way to say this is that an object is an instance of a class. If you were creating a computer hockey game, you might create a single hockey player class; the actual players in the game are instances of this class. Figure 1.2 shows how the hockey player objects are related to the single player class.

Figure 1.2. Several hockey player objects can be created from a single player class.

The figure reveals how several objects are created from a single class, which serves as a template for the objects. Using a food analogy instead of hockey, you can think of the class as a cookie cutter and the objects as the cookies. Another important feature of classes is that they allow you to create subclasses, which add to the properties and features in a class to make it more specific. A subclass inherits the properties and features from its parent class, and then adds some of its own. In this way, a subclass is similar to a human child in that it inherits traits from its parent, but also has its own new traits.

In order to understand the benefits that OOP offers in terms of game development, it’s helpful to think of a game as a type of abstract simulation. If you think about most of the games you’ve seen or played, it’s almost impossible to think of one that doesn’t simulate something. All the adventure games and sports games are clearly simulations, and even the most far-out space games are modeling objects that exist in some kind of virtual world. Knowing that games are models of worlds, you can make the connection that most of the things in games (landscapes, creatures, and so on) correspond to things in these worlds. And once you can resolve a game into a collection of “things,” you can apply OOP techniques to the design. This is possible because things can easily be translated into objects in an OOP environment.

To better understand what I’m talking about, consider the OOP design of a simple fantasy adventure game. The object representing the world for this game might contain information such as its map and images that represent the visualization of the map, as well as time and weather. All other objects in the game would include positional information that describes where in the world they are located. This positional information could be a simple XY value that pinpoints the object’s location on the world map.

The object for the main character in the game would include information such as life points and any items picked up during the game (weapons, lanterns, keys, and so on). The game itself would interact with the character object by telling it to move in different directions based on user input. The items carried by the character would also be created as objects. For example, the lantern object would probably keep track of how much fuel is left in the lantern, and whether it is on or off. Interactions with the lantern would simply include turning it on or off; the lantern object would be smart enough to reduce its fuel supply when the lantern is turned on.

Creatures in the game could all be based on a single creature class that describes general characteristics shared by all creatures such as life points, aggression, and how much damage they inflict when fighting. Specific creature objects would then be created and turned loose in the virtual world. The creature objects and the main character object could all be subclassed from the same organism object. Unlike the character object, which is driven by user interactions, the creature objects would be controlled by some type of intelligence programmed into the game. For example, more aggressive creatures might always chase after the main character when they are on the screen together, whereas passive creatures might have a tendency to hide and avoid contact. You could create creature subclasses that enhance the basic creature with unique capabilities such as the ability to fly, swim, or breathe fire. Figure 1.3 shows how the different classes in this hypothetical adventure game might be organized.

Figure 1.3. Classes in a hypothetical adventure game are built on one another to establish a virtual world of objects.

Don’t forget that classes are templates for objects, which means that the classes shown in the figure are designed as a blueprint for creating objects in the game. However, it’s not until you actually create the objects themselves that they are able to exist in the virtual world and interact with one another. Again, the class is the cookie cutter, and the object is the cookie. So, the development of a game using OOP first involves designing classes for the various “things” in the game, and then creating objects using those classes.

The beauty of the OOP approach to game development is that the game more or less runs itself once everything is in place. In other words, each object is responsible for handling its own business, so the game doesn’t have to concern itself too much with what each object is doing; the game is just providing a framework for the objects to exist in. This framework primarily consists of a game screen for the objects to be drawn on, and an update loop that tells the objects some time has passed. For creatures, this update would entail determining the direction to move in and whether they should attack or run. For the main character, an update involves performing an action based on user input. The main point I’m trying to make is that objects are independent entities that basically know how to take care of themselves.

A more practical benefit of OOP design in games has to do with reusing code. Let’s say that you’ve completed your fantasy adventure game we just talked about and would like to create a similar game set in outer space. Instead of starting over from scratch, you could take the objects you developed for the first game and reuse them in the new game. Granted, some changes would be in order, but many of the changes could be made by creating new subclasses, as opposed to rewriting the originals. Code reuse is certainly one of the most dramatic benefits to using an OOP approach to game development .

Regardless of what programming language you’re using to develop games, you will likely need a compiler to turn the programming code into an executable game application. Because this book focuses on using C++ as the programming language for creating games for Windows, you’ll need a C++ compiler that is capable of creating Windows applications. C++ compilers range from high-powered commercial development environments such as Microsoft Visual C++ and Borland C++Builder to free compilers such as DJGPP. Appendix B, “Selecting a Game Development Tool,” provides more details on selecting a compiler for game development. The example games presented throughout the book can be compiled using any of these compilers .

Similar to compilers, graphics tools range from high-end commercial tools to tools that you can download free; you can also use graphics tools built into Windows such as Paint. If you decide to draw your graphics by hand, you will need to scan in the artwork and clean it up in a special tool. Of course, you’ll need a scanner to scan in artwork, but those are fortunately very affordable. Even if you don’t plan on drawing game graphics by hand, you’ll need an image editing program, or paint program, as they are often called. Paint is the standard image editor built into Windows, which is surprisingly useful for creating and editing basic game images. At the other end of the spectrum are tools such as Adobe Photoshop, which are used by graphics professionals to perform extremely powerful special effects on images.

You learned earlier in the lesson that sound effects used in games are typically sampled, which means that you record them using a microphone or maybe from an audio CD. The sound card on your computer likely already has a line-in port and a microphone port, both of which can be used to sample sounds. You can use the built-in Sound Recorder application in Windows to sample sounds, or you can invest in a fancier commercial tool such as Cool Edit Pro. Either way, the process is very straightforward: just hook up the sound source (microphone, CD player, and so on) and start recording using the sound editing software. You’ll need to perform some cleanup on the sound after recording, such as removing extra noises that appear before and after the sound.

In addition to sampled sound effects, you might want to experiment with creating your own MIDI music. To do so, you must use another special tool known as a MIDI authoring tool. This kind of tool is different from a sound editor in that it is designed so that you enter musical compositions similar to what you see on a sheet of written music. You then assign instruments to different notes as if a band was playing the tune. A more intuitive approach to using a MIDI authoring tool is to connect a MIDI music keyboard to your computer and play the music on it. If your sound card has a MIDI port, and most of them do, the music you play will be recorded by the MIDI software and saved. You can then further arrange the music and alter the way it sounds .