These are the questions that used to keep me up late. Unfortunately, I had to learn the hard way. When I started writing computer games, there was virtually no information available. We were all stumbling around in the dark back then. Game development techniques were invented or discovered in a haphazard fashion. That situation has gradually improved. These days, many people share in the pool of knowledge that gaming technology has become. But it is shared as a verbal tradition--most of the fundamentals of gaming technology remain undocumented. This book is an effort to change that tradition. Throughout this book, I'll be showing you how action arcade games are created from the ground up. You'll learn what it takes to create one, how to work with artists, how to create useful support tools, how to code up fast VGA Mode X graphics, how to debug your games, and even how to market your games. If only I had a book like this when I was starting out!
Some of my friends who are game programmers aren't pleased that I wrote this book. These game programmers (gamers) share a certain mindset; they are willing to exchange information and coding secrets, but only up to a certain point. After all, some things are, by tradition, kept secret. If everybody knew how to write games, gamers wouldn't be valuable anymore. So, why should I give away the secrets of gaming technology? In general, I do not share the point of view that technological cards should be played close to one's vest. I am in favor of disseminating information, even over the protests of some of my colleagues. When Jeff Duntemann, noted editor of PC TECHNIQUES magazine, asked me to write a book on game programming for The Coriolis Group, I jumped at the chance. I believe the technology should be documented, and I am willing to be the one to do it.
I'm in a unique position because I don't rely on game programming as my primary source of income anymore. My husband and I sell a programmer's graphics library called Fastgraph. Since this toolkit is used by many programmers to write games, our interest is in helping our customers (gamers) write as many games as possible. The more game programmers there are and the more games that get written, the more customers we'll have.
So unlike other gamers, it's not in my best interest to keep gaming technology a secret. The best thing I can do is give it away and hope people like you can use it. So, here's your opportunity: take whatever you can from this book--the tools, the knowledge, the programming and design tips--and create the best possible action arcade games that you can and help spread the fun and commerce of PC gaming.
The code in this book represents a technology that has never been documented. There is no reference book you can look up to show you how to write a side-scrolling arcade game. The information is simply not available anywhere. In return for the privilege of presenting my product Fastgraph to you, I'll give you this information, and what was once undocumented will now be recorded.
This book is the product of several years of work. The games and utilities in this book were written by me over a three-year period, but they represent a much larger investment in knowledge. The techniques for creating side-scrolling games were developed over many years by many people. I feel fortunate to have been a part of this community of knowledge, and now I am sharing what I have learned with you. You will find a lot of source code on the companion disk--over 12,000 lines of code! You will also find a complete tool set to to help you build action arcade games, along with several example programs to show you ways to use the tools. There is also a powerful graphics library included on the disk to speed up and simplify the development process. This software, along with the ideas presented in this book, will give you everything you need to get started on your path to game development success. Here's what you get:
So, what exactly is a game engine? Most people think of a game engine as the underlying code to a computer game, plus the utilities used to create the game. Since we're treading into uncharted territory here, I'll go out on a limb and define a game engine to be just that. In actual practice, a game engine is a rather nebulous concept. I've seen people write a few functions to perform 3-D projections and call their code a game engine. I've also seen systems that are so rigid that you can only write one type of game, within a few narrow parameters. These "engines" are sometimes sold commercially.
In my opinion, a game engine should be flexible enough so that it can be easily modified to accommodate a great number and variety of games. It should also be powerful enough to be significantly useful. That means the developer using the game engine will have a major advantage over the developer starting from scratch. The game engine should give the developer extensive functionality without getting in the way when the developer wants to be experimental. The game engine should also be thoroughly tested, and should have practical, as well as theoretical, applications.
That's a tall order for the game engine developer! In this case, the developer is me, and I've done the best I can to write a game engine that fits that description. No game engine can be all things to all people, however. You'll surely find parts of my game engine that you want to work differently. The best part is that you can change it yourself since I'll be giving you all of the source code. Make it your game engine. Modify it, upgrade it, and use it as you see fit.
The game engine in this book consists of two parts: the game editor and the underlying game code, or gametemplate. The game editor is actually a collection of tools for building games. You can use the game editor to create tiles, edit levels, import and edit sprites, and manage files. The second part of the game engine, the game template, should be thought of as a skeleton for creating side-scrolling arcade games. How much of this skeleton I should write proved to be problematic. I didn't want to write a whole game, because it wouldn't fit in this book. But I did want to give you more than a handful of disjoint functions. So I wrote "almost" a game. The Tommy's Adventures game is designed to give you enough information about how such games work that you can use it as a model for your own games, without overwhelming you with too many details.
I designed this book for programmers but you don't need to be a rocket scientist to follow the discussions or the code presented. I've tried to present the key areas of side-scrolling arcade game programming in a step-by-step manner so that you can understand both the big picture concepts and the important details. Some of the programs, such as the game editor, are rather large (over 7, 000 lines of code!), so I'll be presenting the code highlights in the book to help you navigate your way through the code. The first thing you may want to do is print all of the C source files that come with the companion disk. You might want to punch holes in the listings and put them in a binder for easy reference. But make sure you get a big binder!
Any C/C++ programmer can understand and use the code presented. No knowledge of assembly language is required for most of this book. There is a little bit of assembly-language code presented when timing considerations are discussed, but you should be able to use that code without modifications. While understanding assembly language will be useful to you in your gaming career, it's not a prerequisite to reading this book.
In addition, there's quite a bit of information in this book that requires no programming knowledge at all. This introduction, for example, contains no code. Similarly, Chapters 1, 18, and 19 are not just about programming games. They contain information about what side-scrolling arcade games are, how they work, and how to finish them and market them. Publishers, distributors, producers, and curious game players may find these chapters interesting.
Neither Chapter 2 or 3 contains code, but they are directed more toward the developer. They discuss how to go about developing games and how to use the game editor. Usually, the programmer is the one who uses the game editor, but not always. I've heard of programming teams where a non-programmer is the creative impetus behind a game, and may take charge of level design.
Chapters 4 through 15 contain the meat and potatoes of game programming. We begin by discussing how to develop your tools. After all, you can't do a proper job without proper tools. Chapters 4 through 9 discuss the source code for the game editor. Some of the concepts in these chapters can be applied to other types of games. All games, not just side-scrolling arcade games, require pre-processing artwork. These days, artwork is bigger and more important than ever. Anytime you can write a program to manage the tedious job of importing artwork into your game you should.
Chapters 10 through 13 discuss the code that is very specific to side-scrolling arcade games. Our sample game, Tommy's Adventures, is dissected and the concepts of using tiles, sprites, scrolling, and animation are discussed in detail. Hard-core game programmers may want to skip ahead to these chapters. This is where the good stuff is.
Before you skip ahead, though, take a good look at Chapter 5. It is in this chapter that the concept of scrolling using tiles is introduced. This technique is the heart of side-scroller programming; it's the topic that gets the most discussion and generates the most interest. It was presented in the game editor section because, like the game, the level editor requires four-way scrolling. This material will be covered again in Chapter 11, where we look at game scrolling, which uses the same technology as level editor scrolling, but at a much faster pace.
Finally, the appendices offer you some useful resources, and the glossary will help you demystify some of the common game developer jargon.
Throughout the book we'll highlight important terms and concepts with an icon that I call Tommy's Tips. Here's an example:
A game engine is the reusable, underlying code for a game, along with the collection of tools and utilities used to create the game. A game engine usually consists of two parts: a game skeleton that can be used as a template for other games, and a game editor for processing artwork.
Beneath the game engine, there is an even lower level of code. This code is the graphics library. All game programmers use graphics libraries, but not all of them use a commercial graphics library. Some game programmers prefer to write their own low-level graphics routines.
Writing a graphics library from scratch would definitely be beyond the scope of this book, plus it would not be nearly as interesting as the topics we'll discuss. Therefore, we'll use a commercial graphics library upon which to base our game engine. The library we'll use is called Fastgraph. It was written by my husband, Ted Gruber. It is well suited to the current task (and to many other tasks), and it has the advantage of being available in a shareware version.
We are including the shareware version of Fastgraph, called Fastgraph/Light, on the companion disk. This is a fully functional, fully documented version of Fastgraph. When you install it, you'll get the libraries and utilities, examples, and complete documentation. If you want, you can print out the Fastgraph manual and read it. If you prefer, you can scan the Fastgraph manual online, and just use it to fill in whatever gaps in your understanding are left unanswered by this book. To help you understand Fastgraph, we'll include Fastgraph boxes that define and explain Fastgraph's functions and programs. Here's an example of a Fastgraph box.
FGDRIVER.EXE
The FGDRIVER.EXE program is a TSR video driver for Fastgraph/Light. This program must be run once before any program linked with Fastgraph/Light can be run. It loads into memory in a manner similar to a mouse driver, and it will stay in memory until it is unloaded or until you reboot.
I recommend you install Fastgraph/Light before you try any of the other code on the disk. (The installation instructions are included at the front of this book.) Read the installation instructions and experiment with the library a little to get familiar with it before you try to recompile and relink the game or the game editor. If you decide to use Fastgraph rather than Fastgraph/Light, there is ordering information in the back of this book. Fastgraph works the same as Fastgraph/Light, except there is no TSR driver. To upgrade your code to work with Fastgraph from Fastgraph/Light, all you need to do is relink. The code will be completely compatible.
All the programs on the companion disk were tested with Fastgraph and Fastgraph/Light, and work with current versions of Borland C++, Turbo C++, Microsoft C/C++ and Microsoft Visual C/C++. The programs probably work fine with other compilers too, though I haven't tested them all. I'll be working on that while this book is being printed, so be sure to read the release notes on the disk for the latest information on the software. Compiling instructions and batch files will also be on the disk as appropriate. Everything that you'll need to write your own games is included in this book and the companion disk except, of course, a PC equipped with VGA, a mouse, and a C compiler.
The license agreement for the software is printed on the last page of this book. My feeling about the code is that I want you to use it. Take my code and dissect it, change it, add your personal touches, and create great games with it. The only part of the game I want to hang onto is the artwork. The main character, Tommy, is my baby. Please don't write any games starring Tommy for commercial use. (Although, you can feel free to use Tommy and any of the other artwork to create a game for the contest presented in this book.) Create another character of your own. Similarly, the background art is proprietary. You can experiment with the tiles, use them to test the game editor, and create your own levels with them. But please do not release any games using my artwork. I may want to use that stuff myself someday, and it was mine first.
None of the code or artwork is public domain, and there are some time restrictions on how long you can use the unregistered version of Fastgraph/Light . So when you write your game, play fair. Use a registered version of either Fastgraph or Fastgraph/Light, and get your own artwork. If you do those things, you're welcome to use the game editor and the game engine code as much as you want.
Cover |
Contents |
Downloads
Fastgraph Home Page |
books |
Magazine Reprints
Copyright © 1998 Ted Gruber Software Inc. All Rights Reserved.
Awards |
Acknowledgements |
Introduction
Chapter 1 |
Chapter 2 |
Chapter 3 |
Chapter 4 |
Chapter 5 |
Chapter 6
Chapter 7 |
Chapter 8 |
Chapter 9 |
Chapter 10 |
Chapter 11 |
Chapter 12
Chapter 13 |
Chapter 14 |
Chapter 15 |
Chapter 16 |
Chapter 17 |
Chapter 18
Appendix |
License Agreement |
Glossary |
Installation Notes |
Home Page
So you want to be a Computer Game Developer