• Creating Side Scrollers
• Tools of the Trade
  • Overview of the Game Editor Code
  • Overview of the Game Engine Code
• A Labor of Love
• The Ten Steps to Development Success
• Notes about Working with Other People
  • Keeping Secrets
• The Zen of Game Development
• Next Chapter

As you read this book, keep in mind the successful game developer must wear many hats and perform many jobs. Besides writing awesome code, you must also be good at collecting (and often modifying) artwork and music. You must be able to design levels and transition screens. You need to write a captivating storyline. You need to thoroughly test your game, not just for bugs but for playability. And you need to have a marketing plan. Incorporating all these elements into the game is a challenge, especially if you've never done it before. Sometimes you can get help--you may hire someone to compose your music or draw your sprites, for example. But to successfully bring a product to market, you must understand and be involved in all the aspects of game design.

Creating Side Scrollers

From a programming standpoint, there are two parts to the game development process. The first, and most obvious part, is writing the code for the game. Most of us start there--we dive in and try to get some kind of prototype of the game up and running right away. This strategy works great for some kinds of games, but when it comes to side scrollers, we soon discover many things slow us down. We need the artwork before we can write the animation code. Then once we get the artwork, we must organize it in a format that can be used by the game. Organizing the artwork is a tedious process--backgrounds must be reduced to tiles, sprites must be stored in binary files, palettes in one picture must match those in another picture. By the time we get that organized, weeks have passed and we still haven't built the game prototype yet. About this time we realize we have approached the problem wrong-- instead of starting with the game, we should have started with the development tools.

A suite of efficient development tools is an essential element in developing side scroller games. Your work will be greatly simplified if you have tools to do the repetitive tasks of processing artwork for you. The better you become at finding or writing development tools, the better and faster you'll be at developing games. Because I believe the development tools are so important to the game development process, I am going to spend a lot of time discussing them in the next few chapters.

This book is organized so that the tools come first, then the game code. But in my experience, things don't usually work that way. In real life, I find that games and tools tend to be developed simultaneously. Sometimes you will not discover you need a particular tool until you are well into writing your game. When that happens, you need to stop working on the game and write the necessary tool. A professional game developer will be adept at creating tools, and will be able to hack out a simple utility in no time flat. The tools presented in this book will get you off to a good start, and you should be able to use the ideas presented here to build more tools.

The Tools of the Trade

The successful game developer must also be a toolsmith. While some tools can be bought "off the shelf," the tools we're going to need most are not available in any commercial package. Therefore, we will have to build them as we need them. If this task sounds daunting, it is. However, I will give you plenty of code to get you started. Most of this code is incorporated into one program, which I call the Fastgraph Game Editor, or FGE.EXE. We will examine both how to use the game editor and how the editor is constructed. An overview of the game editor code is preented in the next section.

Overview of the Game Editor Code

The Fastgraph Game Editor consists of five components:

• File Manager
• Level Editor
• Tile Editor
• Tile Ripper
• Sprite Editor

Table 2.1: The Source Files Used in the Game Editor

< Note: Download fge.zip and fgesrce.zip from the downloads page. Diana. >

• Tommy's Tips: Compiling and Linking the Game Editor

  If you make any changes to any of these files, you'll need to recompile and link the files. In general, to rebuild the program FGE.EXE, all you need to do is compile all the C files, and link them together. You will need to link with the Fastgraph large model library, which is called FGL.LIB (or the Fastgraph/Light large model library which is called FGLL.LIB). To simplify the process I have included batch files on the disk to use with current versions of the following compilers:

  • Borland C++
  • Turbo C/C++
  • Microsoft C/C+
  • Microsoft Visual C++

  Run the batch files to compile and link all the source code. If you prefer, you can create project files and make files as appropriate. See the release notes on the disk for more information.

Overview of the Game Code

The game engine has two parts, the game editor, and a template for the game. Our game template is called Tommy's Adventures. The source code files for Tommy's Adventures are listed in Table 2.2.

Table 2.2: The Source Files Used in the Game Engine

< Note: Download tomsrce.zip from the downloads page. Diana. >

