Games People Write

Jump into games programming with advice from the experts.

By Mike Scanlin

Tricks of the Mac Game
Programming Gurus
By McCornack, Ragnemalm, Celestin,
et al.
Hayden Books, 1995
ISBN 1-56830-183-9
861 pages (softback) with CD-ROM. $50.00

The desire to write a computer game has probably recruited more people to study computer programming than any other kind of software. Certainly, this is true for me. It was 15 years ago when I asked for my allowance in quarters so I could go down to the local arcade and play games. I remember wondering how they made those games and thinking that it must be the coolest job in the world. Then came the day my grandfather gave me a 16K Apple ][ computer. As with many people, it changed my life. I became obsessed with learning everything there was to know about programming games. It was a slow process of trial-and-error, with lots of hacking and disassembling in between. I can only imagine how much quicker I could have learned everything if I’d had a book like Tricks of the Mac Game Programming Gurus back then. I would have saved so much time that I might have gone outside once in a while, had a few friends and maybe even gone to the movies occasionally.

While there is much to be said for figuring out how to do something on your own, there is also something to be said for not reinventing the wheel all the time. This book explains and solves many of the problems you will encounter while writing a Macintosh game. It will give you enough of the basics so that you can concentrate on game playability, good graphics, and sounds, rather than figuring out things like how to hide the menu bar, how to create preferences and saved game files, and how to correctly let people configure their keyboard controls independent of their country or keyboard model.

This book was written by many people, each explaining everything he knows about his area of expertise (graphics, sound, QuickDraw 3D, networking, PowerPC, etc.). There is not much source code printed in the book (for space reasons - it’s a big book as it is), but the accompanying CD-ROM has lots of documented source code on it.

The beginning of the book reviews GWorlds, GDevices, CopyBits, PixMaps and palettes. For the uninitiated these concepts can be overwhelming, but the author does a good job of telling you just what you need to know to get started. There is a simple demo application called Clem the Clam that shows a little animated clam walking across a background (with appropriate masking). It’s a great app to learn and experiment with.

There is a chapter on how to make good sound (overlapping sounds, background music, etc.), as well as a discussion of an included code library called Hollywood. This library allows you to play AIFF files, 'snd' resources, mono, stereo, MACE-compressed, streaming sound, 8-bit sound or 16-bit sound, and it can do them all at once. This is a great way to get up and running using sounds with minimal effort. The only effort is coming up with good sounds for your game. The mechanics of playing them from within your game are taken care of for you.

A similarly useful chapter covers networking. Taking advantage of the Macintosh’s built-in networking capability has never been easier. It covers AppleTalk in detail (ATP and DDP), and goes into Apple’s new networking protocol, OpenTransport, as well. Once you’ve read this material you will no longer be intimidated by the concept of writing a network game. As in the sound chapter, the grunt work of networking has been taken care of for you. Now you just have to come up with a good network game idea.

Once you’ve got sounds and networking under control, the remaining areas to concentrate on are graphics and game design. Throughout the book there are references to little tricks with graphics: fast blitters, masks, working with offscreen PixMaps, optimizing for CopyBits. I especially like the one discussing how to encode (and compress) 8-bit indexed images so that your blitters are faster. You’ll find there are many examples using 8-bit indexed images. That seems to be the appropriate lowest common denominator you should shoot for if you want to reach the broadest possible Macintosh audience. It also makes porting to non-Macintosh systems easiest (there is a complete chapter on porting and what to consider).

Game design is, of course, the hardest part of any good game. This book has taken care of many of the mechanical aspects involved in writing a good Macintosh game, but it can’t solve the creativity problem for you. It’s up to you to work with good artists, good musicians and good creative people to make your game really fun to play. There are a couple of chapters on how to make the entities in your game appear realistic. The equations for realistic collisions, distance covered by diagonal movement, acceleration due to gravity, etc., are given along with clear diagrams.

Several optimization tips are given, including: using fixed-point math when you can (velocity calculations), using the floating-point registers on a PowerPC as the fastest way to write your blitting loops (for maximum data transfer throughput), using aligned data on the 603 and 604 (which sped up one game’s blit loop by a factor of two when compared to the unaligned case), and using no more than 8 parameters per function so the PowerPC can pass them in registers. There are other details, too, but I’ll let you ferret them out on your own by reading the book.

I strongly recommend this book to anyone considering writing his or her first game. I also recommend it to people who are unfamiliar with sound or networking. Those skills can be useful even in non-game applications.

Having said all that, there are some things about this book I didn’t like. For starters, it really does feel like it was written by many different people. There are places where it’s redundant. I’m not sure I need to be told how to hide the menu bar in three different ways in three different chapters. That tends to confuse, more than help. Which is the best way to hide it? I still don’t know. It would have been great, too, if they could have gotten everyone to agree to a common set of coding guidelines and naming conventions. Consistency enhances comprehension when you’re looking at someone else’s code.

Several of the authors suggest boosting speed by using tables to look up various things (entity behavior, dungeon maps, etc.). While I applaud that technique, I would have made more things resource-driven instead of using static data in the source code. Perhaps, though, the authors used static data for demonstration purposes (to avoid adding the complication of custom resource templates), or for portability reasons.

While some of the authors are very good at explaining their optimizations and why they did things a certain way, others are not. For example, one of the code snippets calls MoreMasters() four times during initialization with a comment that says, “so we won’t run out of handles”. But the phrase “run out of handles” is misleading, because the issue is memory fragmentation, not running out of handles. Nowhere is it explained how to determine the appropriate number of preallocated master pointers (i.e. by exercising your program thoroughly and then looking in the heap to see how many were created).

There are a couple of typographical problems, such as the occasional double-hyphen in the source code (a post-decrement) being converted into an em-dash by some overly aggressive file translator. I’m not sure if novice programmers will know that x-; means x--; (I guess they’ll have to figure it out when they try to compile). Throughout the book there are “Note” paragraphs set on top of solid 10% gray rectangles. Maybe it’s just the copy that I received but about half of those paragraphs were missing the background rectangle or it was so light that you couldn’t see it. The result is that as you’re reading the text you sometimes come across what seems to be a completely disjointed paragraph. Not a big deal once you’ve encountered it a couple of times, though, because you know to skip it and keep reading the text in the following paragraph.

There are also some things that are downright strange. Apparently, one of the authors is Swedish because some of the screen shots contain Swedish text and buttons in the Open/Save dialogs. That adds confusion in an English book because the text around those dialogs was discussing how to save and load games, not how to internationalize. Also, there is a chapter called “Aesthetics” which emphasizes that a consistent look-and-feel can help your game, but then goes on to label the OK button as “Okay” in a standard Macintosh dialog (right next to a Cancel button). To anyone with Macintosh experience, it looks distinctly odd and unnecessarily different.

Despite the above problems, the code is readable and the game logic and diagrams are clean. Also, in a series of interviews, published Macintosh game authors answer some of the non-technical questions most curious readers will have, such as, “How many people worked on that game?”, “How long did it take?” and “What tools did you use?” If you would like to see the sun, have friends, have time to go to the movies or maybe just learn a bit on how to write a Macintosh game, then you should read this book.