Exile - Hints for Programmers, by Jeff Vogel

[Ess-Eschas]

Hello all!

 

While searching for something else, I came across an interesting article Jeff Vogel wrote about Exile I. It was distributed with a special release of Exile 1.1.3, which was included on the companion CD to the 1995 book ‘Tricks of the Mac Game Programming Gurus’, published by Hayden Books. I don’t think this article has been made available online before. Since the article is contained in a old type of package that is not easily read these days – good old DocMaker! – I thought I’d post it on here for posterity.

 

While many of the specific details no longer apply, I think a number of the general points are still quite pertinent today. And they offer an interesting insight into Jeff’s design practices, both in what he did back then, and what he’s carried with him throughout his career. Check out points 6 and 7 in particular!

 

So, without further ado, here’s Jeff’s article, dated 7th June 1995!

 

~

 

Exile - Hints for Programmers   
by Jeff Vogel

 

 

Section 1: Introduction

 

 

     This document contains information about Exile which may be useful to aspiring game programmers: descriptions, examples, and such. It also contains advice from me, a Successful Shareware Game Programmer (TM). I've never been one to avoid soapboxing about game programming, and I think some of the things I've learned may be useful to you. If not, well, I tried. And, you can tell me where I went wrong using any of the E-mail addresses given in the game. I love talking to programmers, players, or anyone who spends time writing me.

 

     The next section contains a tour of the resources in Exile, using ResEdit. I point out a lot of cute tricks you can use, and several mistakes you can avoid.

    Before I start the ResEdit tour of Exile, however, there are a few common misconceptions people have about game programming. I want to dispel them, in order to talk you, yes you, into trying to write games. This platform needs all the good work it can get:

 

Wrong Thing 1:   It takes lots of experience to write a good game.  Exile was my second Mac program. The world editor for Exile was my first. I'm now making my living off of it. Believe me, you don't need a world of experience to make games. Speaking of which...

 

Wrong Things 2:  You need a lot of in-depth hacker knowledge to write a good game.  This is true if you're trying to write yet another Doom clone, or something like Apeiron, with very intricately done animation. For the vast majority of games, however, straight toolbox calls will do. Nothing fancy. Again, you can do it.

 

Wrong Thing 3:  It will be a lot of fun.  This is half true. There will be a lot of fun involved. However, if you're going to do something real, something people will really want to play and pay for, it's gonna' hurt. It will take a lot of work, and a lot of playtesting. Hundreds of hours of your life. Exile took 1000 hours, so far, and I got off very easy.
      However, I don't regret a minute of it.

 

Wrong Thing 4:  I need really fancy graphics and sounds!  No. Look at Exile. The graphics are good, but nothing to bounce up and down screaming about. The most important thing, really the only important thing is...

 

The Play's The Thing.

 

     Make a good game, a fun game, a game your heart is in, a game YOU would want to play, and you can make money. Nothing, not good sounds, not good graphics, not excellent distribution, not a nice review in MacUser, nothing will make up for a lousy game. I promise.

 

     Now then. About Exile. Trot out a copy of ResEdit, every programmer's friend and right arm. Open up Exile with it. In the next section, I'll discuss some of the clever tricks that you can use, and several mistakes you should avoid...

 

 

Section 2: Everyone Loves ResEdit!

 

 

     Why? Because we can root around in other people's work and steal their ideas! Don't be ashamed. I do it. You'll do it. And they'll do it to you. Everything in a resource is fair game. If it's a secret, put it in your code or in an encrypted 'TEXT' file. Everyone does that too.

 

'PICT' -
      The first stop in the tour of the resources of Exile is the 'PICT' resources. Exile is very unusual in the respect that ALL its graphics are kept in PICT resources. Most programmers don't do that - they store them in files or custom resources instead. I did it this way because it's very easy.
     Note how every terrain type, monster, what have you has its own PICT resource. This was my biggest mistake. I did it this way because when making dialogs, it was much easier to include a monster as a PICT in the dialog. The other alternative was having the program draw it in itself. I was too lazy to do this.
     It was a mistake. Why? Look at the info on each terrain PICT. You'll see each take 2.5 - 3 K. Each is 28x36 bytes. That's only 1008 bytes of picture info. Where'd the extra 1.5-2K come from? Well, every PICT resource also has a color table and lots of other data with it! Thus, EVERY pict has 1.5-2 K of overhead data.
     This doesn't sound like much, but when you have over 200 PICTS, as I do, it adds up FAST. It's a shareware program - people download it. Adding 300K of unnecessary data to a shareware program is a SERIOUS mistake.

 

     You'll also note many of the PICTs have black backgrounds. When using CopyBits transparently (something you'll want to do a lot), black was the color I masked out. This was a mistake - since the default color for the background is white, whenever I wanted to draw something transparently, I had to change the background to black by hand. Tiny mistake, but irritating.

 

'STR#' -
     Now for something I did right - string lists. These are very useful, esp. if you, like me, are writing a game with lots of text. They're easy to make and use. They're stored in memory very efficiently. I love them.
     The dialogue for all the towns is in here. Take a look for a while. After a bit, you'll be able to figure out the format for storing the data.
     You will also be able to read a bunch of dialogue and pick up solutions to the puzzles in the game. It's worth noting that I could easily encrypted this data to prevent this. However, why bother? I mean, if someone is stuck and wants a hint, what business do I have keeping him or her stuck at that point?
     My job is to help people have fun. If, to keep having fun, they need to peek at the answers, I have no interest in stopping them. I also give hints to anyone who asks. It makes people happy. It's good business.

 