Notice there is one assembly language file included in the Tommy's Adventures source code. This is the timer code, which will speed up your system's clock. You can use any DOS assembler, such as MASM or TASM, to assemble this file, or in case you don't have an assembler, I have included the .OBJ file on the disk. Just link in the TIMER.OBJ file with the other object files when you rebuild the TOMMY.EXE program.

Also, notice that ACTION.C is not compiled by itself, but is included as part of TOMMY.C, using the #include preprocessor directive. Briefly, this is done because we need to address the action functions as integer pointers, so they must reside in the same code segment as the functions that call them. We will discuss this in detail in Chapters 12 and 13.

As with the game editor, batch files for compiling and linking the game are included on the disk, and instructions for using the different compilers are in the release notes.

A Labor of Love

What is the profile of a typical game developer? You must be dedicated, diligent, determined, and just slightly deranged. And hopefully your only motivation isn't to make a lot of money writing best-selling games. Game programming is a crazy field that takes a lot of creative energy and a desire to push the boundaries of traditional software development. It takes a sort of crazy genius to be successful at writing games, and if you don't start out that way, be warned, it's the way you are likely to end up.

If I haven't scared you off with that last paragraph, read on, and enter the marvelous world of side-scroller game development.

The Ten Steps to Development Success

So you probably now have a few ideas of your own and you're anxious to start writing your own side scroller. Maybe you've even sketched out a few levels or sprites on a napkin. But before you start writing code for your game, you'll want to make sure that you have a good master plan for the complete development process. Here is my top ten list, which should help to put you on the right track.

1. Make sure you have a good story.
As we learned in the previous chapter, side scrollers work best when they are designed around a great story. If you are not a great story writer, get together with someone who is. If you have a good story, your levels and sprites will fall out naturally. The plot in the story will help keep the game focused and heighten the player's interest. Let's explore an example.

One of my favorite games is Karen Crowther's Math Rescue. If you remember from the previous chapter, this is a kid's game that involves searching for numbers and then answering math problems. For this game, Karen came up with the following clever story to start out the game:

Figure 2.1: The story introduced in the Math Rescue game.

2. Plan out your levels in advance.

Once you have a good story in mind, start to plan out your levels. The levels should expand and enhance the storyline. You will want to have many levels in your game, perhaps between 10 and 30. These levels should somehow fit together and make sense in the context of the story. If Tommy suddenly warps from an Egyptian pyramid to a spaceship, you need to explain why. The explanation should be fairly simple--the pyramid was built by aliens, for example, or Tommy's dad has built a time travel machine. Remember, game players don't want to read a story, they want to act it out. Let the story unfold naturally as the levels progress.

You also need to think in terms of finding a creative balance between level variety and conserving artwork and disk space. If you have very elaborate levels, you will need to have fewer of them (unless you are writing a CD-ROM game, in which you will have plenty of room for anything and everything). One way to conserve level space is to use the same tile library for more than one level. You can have two Egyptian levels for Tommy, for example, one inside a pyramid and the other inside a sphinx. Tommy encounters different sprite enemies on each level, and a must find a different path out, so the levels are unique and challenging, but the background art looks about the same.

3. Spend as much time as possible on your main character (sprite).

You want to develop a main character sprite your players can identify with. They will be spending a lot of time with this character as they move him around the levels and try to keep him alive. Developing this character is more difficult than you might think. If you work with an artist, you will need to describe the character to him, in terms of his age, sex, hair style, facial characteristics, clothes, and personality. Your artist will probably give you back a character that looks nothing like you imagined him. At this point, you may need to modify the character yourself. Use a paint program or sprite editor to give your character the right look. Then give it back to your artist and let him touch it up. This process may require several iterations to get it just right. Once you have achieved the desired look for your main character, you will need all the different sprite positions for him--the running frames, jumping frames, shooting frames and so on. It will take your artist a while to get this work done, so you better begin the sprite development process early in the game development cycle.

In some games, you may want to give the player the choice of selecting from a few different characters. Kids especially like to have different options. For example, the Math Rescue game allows you to choose between a boy or girl character. You can handle this by providing a character selection screen as shown in Figure 2.2.

Figure 2.2: Selecting a character in the Math Rescue game.

4. Don't skimp on the supporting cast.

