This chapter provides an overview of the game industry, the complexities of game development, and the personal motivations that drive members of this field to produce the games we love to play. Herein you will find discussions of game design and how your world view and upbringing, as well as individual quirks and talents, have a huge impact on not only whether you have what it takes to make it big, but also whether it is a good idea to work on games at all. There is more to writing games than motivation. While some programmers see game development purely as a monthly salary, some perceive games at a higher level and are able to tap into that mysterious realm of the unknown to create a stunning masterpiece. In this chapter, I discuss that vague and intangible (but all too important) difference.
I also give you a general overview of what it is like to work as a programmer. If you are interested in game programming purely for fun or as a hobby, I encourage you to absorb this chapter because it will help you relate to those on the inside and judge your own creations. When you consider that it takes a team to develop a retail game—while you are an individual—it is not unreasonable to believe that your own games are high in quality and worthy of note. What you must consider are total invested project hours and the size of the team. How does your solo project compare to a team game development project? You see, your solo (or rather, “indie”) game may be comparable to a retail game, all things being equal. One goal of this chapter is to help you realize this fact, to encourage you to continue learning, and to create games from your imagination. Whether you are planning a career in the game industry or simply partaking in the joy of writing games to entertain others, this chapter has something beneficial for you. After all, there are employed game programmers who only make their mark after going solo, and some solo game programmers who only make their mark after joining a team. Taking games seriously from the start is one way to attract attention and encourage others to take your work seriously.
Here is a breakdown of the major topics in this chapter:
Before I delve into the complexities of learning to write a game, I want to take a few moments to discuss the big picture that surrounds this subject. I'd like to think that some of you reading this book very likely will enter the game industry as junior or entry-level programmers and make a career of it. I am thrilled by that possibility—that I may have contributed in some small way to fulfilling a dream. I will speak frequently to both the aspiring career game programmer and the casual hobbyist because both have the same goals—first, to learn the tricks and techniques used by professional game programmers, and then to learn enough so it is no longer difficult and it becomes fun. Programming is difficult already; game programming is exponentially more difficult. But by breaking down the daunting task of writing a modern game, you can learn to divide and conquer, and finish a great game! Thus, my goal in this chapter is to provide some commentary along those lines while introducing you to the technologies used in this book—namely, the C language and the Allegro game library.
First, a disclaimer—something that I will repeat several times to nail the point home: DirectX is not game programming. DirectX is one library that is indisputably the most popular for Windows PCs. However, consoles such as the Sony PlayStation 2, Nintendo GameCube, Nintendo Game Boy Advance, and the many other handheld devices do not use DirectX or anything like it (although Xbox does use DirectX). There are dozens of DirectX reference books disguised as game programming books, but they often do little other than expose the interfaces—Direct3D, DirectInput, DirectSound, DirectMusic, and DirectPlay. Talk about getting bogged down in the details! In my opinion, DirectX is the means to an end, not an end unto itself. Learning DirectX is optional if your dream is to write console games (although I recommend learning as much as possible about every subject).
For the newcomer to game development, this misconception can be a source of consternation. Beginners can be impatient (as I have been myself, and will discuss later in this chapter). Let me summarize the situation: You want to get something going quickly and easily, and then you want to go back and learn all the deep and complicated details, right? I mean, who wants to read an 800-page programming book before they actually get to write a game?
This book focuses on the oft-misused phrase “game programming” and has no prerequisites. I don't discuss Windows or DirectX programming at all in this book. For some excellent reference books on those subjects (which I like to call logistical subjects), please refer to Appendix D, “Recommended Books and Websites.” If I may nail the point home, allow me to present a simple analogy—one that I will use as a common theme in this and other chapters. Writing a game is very similar to writing a book. There are basic tools required to write a game (such as a compiler, text editor, and graphic editor), just as there are tools required to write a book (such as a word processor, dictionary, and thesaurus). When you are planning a new project, such as a game, do you worry about electricity? As such, when you are planning a new book, would you worry about the alphabet? These things are base assumptions that we take for granted.
I take the operating system completely for granted now, and I try to abstract my computing experience as much as possible. It is a liberating experience when I am able to get the same work done regardless of the electronics or operating system on my computer. Therefore, I take those things for granted, whether I am using Windows Explorer or GNOME, Internet Explorer or Mozilla, Visual C++ or Dev-C++. This is an important concept that I encourage you to consider because the game industry is in a constant state of flux that conducts the vibrations of the entire computer industry. Stop being a fan-boy (or fan-girl) of any specific tool, and broaden your perspective.
The concept of a “new computer” is important to the general public, but to a computer industry professional, “new” is a very relative term that only lasts a few weeks or months at most. Everyone has his or her own way of dealing with constant change, and it is part of the experience of working with computers. (Those who can't handle it never last long in this industry.) Rather than seeing change as a tidal wave and trying to keep ahead of it, I often let the wave crash over my head, so to speak, and wait for the next wave. It's an intriguing experience, allowing high technology to pass you up and zoom ahead. But do you know why there is some wisdom in skipping a trend now and then? Because technology is not only in a constant state of change, but it is also in a constant state of experimentation. Not every new “improvement” is good or accepted. Remember videodiscs? (Probably not!) The movie industry had to re-think videodisc technology, in part, because the discs resembled vinyl records, which the public perceived as old technology. Now, who knows which new video format will dominate the film industry—will DVDs continue to reign, or will Sony's BlueRay or HD-DVD be the next standard?
The computer hardware industry markets heavily for the need to constantly upgrade computers. It is logical that these companies would do so because the general public really believes that everything is obsolete year by year. In fact, it is the gross inefficiency of the software that makes this so. Rather than grasping at the latest everything with a must-have belief system, why not continue to use known, stable systems and stand up to the frequent tidal waves of technology trends? What you might call progress, I like to call marketing. Games have single-handedly pushed the personal computer industry to extraordinary new heights in the past decade due for the most part to advances in graphics technology. But that cutting edge leaves a lot of well-meaning and talented folks out in the cold when they might otherwise be developing well-loved games.
So we come back to the point again: What is the cutting edge of game development, and what must I do to write great games? For the first part, the cutting edge is gameplay, not the latest 3D buzzword. Second, to write a great game, you must be passionate and talented. Studying the subject at hand (game programming) is another factor—although it is the focus of this book! For my own inspiration, I look at games such as Sid Meier's Civilization IV, among other popular titles. You can find your inspiration in whatever subject interests you, and it need not always be a video game.
One of the aspects of this book that I want to emphasize early on is that my goal is to reach a majority of hobbyists and programmers who are either aspiring to enter the game industry as career programmers or who are simply writing games for the fun of it. As I explained in the Introduction, this book won't hold your hand because there is so much information to cover. At the same time, it's my job to make a difficult subject easy to comprehend; if you have some fun along the way, that's even better. I don't want to simply present and discuss how to write 2D graphics code; my goal is for you to master it.
By the time you're finished with this book, you'll have the skills to duplicate any game released up to the late 1990s (before 3D hardware acceleration came along for PCs). That includes a huge number of games most often not regarded by the “twitch generation”—that is, those gamers who would describe “strategy” as which direction to circle strafe an enemy in a first-person shooter; the best kind of car to “jack” to make the most money; or escaping via a side alley where the cops never follow you. We can poke fun at the twitch generation because they wouldn't know what to do with a keyboard, let alone how to write game code; therefore, they are not likely to read this book. But if there are any twitch gamers now reading, I congratulate you for broadening your horizon!
Game development is far more important to society than most people realize. Strictly from an economic point of view, the design, funding, development, packaging, delivery, and sale of video games (both hardware and software) employs millions of workers around the world. There are electronics engineers building the circuit boards and microprocessors. Programmers write the operating systems, software development kits, and games. Factory workers mass-produce the packaging, instructions, discs, controllers, and other peripherals. Technical support workers help customers over the phone. There are a large number of investors, business owners, managers, lawyers, accountants, human resource workers, network and PC technical support personnel, and other ancillary job positions that support the game industry in one way or another. What it all amounts to is an extraordinarily complex system of interrelated industries and jobs, and millions of people who are employed solely to fill the shelves of your local video game store. The whole point of this is simply to entertain you. Because we're talking about high-quality interactive entertainment, we have a tendency to spend a lot of money for it, which increases demand, which drives everyone involved to work very hard to produce the next bestseller.
Although this narrative might remind you of the book publishing industry, where there are many people working very hard to get high-quality books onto store shelves, I submit that games might be more similar to motion pictures than to books. All three of these subjects are closely related forms of entertainment, with music included. Books are turned into movies, movies into video games, and both movies and video games into books. All the while, music soundtracks are available for movies and video games alike. Much of this has to do with marketing—getting the most income from a particular brand name. One excellent side effect of this is that many young people grow up surrounded by themes of popular culture that spawn their imaginations, thus producing a new generation of creative people every few years to work in these industries.
Consider the effect that science fiction novels and movies have had on visionaries of popular culture, such as Gene Roddenberry and George Lucas, who each pushed the envelope of entertainment after being inspired by fantastic stories of their time, such as The Day the Earth Stood Still and The Twilight Zone, to name just two. Before these types of programs were produced, Hollywood was enamored with westerns—stories about the old West. What was the next great frontier, at least for an American audience? Having spread across the continent of North America, and after fighting in two great and terrible world wars, popular culture turned outward—not to Earth's oceans, but to the great interstellar seas of space. What these early stories did was spur the imaginations of the young up-and-coming visionaries who created Star Trek, Lost in Space, Star Wars, and action/adventure themes such as Indiana Jones set in a past era (where time is often associated with space). These are identifiable cultural icons.
The game industry is really the next generation of entertainment, following in the footsteps of the great creative powerhouses of the past few decades. Games have been growing in depth and complexity for many years, and they have come to be so entertaining that they have eclipsed the motion picture industry as the leading form of entertainment. But just as movies did not replace books, neither will games entirely replace movies as the leading entertainment medium. Although one might eclipse the others in revenue and profit, all of these industries are interrelated and interdependent.
Thinking hypothetically, what do you suppose will be the next stage of cutting-edge entertainment, the likes of which will supersede games as the dominant player? In my opinion, we have not seen it yet and we might never see it. I believe that books, music, movies, and video games will continue unheeded to inspire, challenge, and entertain for decades to come. But I do hold an opinion that is contrary to my last statement. I believe that western society will embrace entertainment less and adopt more productive uses for games in the next decade. Why do I feel this way, you might ask? Momentum and progress. Games are already being used for more than just entertainment. They are being used by governments to train soldiers in the strategy and tactics of a modern battlefield, one in which military commanders no longer have the luxury of experiencing for real. These types of games have now been coined as serious games. Without real long-term engagements like those during World War II (wars since that time have been skirmishes in comparison), modern militaries must rely on alternative means of training to give troops a feel for real battle. What better solution than to play games that are visceral, utterly realistic, shocking in unpredictability, and awe-inspiring to behold. Who needs a real battlefield when a game looks and feels almost like the real thing (as is the case with Battlefield 2).
I have now explored several areas of our society that benefit from the game industry. What about gamers themselves—you, me, and other video game fanatics? We love to play games because it is exhilarating to conquer, pillage, destroy, and defeat an opponent (especially if he or she is a close friend or relative). But there is the converse to this point of view, regarding those games that allow you to create, imagine, build, enchant, and express yourself. Some games are so artistic that it feels as if you are interacting with an oil painting or a symphonic orchestra. To conclude this game brings forth the same set of emotions you feel upon finishing a good book, an exceptional movie, or an orchestral performance—exhilaration, joy, pride, fascination, appreciation, and yet a tinge of disappointment. However, it is that last emotion that draws you back to that book, movie, game, painting, or symphony again, where it brings you some happiness in life. This experience transcends mere entertainment; it is a joy felt by your soul, not simply a sensual experience in your mind and through your eyes and ears.
Interactivity has much to do with some of the new lingo used to describe the game industry. Although insiders won't mince words, those who are concerned with public consumption and opinion prefer to call the game industry a form of interactive or electronic entertainment. Game programming has become game development. Outlining the plot of a game has become game design. Very lengthy scripts are now written for games, and some designers will even storyboard a game. Do you begin to see similarities with the movie industry?
Storyboarding is a process in which concept artists are hired to illustrate the entire game scene by scene. This is a very expensive and time-intensive process, but it is necessary for complicated productions. Some films (or games, for that matter) are rather simple in plot: Aliens have invaded Earth, so someone must stop them! Although a storyboard might help a hack-and-slash type of game, it is often not necessary, particularly when the designer and developers are intimately familiar with the subject matter. For instance, think about a game adaptation of a novel, such as Michael Crichton's Jurassic Park. The developers of a game based on a novel do not always have the benefit of a feature film, as was the case with Jurassic Park and other movies based on Michael Crichton novels. Simply reading the book and watching the movie is probably enough to come up with a basic idea for what should happen in the game; you probably don't need to storyboard.
Why do I feel that this discussion is important? It is absolutely relevant to game development! In fact, “game programming” has become such a common phrase in video game magazines, on websites, and in books that it is often taken for granted. What I'm focusing on is the importance of perspective. There is a lot more to consider than just what to name a program variable or what video resolution to use for your next game. You need to understand the big picture, to step away from the tree to see the entire forest.
Why do you want to learn game programming? I want you to think hard about that question for a moment, because the time investment is great and the rewards are not always up to par in terms of compensation. You must love it. If you don't love absolutely everything about video games, if you don't love to argue about them, review them online, and play them obsessively, then I have some good but somewhat hard advice. Just treat video games as an enjoyable hobby, and don't worry too much about “breaking in” to the game industry or getting your game published. Really. Because that is a serious source of stress, and your goal is supposed to be to have fun with games, not get frustrated with them.
Note
For a fascinating insider narration of the video game industry's early years, I highly recommend the book Hackers by Steven Levy, which puts the early years of the game industry into perspective. For a historic ride down memory lane, be sure to read High Score! The Illustrated History of Electronic Games by Rusel DeMaria and Johnny Wilson (former editor of Computer Gaming World), a full-color book with hundreds of fascinating photos. Browsing the local bulletin board systems in the late 1980s and early 1990s to download shareware games was also a fun pastime. For an intriguing look into this era, I recommend Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture by David Kushner.
I was inspired by games such as King's Quest IV: The Perils of Rosella, Space Quest III: The Pirates of Pestulon, Police Quest, Hero's Quest: So You Want to Be a Hero?, and other extraordinarily cool adventure games produced by Sierra. There were other companies, too, such as Atari, Electronic Arts, Activision, and Origin Systems. I spent many hours playing Starflight, one of the first games that Electronic Arts published in 1985 (and one of the greatest games made at the time) and the sequel, Starflight II: Trade Routes of the Cloud Nebula, which came out in 1989.
Tip
A new game in the Starflight series is in the works! The new game continues the story at the end of the first game but on the other side of the galaxy (so in the timeline, it takes place in parallel with Starflight II). The game is being developed in C++ and Allegro, and is scheduled for release in late 2007. Unlike most fan-based games, this project has the approval and blessing of Rod McConnell, founder and owner of Binary Systems, which developed the first two games in the series. For more information, visit www.jharbour.com.
In the modern era of gaming today, a college education is invaluable. What if you grow tired of the game industry after a few years? Don't cringe; this is a very real possibility. A lot of hardcore gamers have moved on to casual gaming or given it up entirely while pursuing other careers.
Focus every effort on writing complete and polished games, however big or small, and consider every game as a potential entry on your résumé. If you want to work on games for a living, go for it full tilt and don't halfheartedly fool around about it. Be serious! Go get a job with any game studio and work your way up. On the other hand, if you want to get involved in high-caliber games, then go to college and focus heavily on your studies. Let the game industry pass you by for a short time, and when you graduate, you will be ready and equipped to get a great job. There are some really great high-tech colleges now that are offering game programming degree programs. University of Advancing Technology in Tempe, Arizona, for instance, has an Associate's, Bachelor's, and Master's degree program in game development! Take a look at http://www.uat.edu. One of the cool things about this campus is that I teach there.
Once you have made the decision to go for it, it's time to build your level of experience with real games that you create on your own. Don't assume that one of your hobby games isn't good enough for an employer to see. Most game development managers will appreciate brimming enthusiasm if you have the technical skills to do the job. Showing off your previous work and recalling the joy of working on those early games is always enjoyable for you and the interviewer. They want to see your personality, your love of games, and how you spent hundreds of hours working on a particular game, fueled by an uncontrollable drive to see it completed. Your emphasis should be on completed games. Most importantly, always be genuine.
I would go so far as to say that having a dozen shareware games (of good quality) on your résumé is better than having worked on a small part of a commercial game. Yes, suppose you did work on a retail game. That doesn't guarantee choice employment with another company. What sort of work did you do on that game—level editor, unit editor, level design, play testing? These are common tasks for entry-level programmers on a professional team where the “cool” positions (such as 3D engine and network programming) are occupied by the highly skilled programmers with proven track records who always get the job done quickly.
The best hobbies will often pay for themselves and might even earn a profit. If you have a full-time job that is otherwise fine, then you may turn the hobby of game programming into a money-making adventure. Who knows, you may release the next great indie game.
There are many factors to consider in your own determination, and there is no best direction to take in life. We all just try to do the best that we can do, day by day and year by year. I recommend that you pursue a career that will bring you the most enjoyment while still earning the highest possible salary. You might not care about salary at this point in your life; indeed, you might feel as if you would pay someone to hire you as a game programmer. I know that feeling all too well! I thought it was a strange feeling, getting paid to work on a retail game. When that game came out in stores and I saw it on the shelf, then it was an exhilarating feeling.
However, most of the world does not feel the same way that you do about video games. Very few people bother to read the credits. The feeling of exhilaration is really an internal one, not widely shared. You might already feel that this is true, given your own experience with relatives and friends who don't understand why you love games so much and why you wig out over the strangest things.
I remember the first time I discovered Will Wright's Sim City; it was in the late 1980s. It was quite an educational game, but extremely fun, too. Traveling with my parents, I would point out along the road: “Residential zone. Commercial zone. Ah ha! There's an industrial zone. Sure to be a source of pollution.” I would note traffic jams and point out where a light rail alongside the road would ease the traffic problems. The fact is, the way you feel about video games has a strong bearing on whether you will succeed when the going gets rough, when the hours are piled on, and you find yourself with no free time to actually play games anymore. All you have time to do is write code, and not even the most interesting code at that. But that spark in your eye remains, knowing that you are helping to complete this game, and it will go on your résumé as an accomplishment in life, maybe as a stepping stone in your career as a programmer.
Another argument that you might consider is the very real possibility that you could always go to college later and focus on your career now, especially if you have a lead for a job at a game company. That trend seems to be dwindling because games are now exceedingly complex projects that require highly trained and educated teams to complete them. Any self-taught programmer might have found corporate employment in the 1980s and 1990s, but the same is no longer the case with game companies. Now it has become an exceedingly competitive market. As you already know, competition causes quality to rise and costs to go down. A programmer with no college degree and little or no experience will have a very difficult time finding employment with a recognizable game company. Perhaps he can find work with one of the few hundred independent studios, but even private developers are in need of highly skilled programmers.
You might find more success by taking the indirect route to a career in game development. Many developers have gone professional after working on games in their spare time, by selling games as shareware or publishing them online. And there are as many success stories for high school graduates as there are for college graduates. As I said, every situation is unique. During this period of time, you can hone your skills, build your résumé of games (which is absolutely critical when you are applying for a job in the game industry), develop your own game engines, and so on. Even if you are interested in game programming (which is a safe bet if you are reading this book!) just as a hobby, there is always the possibility that you will come up with something innovative and you might be surprised to receive an unexpected job offer.
As far as specialization goes, there is very little difference between programming a game for console or PC—all are based on the C or C++ language. These are two distinct languages, by the way. It is out of ignorance that many refer to C and C++ interchangeably, when in fact they are very different. C is a structured language invented in the 1970s, while C++ is an object-oriented language invented in the 1980s. It is a given that you must know both of these languages (not just one or the other) because that is the assumption in this industry—you simply must know them both, without exception, and you should not need a programmer's reference for most of the standard C or C++ libraries (although there are some weird functions that are seldom used). If you are a capable programmer (from a Windows, Linux, Mac, or other background), you know C and C++, and you have some experience with a game engine or library (such as Allegro), then you should be able to make your way when working on a console, such as the PlayStation 2, Xbox, or GameCube.
The software development kits for consoles typically include libraries that you must link into your program when the program is compiled and linked to an executable file. Many game companies now produce games for all of the console systems and the PC, as well as some handheld systems (such as the Game Boy Advance). Once all of the artwork, sound effects, textures, levels, and so on have been created for a game, it is economically prudent to reuse all of those game resources for as many platforms as possible. That is why many games are released simultaneously for multiple consoles. The cost of porting a game is just a fraction of the original development cost because all of the hard coding work has been done. The game's design is already completed. Everything has been done for one platform already, so the porting team must simply adapt the existing game for a different computer system (which is essentially what a video game system is). Since all of the code is already in C or C++ (or both), the porting team must simply replace platform-specific function calls with those for the new platform.
For instance, suppose a game for the PC is being ported to Xbox 360—something that is done all the time. The Xbox 360 is very similar to a Windows PC, with a custom version of DirectX. There is no keyboard or mouse, just a controller. Porting a PC game requires some forethought because there is a lot of input code that must be converted so the game is operated from a controller. As an example, one of the most popular online PC games of all time, Counter-Strike, was ported to Xbox and features online play via the Xbox Live! network.
Tip
Microsoft has even opened up Xbox 360 development to hobbyists with the release of XNA Game Studio. The first version of XNA includes Xbox 360 examples, but not the full capability to develop Xbox 360 games yet. (At the time of this writing, you can compile XNA code only for Windows, and the Xbox 360 target will be available in early 2007 for a $99 annual fee—which gives you access to Xbox Live development servers.) For more information about XNA Game Studio, visit http://msdn.microsoft.com/directx/xna/gamestudio/.
The usual setup for a PC game includes the use of keyboard in tandem with a mouse—usually the ASDW configuration (A = left, D = right, W = forward, S = backward) while using the mouse to aim and shoot a weapon. Also, you use the Ctrl key to crouch and the spacebar to jump. If your mouse has a mouse-wheel, you can use that to scroll through your available weapons (although the usual way is with the < and > keys).
I have always found this to be a terribly geeky way to play a game. Yes, it is faster than a controller. But it's like we have been forced to use a data entry device for so long just to play games that we not only accept it, but we defend it. I've heard many elite Counter-Strike players proclaim, “I'll never switch to a controller!” The fact of the matter is, when you get used to controlling your character using dual analog sticks and dual triggers on a modern console controller (such as the Xbox Controller S, shown in Figure 1.1), it is easy to give up the old keyboard/mouse combo.
Counter-Strike was originally a Half-Life mod (or rather, expansion). To play the original Counter-Strike, you had to already own Half-Life, after which Counter-Strike was a free (but very large) download. Porting the game to Xbox must have been a major undertaking if it was truly rewritten just for the Xbox. Based on the similarity to the now-aged PC game, I would suspect that it is the same source code, but very highly modified. There are no Xbox enhancements that I can see after having played the game for several years on the PC. It is interesting to see how the developers dealt with the loss of the keyboard/mouse input system and adapted the game to work with a controller. The in-game menus use a convenient, intelligent menu system in which you use the eight-way directional pad to purchase gear at the start of each game round.
Regardless of the differences in input control and hardware, the source code for a console or a PC game is very similar, and all of it is written in C or C++ (the biggest difference is the development environment and game libraries, or SDKs). One common practice at a game studio is to fabricate a development system in which the SDK of each console is abstracted behind wrapper code, which is a term used to describe the process of wrapping an existing library of functions with your own function calls. This not only saves time, but it also makes it easier to add features and fix bugs.
According to Jupiter Research (http://www.jupiterresearch.com), the game industry continues to grow, having reached $12 billion in sales during 2003. Although console sales amount to more than PC game sales, there are many more PC gamers than console gamers, and the gap will continue to widen.
I have a theory about this apparent trend. I have seen the growth of consoles over the last five years, and I am convinced that console games will be more popular than PC games in a few years. It is just a simple matter of economics. A $200 console is as capable and as powerful as a $1,500 PC. Not too long ago I was a frenetic upgrader; I always found an excuse to spend another $500 on my PC every few months. I believe, at the time of this writing in 2006, console games are outselling PC games.
When I stopped to look at this situation objectively, I was shocked to learn that I had been spending thousands annually—on games, essentially. Not just retail games, but the hardware needed to run those games. It seemed to be a conspiracy! The hardware manufacturers and software game companies were in league to make money. Every six months or so, new games would be released that required PC upgrades just to run. One benefit that the consoles have brought to this industry is some platform stability, which makes it far easier to develop games. Not only can you (as a game programmer) count on a stable platform, but you can push the boundaries of that platform without worrying about leaving anyone with an aging computer behind. No newly released PC game will run on a computer that is five years old (in general), but that is a common practice for the average five-year lifespan of a game console.
Given this speculation and the trends and sales figures that seem to back it up, it is very likely that the PC and console game industries—which were once mostly independent of each other—will continue to grow closer every year. That is why it is important to develop a cross-platform mindset and not limit yourself to a single platform, such as Windows. Mastery of C and C++ are the most important things, while your specific platform of choice comes second. Regardless of your proficiency with Windows and DirectX, I encourage you to learn another system. The easiest way to gain experience with console development is to learn how to program the Nintendo Game Boy Advance (GBA) because open-source tools are available for it. To learn more about this, visit www.jharbour.com/gameboy.
There is a misunderstanding among many game players as well as programmers (all of whom I will simply refer to as “gamers” from this point forward) that 2D games are dead, gone, obsolete, forever replaced by 3D. I disagree with that opinion. There is still a good case for working entirely in 2D, and many popular just-released games run entirely under a 2D game engine that does not require a 3D accelerator at all. Also, numerous games that can only be described as cult classics have been released in recent years and will continue to be played for years to come. Want some examples?
Sid Meier's Civilization III with Play the World and Conquests expansions
StarCraft and the Brood War expansion
Diablo II and the Lord of Destruction expansion
Command & Conquer: Tiberian Sun and the Firestorm expansion
Command & Conquer: Red Alert 2 and Yuri's Revenge
Age of Empires and the Rise of Rome expansion
Age of Empires II and The Conquerors
Age of Mythology and The Titans expansion
The Sims and a dozen or so expansions and sequels
What do all of these games have in common? First of all, they are all bestsellers. As you might have noticed, they all have one or more expansion packs available (which is a good sign that the game is doing well). Second, these are all 2D games. This implies that these games feature a scrolling game world with a fixed point of view and various fixed and moving objects on the screen. Fixed objects might be rocks, trees, and mountains (in an outdoor setting) or doors, walls, and furniture (in an indoor setting). With a few exceptions, these are all PC games. There are several hundred console and handheld games that all feature 2D graphics to great effect that I could have listed. For instance, here are just a handful of exceptional games available for the Game Boy Advance:
Advance Wars
Advance Wars 2: Black Hole Rising
Super Mario World: Super Mario Advance 2
Yoshi's Island: Super Mario Advance 3
The Legend of Zelda: A Link to the Past
Sword of Mana
Final Fantasy Tactics Advance
Golden Sun: The Lost Age
What makes these games so compelling, so hot on the sales charts, and so popular among the fans? It is certainly not due to fancy 3D graphics with multi-layer textures and dynamic lighting, representative of the latest first-person shooters. What sets these 2D games apart are the fantastic gameplay and realistic graphics for the characters and objects in the game.
What are your hobbies, interests, and sources of entertainment (aside from your PC)? Have you considered that what interests you is also of interest to thousands or millions of other people? Why not capitalize on the fan base for a particular subject and turn that into a game? Nothing beats experience. When it comes to designing a game, there is no better source on a particular subject than a diehard fan! If you are a fan of a particular sci-fi show or movie, perhaps, then turn it into your vision of a game. Not only will you have a lot of fun, but you will create something that others will enjoy as well. I have found that when I work on a game that I enjoy playing and I create this game for my own enjoyment, there are people who are willing to pay for it.
Entirely for my own enjoyment and for nostalgia, I wrote a trivia game about one of my favorite sci-fi shows (Star Trek). The game featured 1,600 questions, 400 photos, theme-based sound effects, and a very simple multiple-choice interface (see Figure 1.2).
I decided to put the game up on my website and on a few game sites as a free download. Then I started to think about that decision for a moment. I had spent about two years working on that trivia game off and on during my free time, without setting any deadlines for myself. (Don't let the simplistic graphics and user interface fool you; it is very difficult to so fully cover a subject like this.) So I set a very low price on the game, just $12.00. The game sold 10 copies in the first week. That's $120.00 that I didn't have a week before, and for doing . . . well, nothing really, because I hadn't written that game for sale, just for fun. One month and 30 sales later, I decided to port the game to the Pocket PC platform, running Windows CE. This was about the time when my book, Pocket PC Game Programming: Using the Windows CE Game API, came out. I was fully immersed in Pocket PC programming, so it was not a difficult job. Oddly, I wrote the original PC game using Visual Basic 6.0, and then ported the game to the Pocket PC using eMbedded Visual Basic 3.0, which was very limited with support for just VBScript rather than the full Visual Basic language.
Long story short, over the next year I made enough money from this little trivia game to buy myself a new laptop. That is not enough to live on, but it occurred to me that having 10 to 15 similar games in the “trialware” (try before you buy, synonymous with shareware) market, one could make a good living from game sales. The key is to continue cranking out new games every month while existing games provide your income. To do this, you would need to hire out the artwork (a professional artist will not only do far better work than the typical programmer, but will do so very quickly). I consider artwork to be at least as important as programming. Do you see how you could make a living as a game programmer by filling in niche products? You work for yourself and report to no one. If you can produce enough games to make a living, then you will be on the heels of many giants in the business.
Another interesting game that I wrote is called Perfect Match (see Figure 1.3). It is a good example of the significant improvements you will see in the quality of your games when you collaborate with a professional artist. This game was written in about a month (again, during my spare time), and it features seven levels of play. The artwork in this game was completely modeled and rendered in 3D, and each level is a specific theme. This is another game that I personally enjoy playing, especially with such high-quality graphics (done by Edgar Ibarra).
Figure 1.3. Perfect Match is a tile matching game with high-quality rendered graphics (four screens shown).
Some “budget” game publishers produce game compilations on CD-ROM, which have a good market at superstores, such as Wal-Mart. But the trend is heading more toward online sale and download. This is a very good way to make money by selling games that aren't “big enough” for the large retail game publishers, such as Electronic Arts. Companies selling budgetware make it possible for individual (“indie”) developers to publish their games with little or no startup or publishing costs. Simply work on the games in your spare time and send them in when they're complete. Thereafter, you can expect to receive royalties on your games every month. Again, the amount of income depends on the quality and demand for each game.
In this section I want to show you a hobby project I worked on when I was just getting started. This game is meager and the graphics are terrible, but it was a labor of love that became a learning tool when I was first learning to write code. This is an unusual approach, I realize, so I hope you will bear with me. My goal is to show you that you can turn any subject or hobby into a computer game of your own design, and no matter how good or bad it turns out to be, you will have grown significantly as a programmer from the experience.
I remember my first two-player game, which took a year to complete because there were no decent game programming books available in the late 1980s (only a handful that focused on the BASIC language), and I was literally teaching myself while working on this game. I called the game Starship Battles, and it was an accurate simulation of FASA's now-defunct Tactical Starship Combat game, right down to the individual starship specifications. This was a very popular pen-and-paper role-playing game in the 1980s, and at the time I had a collection of pewter miniature starships that I hand-painted for the game. Apparently, Paramount Pictures Corporation reined in many popular licensed products in the late 1980s, which is why this game is no longer available in retail stores (although it can be found on eBay).
I wrote Starship Battles with Turbo Pascal 6.0 using 16-color EGA graphics mode 640 × 350, which explains why it looks like it is running in widescreen mode. It featured double-buffered graphics (via EGA page flipping), support for dual joysticks, and Sound Blaster effects. Figure 1.4 shows the game in action. This game was partially inspired by Star Control II, a classic favorite of mine.
Figure 1.4. Starship Battles was a game of one-on-one starship combat set in FASA's Star Trek RPG universe.
Figure 1.5 shows the player selection screen in Starship Battles. This was a simplistic front-end for the game.
This simple-looking game took me a year to develop because I had to teach myself everything, from loading and drawing sprites to moving the computer-controlled ship with simplistic artificial intelligence to providing dual joystick support. This game also made use of the Sound Blaster Developer Kit (shown in Figure 1.6), which was very exciting at the time. I was able to produce my own sound effects (in VOC format) using the included tools and play real digital sound effects in the game. For the joystick support, I had a joystick “Y” adapter and two gamepads, requiring some assembly language programming on my part to tap into the joystick driver.
Figure 1.6. The Sound Blaster Developer Kit by Creative Labs included the libraries and drivers for multiple programming languages.
The game included a starship editor program (shown in Figure 1.7) and my own artwork (as you probably already guessed). The original hex-based pen-and-paper game with cardboard pieces was the space battle module of FASA's larger Star Trek: The Role Playing Game. There were episodic add-on booklets available for this role-playing game, as well as ship recognition manuals and die-cast starship miniatures. The editor included fields for beam weapon and missile weapon types, which the game used to determine how fast a ship was able to shoot in the game, as well as how many shots could be fired at a time.
The Andor-class starship was one of my favorites because it was classified as a missile ship, able to fire eight missiles (or rather, photon torpedoes) before reloading. Some ships featured more powerful beam weapons (such as phasers or disruptor beams), which dealt great damage to the enemy ship. Figure 1.8 shows the specification sheet for the Andor, from FASA's Federation Ship Recognition Manual (shown in Figure 1.9). It is always interesting to see the inspiration for a particular game, even if that game is not worthy of note. My goal is to help you to find inspiration in your own hobbies and interests.
I spent a lot of time on this game and learned a lot from the experience, all of which had to be learned the hard way—through trial and error. First of all, I had no idea how to load a graphic file, such as the then-popular PCX format, so I started by writing my own graphic editor. I called this program Sprites; over time I wrote a 16-color version and a 256-color version. The 16-color version (shown in Figure 1.10) included limited animation support for four frames and rudimentary pixel-editing features, and was able to store multiple sprites in a data file (shown in Figure 1.11). Most importantly, I learned to program the mouse with assembly language. This sprite editor was very popular on bulletin board systems around 1990.
Figure 1.10. Sprites v2.1 was a pixel-based graphic editor that I wrote in 1990 while working on Starship Battles.
Tip
For the curious fan, the best modern implementation of FASA's tactical starship combat game is Activision's Starfleet Command series, excellent Windows PC games that have kept this sub-genre alive.
After completing Starship Battles, my plan was to convert the game to 256-color VGA mode 13h, which featured a resolution of 320 × 200 and support for double-buffering the screen inside the video buffer (which was very fast) for ultra-smooth, flicker-free animation. I came up with Sprites 3.1 (shown in Figure 1.12) with an entirely new menu-driven user interface.
Rather than finish the sprite editor (which was not compatible with the previous version and lacked support for multiple sprites) and rather than focus on a new version of the game, I stopped using the program. About that time I became frustrated with limitations in Turbo Pascal and I decided to switch to Turbo C. At the same time, I switched to using Deluxe Paint instead of my sprite editor, storing game artwork in a PCX file rather than inside a custom sprite file. This being such a huge step, I never did get around to improving Starship Battles, which suffered from its EGA roots.
Making the transition from Pascal to C was not the most difficult part; the hardest part was rethinking my entire self-taught concept of building a game. During the development of Starship Battles, I had no access to a good graphic editor, such as Deluxe Paint, so I had no idea how to rotate the sprites. Instead, I wrote small utility programs to convert a single sprite into a rotated one with 16 frames. Talk about doing things the hard way! I actually found some matrix math functions in a calculus book and used that knowledge to write a sprite rotation program that generated all of the rotated frames for each starship in the game.
Had I known about Deluxe Paint and Deluxe Animation, with features for drawing and animating sprites on-screen, I might have cried. At any rate, with new technology comes new power, so I gave up this game and moved on to another one of my hobbies—war games. Today, the modern equivalent of Deluxe Paint and Deluxe Animation is an awesome sprite editor called Pro Motion, which is available at http://www.cosmigo.com (and included on the book's CD-ROM).
I have been a fan of Milton Bradley's Axis & Allies board game for 20 years, recently getting into the expanded editions, Axis & Allies: Europe and Axis & Allies: Pacific. This game is still huge, as evidenced by websites such as http://www.axisandallies.org. After completing Starship Battles, I decided to tackle the subject of Axis & Allies using the “proper” tools that I had discovered (namely, the C language and PCX files). The result of the effort is shown in Figure 1.13. What was truly awesome about this game was not the gameplay, per se, but the time spent with friends (another factor in my belief that console games will continue to gain popularity—for all the effort, the greatest appeal of console games is taking on a friend). What some would consider fond memories, I look back on as additional inspiration.
What made Axis & Allies so much fun? Winning the game? Hardly! I rarely beat my arch-rival, Randy Smith (as a matter of fact, I beat him two times out of perhaps sixty games!). When you design your next game, come to terms with the fact that winning is not always the most important thing. Having fun should be the primary focus of your games. And when your game is irresistably fun, people will continue to play it. This is so contrary to modern game designs that focus on discrete goals; I feel that this trend coincides with the mechanical feel of the modern 3D game. Only after several years of refinement have game-play and enjoyment started to enter the equation again. Gamers don't want a whiz-bang 3D technical demo, suitable for the crowds at GDC or E3; they want to have fun.
This single screen is packed with information that I believed would be helpful to a fan of the game. For instance, simply moving the mouse over a territory on the world map displayed the territory name, country flag, production value, attack strength, defense strength, and anti-aircraft capability. In addition, the bottom-right displayed global information about the current player, including total industrial capacity, number of territories owned, and global attack and defensive capabilities. Clicking on a territory (such as Eastern USA) would bring up a unit selection dialog, in which the player could select units to move or attack (see Figure 1.14).
After moving units onto an enemy territory, the player would then engage in battle for that territory against the defending units. Figure 1.15 shows the battle screen.
Each round of a battle allowed attacker and defender a chance to fire with simulated rolls of the dice (one die for each unit, according to the board game's rules). Figure 1.16 shows the defender's counterattack.
This was the largest game I had attempted at that point, and it was difficult with the constant desire to return to Turbo Pascal, the language most familiar to me. Making strides in a new direction is difficult when it is easier to stay where you are, even if the technology is inferior. I constantly struggled with thoughts like, “It would be so much easier to use my sprite editor.” But persistence paid off and I had a working game inside of a year, along with the experience of learning C and VGA mode 13h (the then-current game industry standard). This game really pushed me to learn new things and forced me to think in new ways. After much grumbling, I accepted the new technology and never looked back, although that was a difficult step. When I look back at the enormous amount of time I spent writing the most ridiculously simple (and cheesy) games, it really helps me put things into perspective today—there are wonderful software tools (many of them free) available today for writing games.
My goal over the last few pages was not just to traverse memory lane, but to provide some personal experiences that might help explain how important motivation can be. Had I not been such a big fan of these subjects, I might have never completed the games that I have shown you here. Who cares? Touché. Whatever your opinion of reason and motivation, game development is a personal journey, not just a skill learned solely to earn money. I will admit that these games are poor examples. They were labors of love, as I mentioned, and they suffered from my lack of programming experience. I worked with themes that I enjoyed, subjects that were my hobbies, and I can't stress enough how important that is! However, I will also point out that these game examples got me a job as a game programmer back in the day.
Tip
Don't be ashamed of your work, whatever your opinion of it, because you are your own worst critic, and your work is probably better than you think. Be humble and ask the opinion of others before either praising or derailing your work.
My own personal motivations are to have fun, to delve deeper into a subject that I enjoy, to re-create an event or activity, and to learn as I go. With this motivation, I will share with you my own opinion of what makes a great game and, in later chapters, explain exactly how a game is made. Another benefit of working on a game about a subject that you love is that it will stay with you for years to come as a fond memory. For example, I've recently started working on the design for a new version of Starship Battles and it is evolving into a larger game that gives players control over large fleets of starships. I am doing this entirely for fun because this is the type of game that I would love to play! Do you think you can write a game that you will enjoy returning to again to remake after 15 years?
I want to try to find the best balance of pushing as far into advanced topics as possible in this book while still covering the basics. It is a difficult balance that doesn't always please everyone, because while some programmers need help at every step along the way, others become impatient with handholding and prefer to jump right into it and start. One of the problems with game development for the hobbyist today is the sheer volume of information on this subject, in both printed and online formats. It is very difficult to get started learning how to write games, even if your goal is just to have some fun or maybe write a game for your friends (or your own kids, if you have any). I find myself lost in the sheer magnitude of information on the overall subject of game development. It truly is staggering just looking into personal compilers, libraries, and tools, let alone the commercial stuff. If you have ever been to the Game Developers Conference, then you know what I mean. This is a huge industry, and it is very intimidating! Getting started can be difficult. But not only that, even if you have been a programmer for many years (whether you have worked on games or not), just the level and amount of information can be overwhelming.
One subject that is rather universal is DirectX. I have found that the more I talk about DirectX, the less I enjoy the subject because it is basically a building block and a tool, not an end in and of itself. Unfortunately, DirectX has been misunderstood, and many talk about DirectX as if it is game programming. If you learn the DirectX API, then you are a game programmer. Why doesn't that make sense to me? If I can drive a car, then am I suddenly qualified to be a NASCAR driver? DirectX is just a tool; it is not the end-all and be-all of game development.
In fact, there are a lot of folks who don't even like DirectX and prefer to stick with cross-platform or open-source tools, in which development is not dictated by a company with a stake in the game industry (as is the case with Microsoft and the Xbox 360, in addition to Microsoft Game Studios). The professionals use a lot of their own custom libraries, game engines, and tools, but an equal number use off-the-shelf game development tools such as RenderWare Studio (www.renderware.com). This is a very powerful system for game development teams working on multi-platform games. What this means is that a single set of source code is written and then compiled for PC, Xbox 360, PS3, and Wii (with support for any new consoles that come out in the future through add-on libraries). Have you seen any games come out for multiple platforms at the same time? (One example is LucasArts’ Secret Weapons Over Normandy.) It is a sure bet that such games were developed with RenderWare or a similar cross-platform tool. Render-Ware includes source code management and logistical control in addition to powerful game libraries that handle advanced 3D graphics, artificial intelligence, a powerful physics system, and other features. And this is but one of the many professional tools available! Another good example is Gamebryo, which was used for the development of Sid Meier's Civilization IV.
I have found that there are so many books on DirectX now that the subject really doesn't need to be tackled in every new game development book. My reasoning is logical, I think. I figure that no single volume should try to be the sole source of information on any subject, no matter how specific it is. Should every game development book also teach the underlying programming language to the reader? We must make some assumptions at some point, or else we'll end up back at square one, talking about ones and zeroes!
You should consider another very important factor while we're on the subject of content. Windows is not the only operating system in the world. It is the most common and the most dominant in the industry, but it is not the only choice or even necessarily the best choice for every person (or every computer). Why am I making a big deal about this? I use Windows most of the time, but I realize that millions of people use other operating systems, such as Linux, UNIX, BeOS, FreeBSD, Mac OS, and so on—whatever suits their needs. Why limit my discussion of game development only to Windows users and leave out all of those eager programmers who have chosen another system?
The computer industry as we know it today was founded on powerful operating systems such as UNIX, which is still a thriving and viable operating system. UNIX, Linux, and the others are not more difficult to use, necessarily; they are just different, so they require a learning curve. The vast majority of consumers use Windows, and thus most programmers got started on Windows.
I want to support systems other than Windows. Therefore, this book focuses on the C language and the Allegro multi-platform game development library (which does use DirectX on the Windows platform, while supporting many others). Allegro was originally developed by Shawn Hargreaves for the Atari ST; as a result of open-source contributions, it has evolved over time to its present state as a powerful game library with many advanced 2D and 3D features also included. The primary support website for Allegro is at http://www.talula.demon.co.uk/allegro. I highly recommend that you visit the site to get involved in the online Allegro community because Allegro is the focus of this book.
Note
We are focusing our attention on the latest version of Allegro, which, at the time of this writing, is version 4.2.
Rather than targeting Xbox 360, PS3, and Wii (which would be folly anyway because the console manufacturers will not grant licenses to unofficial developers), Allegro targets multiple operating systems for just about any computer system, including those in Table 1.1.
Table 1.1. Allegro's Compiler Support
Operating System | Compiler/Tools |
|---|---|
Mac OS X | Apple Developer Tools or XCode |
Windows | Microsoft Visual C++ 6.0 (or later) |
Windows | Borland C++ 5.5, C++Builder 3.0 (or later) |
Windows | MinGW32/Cygwin |
MS-DOS | DJGPP 2.01 with GCC 2.91 (or later) |
MS-DOS | Watcom C++ 10.6 (or later) |
IRIX | GCC 2.91 (or later) |
Linux | GCC 2.91 (or later) |
Darwin | GCC 2.91 (or later) |
FreeBSD | GCC 2.91 (or later) |
BeOS | Be Development Tools |
QNX | QNX Development Tools |
Table 1.1 presents an impressive and diverse list of operating systems, wouldn't you agree? Allegro abstracts the operating system from the source code to your game so the source code will compile on any of the supported platforms. This is very similar to the way in which OpenGL works. (OpenGL is another open-source game development library that focuses primarily on 3D.)
Allegro is not a compiler or language; rather, it is a game library that must be linked to your main C or C++ program. Not only is this practice common, it is smart. Any time you can reuse some existing source code, do so! It is foolish to reinvent the wheel when it comes to software, and yet that is exactly what many programmers do. I suspect many programmers prefer to rewrite everything out of a sense of pride or arrogance—as in, “I can do better.” Let me tell you, game development is so extraordinarily complicated that if you try to write all the code yourself without the benefit of a game library or some help from the outside world, you will quite literally never get anywhere and your hard work will never be appreciated!
Allegro features a comprehensive set of 2D and 3D graphics features.
Raster operations | Pixels, lines, rectangles, circles, Bezier splines |
Filling | Pattern and flood fill |
2D sprites | Masks, run-length encoding, compiled sprites, translucency, lighting |
Bitmaps | Blitting, rotation, scaling, clipping |
3D polygons | Wireframe, flat-shaded, gouraud-shaded, texture-mapped, z-buffered |
Scrolling | Double or triple buffers, hardware scrolling (if available) |
Animation | FLI/FLC playback |
Windows drivers | DirectX windowed and full-screen, GDI device contexts |
DOS drivers | VGA, Mode-X, SVGA, VBE/AF, FreeBE/AF |
UNIX drivers | X, DGA, fbcon, SVGAlib, VBE/AF, Mode-X, VGA |
BeOS drivers | BWindowScreen (full-screen), BDirectWindow (windowed) |
Mac OS X | CGDirectDisplay (full-screen), QuickDraw/Cocoa (windowed) |
Allegro features some excellent support for music playback and sound effects.
Note on, note off, volume, pan, pitch, bend, drum mappings | |
Digital sound | 64 channels, forward, reverse, volume, pan, pitch |
Windows drivers | WaveOut, DirectSound, Windows Sound System |
DOS drivers | Adlib, SB, SB Pro, SB16, AWE32, MPU-401, ESS AudioDrive, Ensoniq |
UNIX drivers | OSS, ESD, ALSA |
BeOS drivers | BSoundPlayer, BMidiSynth |
Mac OS X drivers | CoreAudio, Carbon Sound Manager, QuickTime Note Allocator |
Allegro also supports the following hardware and miscellaneous features.
Device input | Mouse, keyboard, joystick |
Timers | High-resolution timers, interrupts, vertical retrace |
Compression | Read/write LZSS compressed files |
Data files | Multi-object data files for storing all game resources |
Math functions | Fixed-point arithmetic, trigonometric lookup tables |
3D functions | Vector, matrix, quaternion manipulation |
Text output | Proportional fonts, UTF-8, UTF-16, Unicode |
Not only is this book focusing on a free, open-source game library in the form of Allegro, I will also use an open-source C++ compiler and IDE (Integrated Development Environment) called Dev-C++, which is shown in Figure 1.17.
Dev-C++ includes an open-source C++ compiler called GCC (GNU Compiler Collection) that is the most widely used C++ compiler in the world. I used this compiler to develop the sample programs for my Game Boy Advance book too! GCC is an excellent and efficient compiler for multiple platforms. In fact, many of the world's operating systems are compiled with GCC, including Linux. It is a sure bet that satellites in orbit around Earth have programs running on their small computers that were compiled with GCC. This is not some small niche compiler—it is a global phenomenon, so you are not limiting yourself in any way by using GCC. Most of the console games that you enjoy are compiled with GCC. In contrast, the most common Windows compilers, such as Microsoft Visual C++ and Borland C++Builder, aren't used as widely but are more popular with consumers and businesses.
This brings up yet another important point. The source code in this book will compile on almost any C++ compiler, including Visual C++, C++Builder, Borland C++, Watcom C++, GCC, CodeWarrior, and so on. Regardless of your compiler and IDE of choice, the code in this book should work fine, although you might have to create your own project files for your favorite compiler. I am formally supporting Visual C++ 2003, but have also included projects on the CD-ROM for Dev-C++ as well. All that means is that I have created the project files for you. The source code is all the same! Incidentally, Dev-C++ is also included on the CD-ROM. Due to its very small size (around 12 MB for the installer), you might find it easier to use than Visual C++ or C++Builder, which have very large installations. Dev-C++ is capable of compiling native Windows programs and supports a diverse collection of “DevPaks”—open-source libraries packaged in an easy-to-use file that Dev-C++ knows how to install.
Allegro is one such example of an existing code library, and it's just plain smart to use it rather than starting from scratch (as in learning to program Windows and DirectX). But what if you are really looking for a DirectX reference? Well, I can suggest several dozen good books on the subject that provide excellent DirectX references (see Appendix D, “Recommended Books and Websites”). The focus of this book is on practical game programming, not on providing a primer for Windows or DirectX programming (which is quite platform-specific in any event). As I have mentioned and will continue to do, I am a big fan of Windows and DirectX. However, I am also a big fan of console video game systems (such as the GameCube's Dolphin SDK), and programming a console will open your eyes to what's possible. This is especially true if you have limited yourself to writing Windows programs and you have not experienced the development possibilities on any other system. (Ironically, the Dolphin SDK uses the same compiler that Dev-C++ comes with—it's called GCC. This open-source compiler is also used for Game Boy Advance development).
Tip
All of the source code in this book is platform-agnostic, and will compile and run on any compiler that has been properly configured to build Allegro game library code. You do not need to change a single line of code in any code listing, regardless of the system you are using!
Dev-C++ is just one of the IDE/compiler tools you can use to compile the code in this book. Feel free to use any of the compilers listed back in Table 1.1. It might be possible to use older compilers, but I wouldn't recommend it. While GCC is guaranteed to work with Allegro, the same cannot be said for obsolete compilers, which very likely do not support modern library file structures.
This chapter presented an overview of game development and explained the reasoning behind the use of open-source tools such as Dev-C++ and Allegro (the primary benefit being that these tools are free, although that does not imply that they are inferior in any way). I explained how Windows and DirectX are the focus of so much that has already been written, and that this book will delve right into game programming rather than spending time on logistical things (such as tools). I hope you will embrace the way of thinking highlighted in this chapter and broaden your horizons by recognizing the potential for programming systems other than Windows. By reading this book and learning to write platform-independent code, you will be a far more flexible and versatile programmer. If you don't fully understand these concepts quite yet, the next chapter should help because you will have an opportunity to see the capabilities of Allegro by writing several complete programs.
You can find the answers to this chapter quiz in Appendix A, “Chapter Quiz Answers.”