'DITL' -
      Ahh, dialogs, the boon and bane of the Mac game programmer. The modal dialog is the easiest, quickest way to create all sorts of stuff in your game. They also get on user's nerves if you use them too much. I use them a lot. People gripe at me for it all the time. Be careful.
     Looking around a bit, you will see the single most useful trick for getting a dialog to look professional - the Cover The Whole Thing With a PICT trick. Create a PICT resource looking like what you want the window to look like, and slap the sucker down on the dialog at the start. Eats up memory like hell, but users demand that the dialogs look spiffy, so we have little choice.
     By the way, the buttons in Exile are not standard Mac buttons - they're programmed by hand. I get griped at about this occasionally - I should have made them customized buttons using toolbox routines. Most people, however, don't care.

 

     A side note - the Human Interface Guidelines are just that - Guidelines. However, you ignore them at your peril. There are some people who will not pay you if you violate the HIG too often. You will violate them, I promise, but choose carefully when and how you do it.

 

'snd ' -
     Not much to say here. EVERYONE stores their sounds this way. It's the only good way, really. Spend a little bit selecting info on the sounds. Notice some are purgeable, and some aren't. The little sounds that are used all the time aren't purgeable. I load them in at the beginning, lock them down, and keep them in memory for the whole time Exile is running. The rest, I load when I play them - these MUST be purgeable, so they can be ditched when the game gets short on memory.

 

'BNDL' -
     Ahhhh ... where would we be without customized icons? Learn how to do this. It's a necessity. And remember - when you make the change, you need to rebuild the desktop to see it. Restart, and while the Mac is rebooting, hold down the Command and Option keys.

 

     It's also worth it to take a look at the specials.dat file. When you have lots of resources, storing them in a different file is a very good idea. This file contains nothing but several hundred dialogs. I give special encounter info using dialogs. It's easy. It works. Your mileage may vary. They do take a long time to make, by the way.

 

Section 3: Miscellaneous Tips

 

 

     Some much to say, so much to learn. The path to doing this stuff full-time is long and icky. However, there are several tricks and guidelines that can make your life easier...

 

1. Write clean code!  Remember all that boring stuff they told you in computer class about writing elegant, easy to read code? They weren't joking. They were right.
     Why? Well, Exile is over 20000 lines of code. Your Big New Game will be too. Every line you write you will have to return to at some point, probably months later. When you do, you will need to figure out what the heck you wrote. If the code is a spaghetti-like mess, you may spend an hour. This is very bad. And, speaking of which...  (this one's gonna' hurt)

 

2. Comment your code!  Yeah, I know, I know. You'd rather die. But trust me on this one. If one minute of commenting a routine spares you ten minutes of figuring out what the heck you did six months later, you got a good deal.
    Your most valuable commodity will not be RAM. It will not be cool extensions, or programming manuals, or amazing applications. Your most valuable commodity will be time. Commenting code saves you time. It doesn't take huge gobs of anal-retentive comments, explaining every line in grotesque detail -  quick notes saying what each 20 lines of code do should suffice. It's one of the best habits you can cultivate.

 

3. Don't be a system hog!  Keep your game as small as possible - if it's shareware, people are going to be downloading it. The bigger it is, the less chance they'll grab it. 1.5 MB compressed is a good upper limit.
     A shareware game probably shouldn't use more than 2 MB of RAM. If Marathon can run decently with 3 MB of RAM, your game can too.
     A surprising number of users play games while doing their work. Your game should be able to coexist with other programs. If it can't, it will cost you money.

 

4. Get DocMaker!  This document was written with it! So are many shareware program's docs, and most online magazines. It's a beautiful shareware program that makes documents that run on anyone's machine.
     By the way, Get More Info is an incredibly useful extension. It lets you change any document's owner and type.

 

5. Buy lots of programming manuals!  Time is your most valuable commodity. If a $30 book saves you 3 hours of programming time, you got a great deal. This book is a good start, but won't tell you how to do everything. The Inside Macintosh CD-ROM is great! Inside Mac - Macintosh Toolbox Essentials, in paper form, is essential. Any book by Dan Parks Sydow should be on your shelf as well.

 

6. Vogel's First Rule of Programming - There Is No Such Thing As A "Small" Change.  Every change you make to your game will have two bugs in it. The first will be obvious and stupid, and you'll be relieved to find it and feel like you did your debugging. The second bug will be subtle and nasty and make your life a living hell, usually two months later. Or after you released your game. This has happened to me more times than I care to think about.
     There is no such thing as a "small" change. Speaking of which...

 

7. Test Your Game!  Shareware has gotten a reputation as being very buggy. This perception is, generally, justified. Most shareware developers seem to treat beta-testing as an irritation, not an absolute necessity. This attitude is appalling.
     If we shareware developers are ever going to be treated with professionalism and respect, the very, absolute least we need to do is write stuff that works.

 

8. Do it!  I mean it. Grit your teeth. Set aside a lot of time. And go for it! Write the game you want to play, and odds are, others will too! I won't kid ya', it'll be a lot of work, and suck sometimes. But it's worth it, a thousand times worth it.

 

By the way, it's SpidWeb@aol.com[*]. If you read this, please drop me a note. I want to hear from you!

 

- Jeff Vogel
Keeper of Exile
Spiderweb Software

 

~

 

[*] Ess's note: This address is no longer functioning. Check Spiderweb's current Contact page for up-to-date information!

[Aventari]

Great find. It is interesting to see that Jeff has been so consistent over the years in his enthusiasm for making games.

[Celtic Minstrel]

Well, section 2 is entirely obsolete, and also section 3 point 4, but I think most of the rest is still reasonable to good advice…