Although the main character can make or break your game, the other characters are important also. Design enemies that are not only scary looking, but responsive. If possible, give them artificial intelligence--have them follow you, for example, or duck when you shoot at them . Also, put some creativity into killing enemies. In Commander Keen: Goodbye Galaxy, there are small dangerous bats that swarm around your head and occasionally land on the path in front of you. The only way to kill them is to squash them with your pogo stick. This action is not obvious, it takes a while to figure it out. (And I still haven't figured out how to get away from the giant fish!) Enemy sprites are a bit easier to develop than the main character sprite, because they require fewer sprite frames (perhaps only three or four) and because they are not required to have the emotional impact of the main character. Usually it is a good idea to give your artist some creative license when working with the enemy sprites. Let him draw several different enemies, and choose the ones you like best.

5. Plan keyboard control carefully.

Too many keystrokes will confuse your players. There should be one key to shoot, another one to jump, and possibly one more to kick or throw a punch. In addition to these designations, you should use the arrow keys to move your character around, the Esc key to provide a quick exit from the game, and the F1 key to access online help. That's about it. Do not expect the player to remember more keys than that. Requiring a player to press a combination of two or more keys to accomplish a simple task is a recipe for disaster. Keep your keyboard interface as simple as possible.

6. Find unique solutions to common problems.

Game designers use visual devices to represent certain events. The problem is, gamers use the same devices over and over. A successful game will incorporate new ideas for solving common problems. Examples of some common problems are:

* The Key/Door Problem--Exiting from a level involves finding a door (location on the level) and a key (device or event required before the door can be opened). In Word Rescue, the player is awarded a key when he finds all the words, and then must proceed to a door. That solution is so common it has become clich�. In Goodbye Galaxy, the key is replaced by a crystal, which is also a very common device. In other games, the key may be rescuing a scientist or defeating a boss enemy. Since most levels require unlocking some kind of door to exit, we need to find some new metaphorical keys. Use your imagination, but please, come up with something new.

* The Longevity Problem--Main characters have a finite amount of energy.The energy level goes up and down, depending on what hazards are encountered and what rewards are achieved. Often you will see some kind of visual health meter that graphically displays the amount of energy a character has left. When the character finds food (usually the same old hamburger and soda pop), the energy goes up. When he touches an enemy, the energy goes down. Can we come up with a new metaphor? In real life, people do not walk around with an energy meter that flows up and down. This device is so common (it is even in our Tommy's Adventures game) yet so completely nonsensical, it seems like we should be able come up with something a bit more original. An example of an uncommon energy device is the lamp in the popular Aladdin game. As Aladdin's energy goes down, the smoke wafting out of the lamp decreases. To make his energy go back up, Aladdin finds blue hearts. This is still nonsensical solution, but at least a little different.

7. Add some surprises.

Did you know you can make Commander Keen drop his pants in the Pyramid of the Moons? (You didn't hear that from me.) Players love stuff like that. When they play your game, they want to see things they have never seen before. Unusual enemies, hidden clues, secret rooms, special effects, humorous segues, and puzzles with non-obvious solutions are the special touches that will set your game apart from the rest. When it comes to game design, don't be afraid to try something new..

8. Conserve everything.

I will be stressing this point throughout this book. Plan on conserving disk space, RAM, video memory, code, array space, stack space, machine cycles, artwork, and everything else. If there are two solutions to a problem, choose the one that is less resource intensive. If you can reuse array space, do so. Similarly, reuse artwork whenever possible. Modern games can quickly become unwieldy, and the professional game developer will use every trick under the sun to keep things under control.

9. Don't take shortcuts with the beta test cycle.

Beta testers, also known as play testers, are an essential part of the game development process. Recruit and reward competent beta testers. One of the best rewards you can give a beta tester is to take his suggestions seriously.

10. Set time aside for the finishing touches. Okay your game is done; everything works and the art looks great so you're ready to unleash it on the world. Stop right there. You still have work to do if you want to create a truly great game. Don't think of your game in terms of a program, think of it as a product. As I mentioned earlier, there is more to the game than just the code. Be sure you have all the elements of a complete product before you release your game. Don't skimp on documentation. Animate your transition screens. Use an attractive font. Pay attention to the details, and give your game a polished, professional look. I will give you more tips for finishing your game in Chapter 17.

Notes about Working with Other People

If you try to create a game completely by yourself, you might be limiting your chances for success. Most developers I know work in teams or they contract out part of their development tasks. For example, a developer might hire another programmer to write development tools, or two programmers may work together as partners to develop a game, each bringing with him some unique skills that make the game better than either one of them could do alone. This speeds up the development process, and also usually results in a better product. There are some potential pitfalls, though. Be careful about choosing a partner to work with, and make sure the responsibilities and rewards of each partner are understood in advance. I have seen partnerships break up after both partners have invested heavily in developing a game. Try to foresee problems and protect yourself.

I have also seen successful teams that consist of one programmer and one non- programmer. The non-programmer may do the creative work of level design, artwork, packaging, marketing, and user support. Sometimes husbands and wives form this kind of a team, and it works out well. Be careful of forming a team where one person does all the development work and the other person is in charge of only "marketing". In my experience, such teams tend to be unbalanced. If you are capable of developing a really good game, you can always find someone to help you market it, but you do not need to make that person a full partner in your business. If you explore your options, you will probably find a more cost effective way of getting the marketing done. As your company grows, you may decide to hire a marketing person, but that decision should be made carefully.

Keeping Secrets

Some developers are very secretive about what they do. They'll share information with each other, but only after certain dues have been paid. For example, if you've proven yourself worthy by releasing a game, then others will give you inside information. This information is not to be released to outsiders, however. To do so would risk saturating the market with low-end games, and diluting the value of any individual game.

Non-disclosure agreements (NDAs) are standard among gamers. In some circles, it's considered standard operating proceedure to exchange NDAs before talking about anything. For example, before I let you see my new game, you must sign a paper that says you'll never tell anybody what you've seen. Similarly, if you give me a glimpse at your source code, I'll also sign an NDA for you. Only then will we whisper our secrets to each other, making sure nobody else is within earshot. The only way we'll find out about a competitor's technology is by espionage; and once we get it, we won't give it to anybody else. So even as the insider pool of knowledge increases, we discourage newcomers from entering the field. We protect our interests that way.

Must it always be like that? No, not really, and the gaming arena is starting to change. Despite the best efforts of the pioneers, new game programmers have entered the playing field. This new generation approaches the market differently. They are not as tight-lipped as their predecessors. They are less concerned with protecting the marketplace, and more concerned with furthering the technology. As the market has evolved, more programmers are beginning to discuss their methods in public forums. As a result, the market has expanded, and so has the number of titles available. A few development houses have released the top-selling titles, and hundreds of other developers have released less popular but still marketable games. The market has become flooded with titles, but it's turned out to be not such a bad thing. There are games available to suit almost any player's preferences. Every niche of the market is receiving coverage. The game market is expanding to fill every nook and cranny, and the players are emerging as the big winners.

There is still, however, some information that is not easy to get access to. While game programmers are less hesitant about sharing their information than they used to be, they are just as busy as ever. Not many game programmers worth their salt are writing books about game programming, because they're too busy programming games. You can find out how a game programmer does it by asking him questions on CompuServe or other networks, and he may tell you, but he'll be too busy to tell you in any detail. To really explain how to write a game, it takes a whole book--like this one, for example.

The Zen of Game Development

When I was first approached with the idea of writing a game programming book, my editor, Jeff Duntemann, suggested that I write a book for his popular Zen series-- something like Zen of Game Programming. I don't think of myself as a Zen Master or a "Zen Mistress" for that matter, so the idea didn't really grab me. Actually, I'm not sure what a Zen Master is. My impression of a little old man who spends his life pondering the meaning of the sound of one hand clapping is probably not very accurate.

I think the idea behind "Zen programming" is that we programmers tend to develop a philosophy for writing software, and we train ourselves to think in ways that improve the development process. Game developers, especially, need to develop good habits, and need to understand why they write games the way they do. Some of these habits are inherent. Some game programmers are even born with them. Other habits are a bit more subtle. So here are some of my thoughts on the Zen of game development:

To begin with, game development should focus on beauty, speed, and functionality, but not necessarily all of those things at the same time. You need to know when to optimize, when to beautify, and when to hack out code in a hurry.

Allocate your time wisely. If it takes you a week to write a utility that shaves a month off your development cycle, then that's a good investment of your development time. If you spend a month optimizing and beautifying that utility, then it's a waste of time.

Write reusable code. Volumes can be written on this subject, but I think most programmers need to develop a feel for how to design reusable code. In general, write modular code. Don't mix general-purpose code with code that is specific to the current project. Plan on being able to use the general-purpose code again. Also, be careful about hard-coding values in your code. It may be smarter to declare and initialize a variable or define a term that can be easily changed later.

Think of creative ways to make the computer work for you. Any time you find yourself doing a repetitive task, such as editing artwork, ask yourself, "Could I write a program to automate this task?"

Know when to use other people's code. Sometimes writing code from scratch will actually take less time than deciphering somebody else's code. Third party libraries can be useful, but only if properly used. A low-level library such as Fastgraph will shave months off your development cycle. A GUI or string-handling library may be helpful under some circumstances, but in general you should get in the habit of writing most of your high-level code yourself. If you depend too much on third arty libraries, you'll be limited by the functionality of those libraries, and you may not be able to achieve all the special effects you want.

Don't reinvent the wheel. There are only so many ways to write a good set of fast bitmap display routines. If you spend six months optimizing your bitmap function, that's six months you have not spent writing your game. Try to find the proper mix of third party code and your own code to speed up the development cycle without limiting your development options.

Develop good coding habits. Develop a coding style where lines of code are indented consistently. This will make debugging easier. Use comments liberally. Organize and alphabetize your functions. Use header files where appropriate. Pretend that someone like me is going to look at your code. If you give me sloppy code to look at, I can be very critical. I much prefer to look at clean code.

Start small. The first game you write should not be your most ambitious. I don't recommend that people invest two years in their first game. Invest a few months in a less ambitious project, and release it through shareware or low-cost retail channels. Release several simple games before you embark on your masterpiece. Everybody makes mistakes on their path to game development success; you want to make your mistakes on the small investment projects. Once you have a feel for the market, for your tools, and your skills and abilities, you'll be more likely to be successful with your next game.

Know where you're going, but be aware that there are multiple paths to get there. Expect your finished product to look somewhat different than your original design. Don't over-design your product, just give yourself general guidelines and then allow room for inspiration as the project progresses. A lot of game programming is done by trial and error. What looks good on paper may not feel right once implemented. Play your game, and let others play your game, and pay attention to their feedback. If a certain part of your game doesn't feel right, abandon it and try something else.

Don't waste time in the design process. Some code requires design documents, but sometimes design documents are a waste of time. Know the difference.

Interact with other game programmers. Nobody functions well in a vacuum. Online forums dedicated to the subject of game development are abundant. Find one you're comfortable with, and then discuss your game and any problems you may be having. Don't be afraid to help other game developers. Don't think of the other developers as your competitors, think of them as your colleagues. Furthering the industry by sharing information benefits everyone. As I said earlier, open communication is the whole premise of this book.

Writing the last 10 percent of a game takes approximately the same amount of time to complete as the first 90 percent. I don't know why, but I've seen this happen over and over. When you think you are 90-percent done, you are probably really about half way. Plan your release date accordingly. Try not to stretch out that last 10 percent. Know when to wrap up your game and call it finished. You can always find something to tweak. Acting on this impulse may keep your game at home and not on the market.

Pay attention to the final details. When knitting a sweater, the finishing touches make the difference between a sweater that is "homemade" and one that is "handmade." Similarly, the finishing touches on a game will make the difference between a game that is done by amateurs and one that is done by professionals. Pay attention to everything that is important; the documentation, labeling, packaging, and overall presentation will have a major impact on the salability of your game. Remember, first impressions count.

Take pride in your career as a game developer. Game developers are the brightest and the best of computer programmers. They are the most creative, smartest, most admired, and most marketable. Aspiring to be a game developer is a worthy ambition for any young person, and achieving that goal is the proof of maturity.

Feel good about yourself. You are contributing to the cultural wealth of the human race.