Contents
Editorial: Five Years and It’s Time for a Change
Chris Crawford
Professionalism
Evan Robinson
Making the PC Speaker Speak
Hal Martin
Programming MC Kids
Gregg Iz-Tavares and Dan Chang
Lessons from Patton Strikes Back
Chris Crawford
Editor Chris Crawford
Subscriptions The Journal of Computer Game Design is published six times a year. To subscribe to The Journal, send a check or money order for $30 to:
The Journal of Computer Game Design
5251 Sierra Road
San Jose, CA 95132
Submissions Material for this Journal is solicited from the readership. Articles should address artistic or technical aspects of computer game design at a level suitable for professionals in the industry. Reviews of games are not published by this Journal. All articles must be submitted electronically, either on Macintosh disk , through MCI Mail (my username is CCRAWFORD), through the JCGD BBS, or via direct modem. No payments are made for articles. Authors are hereby notified that their submissions may be reprinted in Computer Gaming World.
Back Issues Back issues of the Journal are available. Volume 1 may be purchased only in its entirety; the price is $30. Individual numbers from Volume 2 cost $5 apiece.
Copyright The contents of this Journal are copyright © Chris Crawford 1992.
_________________________________________________________________________________________________________
Editorial: Five Years and It’s Time for a Change
Chris Crawford
This issue closes the fifth year of publication of the Journal of Computer Game Design. I must say, it is surprising how the years have flown by. After five years, the time has come to re-evaluate the fundamental purpose and content of the Journal.
This Journal was founded with a clear purpose; I stated it forthrightly in the very first editorial:
“The purpose of this Journal is to foster the development of the art of computer game design. It is a forum for game designers to talk to each other and the world.”
The emphasis was on the art of computer game design. From our comfortable position here in 1992, that seems natural and obvious. Back in 1987 things weren’t so simple. The truth is, five years ago computer game design was a field without an identity. “Computer game designers” didn’t exist in any significant numbers. Our industry was populated by a random collection of programmers, graphic artists, writers, and other talented people who somehow slopped games together. There was no community of game designers, no sense of identity, no common terminology, no shared outlook. We were a mob, not a community.
I therefore embarked the Journal on a clear course with the declared intention of founding a social and intellectual community. Every issue shouted loudly, "We are NOT programmers! We are computer game designers!" The emphasis was on the positive side of that declaration, but the negative side was there, too. For the first five years of its existence, this Journal has been dedicated to the goal of community-building. This dictated much of the editorial content of the Journal: articles defining the fundamental terms of our craft, characterizing the roles of the various artists who work in our industry, arguing over the basic terms of business under which we work. After a rocky first year, the readership caught on and began submitting articles that staked out the territory with increasing precision.
But now, five years later, the situation has changed. The community that I sought to forge with the Journal (and later, with the Computer Game Developers’ Conference) has come into existence. The basic terms of our field have been defined. True, there remains room for argument, but at least we have framed many of the questions over which to argue. Most important, we as game designers have a clear identity. We know who we are, perhaps not with Jungian clarity, but almost as well as many other professions. We are not the kid brothers of "real" programmers. Game design is not a temporary stage that real programmers go through between college and their first serious job. It is a tough, demanding job that is widely recognized as one requiring talent, and we have identified a class of designers who have that talent. We’ve come a long way.
It is time for this Journal to recognize those changes. Accordingly, this Journal will undergo major changes, some of which begin with this issue. Among these changes:
New editorial approach
Henceforth, this Journal will shift its emphasis away from community-building efforts and more toward the nitty-gritty of game design. It’s time to pull this Journal’s head out of the clouds and focus on more down-to-earth issues. The change will not be cataclysmic -- hey, I’m still Chris Crawford and there will always be a bit of Blue Sky in this Journal. But Blue Sky will henceforth take a back seat to Olive Drab.
Let me be specific with a prioritized list of articles that I’d like to see you the readership submitting. In order of desirability they are:
Great Articles
Discussions of algorithms or computational strategies or techniques that solve problems of particular interest to game designers. Good examples are Evan Robinson’s and Hal Martin’s articles in this issue, or some of my technical articles from previous issues, such as "How to Build a World," or the article on combinatorial methods in creating province names.
"I just finished a game project and here are some of the interesting problems that I encountered and the solutions I devised." (Example: "Lessons From Patton Strikes Back," this issue)
Good Articles
Articles on how to use a new and interesting piece of hardware. Now, I have to be careful here. I don’t want to turn the Journal into a dumping ground for technical notes from every hardware manufacturer in the business. I also don’t want the sound card wars fought out in excruciating detail in these pages. In general, I’ll cast a jaundiced eye at articles emanating from manufacturers. I’d much rather see a real live games programmer talking about hardware.
Fair Articles
Opinion pieces presenting hot air about what’s right or wrong with this industry. Henceforth, I’ll be evaluating each article by its information content. Opinion pieces, by their nature, don’t have much information content. I’ll print one if it presents some really interesting and well-reasoned opinions. Besides, editorials are MY territory!
Bad Articles That Won’t Be Printed
Hate pieces about publishers. Sorry, folks, but gripe sessions just aren’t appropriate in this Journal.
Anything for beginners. This is a professional journal and I will not patronize beginning game designers. The best way to help beginners is to let them in on how we perform our craft. Talking down to them doesn’t help them.
Technical articles covering material that’s covered elsewhere. If you’ve got yet another sort, hashing scheme, minicompiler, or floating point routine, take it somewhere else. I want technical articles of special interest to game designers covering material that they won’t get in any of the hundreds of technical journals out there.
Submission standards and rules
I keep getting article submissions from people who don’t read the masthead. Six months ago somebody sent me hardcopy of an article with a cover letter promising a diskette in a week. The diskette never came, so I trashed the article. I am not a typist, and my fingers have finite capacity, so if you can’t get me machine-readable source, I won’t print it. I would prefer to receive everything in Macintosh MicroSoft Word 4.0 format, but I can take flat ASCII on either Mac or IBM diskettes. You can send me the file via GEnie mail or even MCI mail. I will no longer take submissions by custom modem transfer; those operations always consume far more time than just dropping a diskette into the mail.
If you need to include illustrations in your article, please format them in PICT format on the Mac or TIFF format on the PC. Gregg Tavares and I pulled our hair out trying to find a format that would work. It took nearly a month of trial and error. If you send it in a strange format, I probably won’t be able to print it.
Ads
I experimented with advertisements a few issues back. I printed three ads and it appears that they failed to generate a single response. I therefore decided not to permit any more ads. However, I have received requests from readers for ads. They believe that there must be products of special interest to game developers, and they have no ready means of locating such products. Accordingly, I have decided to try again. However, I do not have a sales force to hit the phones, so I’m going to leave it up to the readership. If you know of a vendor with an interesting product, why don’t you call and suggest that they advertise in the Journal? For my part, I’ll keep the ad rates low (I’m not paying for a sales force.) The policy is simple: $50 for a quarter page (3.0 inches wide by 4.5 inches high.) I’ll take camera-ready copy or simple ASCII. One color, nothing bigger, no discounts for smaller ads, payment with submission. I reserve the right to reject any ad that fails to meet my lofty standards of taste and refinement.
New layout and pricing
Another change coming will be a new layout. I haven’t decided on all aspects of the design, but the changes will be mostly cosmetic. It’s time to rework some of the layouts in this Journal.
Also coming: a price increase. I’ve held the line at $30 for five years, and inflation has slowly eaten into my margins. It’s time to bump up the price. Starting with Volume 6, Number 1, the subscription rate of the Journal will be $36 per year in North America, and $50 per year outside of North America. The price of a single back issue will climb to $6. All you people whose subscriptions expire soon, get your renewals in before October 1st and you’ll get the old rate.
_________________________________________________________________________________________________________
Professionalism (and a sidebar on Computer Opponents)
Evan Robinson
Copyright © 1992 Evan Robinson
Portions Copyright © 1991,1992 Hero Software, Inc.
Foreword
In the June 1992 issue of the Journal, Chris Crawford (Editorial: Get Professional!) bemoans the lack of “…submissions that dive into the nitty-gritty details of game design, openly discussing algorithms or computational techniques.” There’s a good reason for that. The aforementioned Chris Crawford has always campaigned against technical articles. I have always been under the impression that the express policy of the Journal was “No Articles On Programming”. But the ultimate expression of computer game design, algorithms, or computational techniques in our business is program code. If I am going to write a reasonably complete description of how something happens in Champions®, it will almost certainly involve programming and code or pseudo-code. Or it will be so long, wordy, convoluted, and self-referential that it will be less understandable than code.
There’s very little in what I do as a programmer, program designer, and game designer that I’m not willing to share with others. If I’m less than eager to share code or ideas, it’s usually because I’m embarrassed about their expression or simplicity, not because I think the material is so valuable that I can’t let others see it. I have given others the entire source to World Tour Golf, our graphics and support code, and probably most embarrassing of all, our utilities (which were never written to be used more than once, much less by other people). I’ve received similar consideration from others.
So to counter this vicious, backbiting, ill-conceived and unwarranted slur (insert large quantity of smiley faces here -- that was a joke!) against the flower of computer game designers and programmers, and to remind us all that “I have always relied upon the kindness of strangers,” I offer the following…
Technical Gunk About Computer Opponents
Champions offers me a unique challenge in the creation of the Computer Opponents (COs). Not only is the game system orders of magnitude more complex than any I’ve written COs for, the COs must do more than one thing. In World Tour Golf, the CO had to select a reasonable club and make a reasonable shot. Not too difficult. In Centurion, there were several COs, but they were each simple because they did not have many options. COs in Champions must be capable of programmed activity to support a storyline as well as “intelligent” combat decisions in a complex system. Because the system is expected to be expanded through data disks, (and the stories, scenes, and characters are not yet final for the first version) the COs cannot be hardwired to any specific set of stories, situations, and characters.
Jon Freeman very kindly consented to assist us in our discussion of COs. Many of the resulting concepts flow directly from his input, as well as that of the other Hero designers (Ken Zarifes, Ray Greer, Steve Peterson, and Nicky Robinson).
We broke the combat problem down into several parts. Programmed behavior we put aside for later. Simple combat behavior includes, among other things, and in no particular order,
1) when to quit
2) what attack to use
3) which opponent to attack
4) resource management (fatigue, limited use of powers, etc.)
5) where to move
The first attempt specified six basic characteristics. Combat Status is a (theoretically objective) measure of how the CO is faring in the current combat. Objectivity is whether the CO emphasizes the positive (from the CO’s point of view) or the negative. Risk is the willingness of the CO to hazard itself. Combat Mode expresses the CO’s current position on a continuum from Fully Offensive to Fully Defensive (and reflecting certain special states such as Berserk and Escaping). Adaptability is the ability of the CO to re-evaluate attacks/defenses and alter tactics and/or Combat Mode. Intelligence is goodness of data when re-evaluating.
The comment header describing my first overall AI routine was:
DESC:AI routine
1) If AI is unconscious and ready to act, Recover, DONE
2) get current combat status = objective_status + objectivity + risk
3) if not escaping and status is < EXIT_STATUS, mark as escaping
4) if not ready to act,
a) if blocked, move to avoid block
b) if escaping, do escape move to get away
c) otherwise, attempt to meet current distance requirement
5) READY TO ACT
a) setup housekeeping for next action time
b) adaptability/20 chance of re-evaluating attack data
c) select new attack
i) if AI has missed MISS_THRESHOLD times in a row
ii) 25% of time
6) get up if AI is down on ground
7) if escaping, set escape move, DONE
8) UP AND READY TO ATTACK
a) calculate range & direction to target
b) if current attack is STR based,
i) if range > 1 hex, move to target, DONE
ii) else pick punch or haymaker and set do_attack
c) else (power based attack)
i) if attack is ranged or range is < 2 hexes, do the attack, keeping track of misses. If hit and attack is special, choose new non-special attack, DONE
ii) if not ranged and range > 1 hex, move closer, else do the attack, keeping track of misses, DONE
d) if do_attack set, spend endurance, roll to hit do attack animation
if hit, do damage else keep track of misses, DONE
Obviously there are important changes to be made. There is no provision for changing Combat Mode (although Combat Mode is used in the routine to select a new attack). No mention is made of how to select the current distance requirement. The organization of 8) leaves something to be desired since several options that used to be present are no longer valid. Resource management isn’t considered. Attack selection is brushed off to another routine.
The attack selection routine illustrates a simple but valuable technique that should be kept in mind. The combat resolution system used in Champions is complex, requiring the examination of up to 42 Powers, Skills, Talents, Characteristics, Maneuvers, and Modifiers which might be present to determine a hit and up to 51 to determine damage. (After you climb down from the ceiling, you should be aware that the typical attack involves less than 10 of each, and the actual maximum for any specific attack is probably about 1/2 of the total which must be considered to account for every possible attack). Even though we have simplified to some extent, the thought of writing code to decide which attack was right to use was daunting.
So I didn’t. I just wrote the ToHit and Damage routines so that they could be used, without effecting any characters involved, to simulate attacks (this technique is called Monte Carlo simulation). Each routine takes an argument specifying the number of times the event should be simulated, and cumulative data is kept available to the CO routines.
The CO saves data from a Monte Carlo simulation of each possible attack for future decision-making. The goodness of the data is altered by varying the number of simulations in a run according to the CO’s Intelligence and then normalizing the data, allowing for wide variance or small variance in the data. Adaptability is used to determine how often the CO re-runs the simulations.
Given the data, attack selection is made according to Combat Mode. Each Combat Mode has several options chosen by random number, providing variability within each Mode. Each option is an ordered criteria pair selected from STUN, BODY (two types of damage), END (resource use), HITS (frequency of hitting opponent), and SPECIAL (attacks which do nonstandard damage). An attack is selected which has the highest ranking according to the ordered criteria pair chosen. One option is to continue using the last ordered criteria pair chosen.
Afterword
I notice, after writing this article, that there is much less code or pseudo-code than I thought there would be at the beginning. So my primary reason for not submitting meaty articles to the Journal was completely spurious. I abase myself in the general direction of Habitat Crawfordat and pledge future articles. Say Hallelujah!
True Confessions
cutting and pasting code into this article (and then removing it), I found an obvious bug in the following fragment:
if (LAST != ranking) {
rank1 = HINYBBLE(ranking);
rank2 = LONYBBLE(ranking);
}
…
ais[chr].rank1 = (Ubyte) rank1;
ais[chr].rank2 = (Ubyte) rank2;
…
If the selected ranking is LAST, the two local variables rank1 and rank2 are never initialized to their current variables in the ais[chr] structure, so the two criteria become random values.
That’s why I don’t like showing other people my code. Because I know things like that are hiding in it. But I say it’s better to find things like that and be embarrassed in public than to let them get into the program, even if nobody ever figures out they’re there. Because I want to be a professional.
_________________________________________________________________________________________________________
Making the PC Speaker Speak
Hal Martin
Anyone who has examined the innards of PC compatibles knows that the internal speaker was never intended to produce anything but single tones. Various high level languages have functions, such as sound() and nosound() in C, which can be used to play single melodic line music on the speaker. But it has been something of a mystery to a lot of programmers as to just how speech and assorted complex sounds can be produced on the internal speaker.
Questions about how to do it have appeared in the letters to the editor in Dr. Dobb’s Journal lately, although no answers have ever appeared there. When I first wanted to know how it was done, I left detailed questions in various Compuserve forums, without success. The people who know, and have been doing it for years in games apparently aren’t talking.
This article was prompted by Chris Crawford comments about professionalism in the last issue, It happened to be the last issue in my subscription, and I was thinking of not renewing because there seemed to be no articles of real substance. I had subscribed hoping to see some real how-to-do-it articles, like the ones we used to see in Byte, before it became another expensive sales catalog like PC Magazine, and like we still can read in Dr. Dobb’s. Then I read Chris’s article on professionalism decrying the same things about this Journal.
He’s right. No professional journal will succeed without those of us who are willing to share our ideas. As for the one mentioned here, it certainly qualifies as good practice, as opposed to proprietary information, as Chris defined it. That is, it has been around for quite a few years, so plenty of people have figured it out. So here is how the speaker talks (pardon my grammar, “speaks”).
The PC internal speaker can only be turned off and on. There is no voice amplifier connected to it. The off and on switching can be done under program command, or the speaker can be connected to the output of Timer 2 in the PC’s 8253 timer chip. It is through this latter method, along with setting the period of Timer 2, that single melodic line music is produced.
Production of speech on the PC speaker requires implementing a pulse width demod-ulation scheme, a rather crude implementation of which is shown in the accompanying listing. Pulse width modulation uses a pulse train of fixed frequency, with each pulse varying in width proportional to a sample of the modulating waveform taken at that instant. Figure 1 shows a sine wave as it appears once pulse modulated, and as it is demodulated.
The method described here actually begins with a string of digital samples as produced with a SoundBlaster Pro sound board. Hence, a function such as that of the listing can be included in a game meant to support either a SoundBlaster compatible board, or the PC speaker, as determined by the selections made during instal- lation. Sound tracks produced by the sound board can be run through this function without conversion, and played on the PC’s internal speaker if the game buyer’s PC is not equipped with a sound board.
The function in the listing can be called from C++ using the prototype
extern "C" void far VoiceTrk(char far *Start, int Length);
where Start is a far pointer to the beginning of the array of samples, and Length is the number of samples.
The function sets up two loops. The outer loop accesses samples until the array of samples is exhausted. The inner loop begins by turning on the PC speaker with an “out” instruction, then timing the width of the resulting pulse by looping a number of times equal to the size of the sample. When the inner loop has been executed a sufficient number of times, the speaker is turned off. Then the outer loop gets another sample from the sound track, and the process is repeated.
Note, by the way, that maskable interrupts are turned off with a CLI instruction before the sound reproduction begins, and turned on again with an STI instruction before returning control to the calling program. Otherwise, sound, and particularly music, produced would warble like old movies on late night TV. This is caused by the timing being interrupted by the 18.2 Hz time of day interrupt which keeps the system clock updated.
Right away, you can see why I referred to the function as a crude implementation. The function is obviously machine dependent, since the timing is dependent upon how long it takes the particular processor to execute the code. In writing this first version of the function, I had to work backwards, finally adjusting the sample rate on the SoundBlaster to make the playback timing correct. It happens that with my 386SX based machine running at 16 MHZ, the correct production sample rate is around 6300 Hz.
When the function runs, what is actually coming out of the PC speaker is the pulse modulated version of the input sound. A combination of the inertia in the speaker, plus the frequency response of the human ear, gives the smoothing effect shown in Figure 1 to give the approximation of the original waveform. The function seems to work best on sound tracks which are clipped when recorded on the SoundBlaster. The clipping doesn’t introduce much distortion, and even with the relatively poor sound reproduction quality of the PC speaker, I have been able to play speech and music with good results.
Granted, the function as shown is not suitable for production quality software, and I am not intentionally holding back some good but proprietary version. I just haven’t gotten around to writing it yet. There are a couple of ways to make the function hardware independent, and I will mention one. The nice folks at Ted Gruber Software in Las Vegas have a nice library of graphics tools marketed under the name FastGraph, and included in it is a function which can sense the speed of the particular processor on which it runs. One fix for the function in this article is to run Ted Gruber’s “how fast is the processor” function at the beginning of the game, and derive a slowdown constant from its output which would then be fed to the sound reproducing function.
This article was meant to be response to the lack of “how- to-do-it” articles in the Journal, but I will now indulge myself in yet another of those opinionated statements that have taken the place of the “how-to-do-it” articles. No doubt some of the readership who have been producing games for a lot longer than I have will sneer at this primitive technique, dismissing it with the observation that there are better PC speaker sound functions around. My reply is, if you had been willing to publish them, I wouldn’t have had to hack this one out on my own. So if you have a better idea, let’s see it in the next issue. (Or, more bluntly, put up or shut up — Ed.)
We are, after all, like writers of fiction, only in our own high tech form. The successful and published writers of fiction are often all too ready to show up at writing workshops and share what they know about creative writing with new writers. The world of printed fiction is thus all the better for it because of the diversity created by the new talent encouraged this way.
; File VOICETRK.ASM - This program plays a digitized
;voice track as generated by SoundBlaster as a
;pulse-width modulated signal on the internal IBM
;speaker.
VoiceTrkParms struc
dw 4 dup (?) ; pushed BP, ES and return address
StartOffset dw ? ; offset of address of voice track buffer
StartSegment dw ? ; segment address of voice track buffer
TrackLength dw ? ; Length of voice track
VoiceTrkParms ends
.model large
.code
public _VoiceTrk
_VoiceTrk proc far
push bp
push es
mov bp,sp
mov si,StartOffset[bp]
mov es,StartSegment[bp]
mov cx,TrackLength[bp]
in al,61h
push ax
mov ah,1Fh
and al,0FCh
out 61h,al
mov bp,0
cli
OuterLoop:
mov dh,0
mov dl,es:[si+bp]
test dl,ah
jz InnerLoop
or al,2
out 61h,al
InnerLoop:
cmp dl,dh
jne NoShutDown
and al,0FCh
out 61h,al
NoShutDown:
inc dh
cmp dh,32
jne InnerLoop
inc bp
loop OuterLoop
sti
pop ax
out 61h,al
pop es
pop bp
retf
_VoiceTrk endp
end
_________________________________________________________________________________________________________
Programming MC Kids
Gregg Iz-Tavares and Dan Chang
M.C. Kids (That's Em Cee Kids)
In this article, we take an in-depth look at programming a Nintendo Entertainment System (NES) “platform game”.
The Development Team
Four people, Darren Bartlett, Gregg Iz-Tavares, Dan Chang, and Charles Deenen, created M.C. Kids in about eight months. Darren designed the levels, laid-out the maps and drew most of the artwork. Gregg and Dan programmed the game and the tools needed to implement the game. Charles composed the music, created the sound effects, and programmed the music driver. By today’s standards, this is a rather small team; look at the credits for some other platform games, and you’ll see perhaps six artists, five level designers, one musician, one sound effects person, and five programmers!
NES Capabilities
Here is a summary of a Nintendo’s features:
• Up to 256K of program ROM
• Up to 256K of character (graphics) ROM
• 256 background characters images available at once, each 8x8 pixels in size
• 256 sprite images available at once, each 8x8 pixels in size
• 64 sprites, each 8x8 pixels in size, with up to three colors.
• Three sound channels, one noise channel, and one DMA sample channel for playing samples.
• Four screen palettes of three colors, four sprite palettes of three colors and one background color.
• 2K program and 2K video RAM built-in
You may expand the RAM by including it in your cartridge. You may add 8K of RAM to the program (direct CPU addressable) side, which allows you to keep track of more game information. You may also add 8K of RAM to the video side, which allows you to have four display screens instead of the normal two, and also allows you to re-define your characters and sprites. Without 8K of RAM on the video side your graphic images (character font and sprites images) must be hard-coded into ROM.
Most video game systems use a character set and sprite system for displaying graphics. Unlike most home computers today that use a bitmapped display for graphics, the game systems have just a character mode. This character mode is very similar to the text mode on an EGA or VGA card. On a VGA card you can install your own font into the card’s RAM through software (this is how the Norton Utilities 6.0 gets its spiffy look). On the NES you MUST install your own font because it doesn’t have one built in. If you redefined all or most of the font characters to be pictures then you could make graphic games in text mode. Almost all video game systems work this way, including most systems at the arcade. What makes the video game systems look so good is that unlike VGA text mode in which each character can only have 2 of 16 colors, an NES character can have 4 of about 51 colors. Other systems like the SNES (Super NES) can have characters with up to 256 of 32768 colors.
The advantage of a character-based game is that the entire screen takes far less memory to manipulate. An NES screen is 32 characters across by 30 characters down, and requires only 960 bytes to represent. This is much less memory to deal with than say an MCGA screen (64000 bytes), a Mac Plus screen (about 22000 bytes), or even a CGA screen (16000 bytes).
Most video game systems also have what we call sprites. A sprite is a shape you can define and display in front of the text/graphics screen. Sprites are very much like those plastic colorforms found at toy stores. You can place them anywhere and they do not affect the picture behind them. On the NES you can display 64 8x8 pixel sprites, each with 3 colors. If more than 8 are displayed on the same horizontal scan line then the higher number sprites will not be display on that line. You must design around this. If you’ve played Super Mario 2 or 3 and you see Mario and 4 monsters there are around 24 sprites on the screen. If all the monsters are on the same horizontal strip you will notice the sprites flicker. This flickering was programmed because if it wasn’t then one of the monsters or Mario would disappear.
On the NES, you can create 4 screens and 4 sprite palettes, each of which are 3 colors plus one global background color. Sprites and screen characters can choose which of their 4 palettes to be displayed in. This allows you to display 25 colors on the screen without resorting to tricks.
The 6502 can only address 64K of memory so the ROMs are bank switched. You can purchase different bank switching schemes for your cartridge like 16K banks or 8K banks for the program ROM and 4K to 1K banks on the graphics ROM.
You can also purchase a battery in your cartridge with the 8K of program RAM so it will be persistent (i.e., you can save your game) and you can purchase a timer interrupt if your product needs it for sound or special video tricks. Each of these cartridge extras raises the production price of your cartridge by a couple of dollars. If you plan to sell a hundred thousand or more cartridges, a couple of extra dollars per cartridge can really add up to lots of lost profit so usually you need to design your game to keep the cost as low as possible.
Platform Games
In a platform game, you control an on-screen character who walks on platforms. Another common term for these types of games is “a ledges and ladders game” since most of them have ledges (platforms) to stand on and ladders to climb up or down between platforms.
Platform games have been around for a long time. The first I know of was an arcade game called Space Panic by Gremlin which was quickly copied to the Apple II to become Apple Panic and Lode Runner. Other early platform games are Donkey Kong, Kangaroo, Mappy and Mario-Bros. In the early 80’s a game called Pac-Land hit the arcades. It was the first platform game in which one of the goals was to collect lots of items and also the first platform game to scroll. It was not a big hit but it’s ideas were soon adopted into most platform games.
The next big improvement came with Super Mario Bros. Up until that time most platform games had only one goal - stay alive as long as possible. The games had few levels, but a player could, if skilled enough, play the game forever. Super Mario Bros was one of the first platform games to add an adventure element and an ending. In Super Mario Bros the object is to save the princess, and to do it the player has to play through a large number of levels. Super Mario Bros had about 32 levels. Once the player finishes all 32 levels the game is over; you’ve “rescued the princess”.
Today’s platform games have added quite a few new twists to the older designs. The Mario series is considered the standard against which all other platform games are compared. Mario 2 had 23 levels and added your choice of four characters, each with different abilities. It also added vastly better graphics and about twice the object types as Mario 1. Mario 3 had 88 levels, and instead of different characters, you had different suits, each suit giving the player new abilities. Mario 4, with its 64 levels, added quite a few more object types.This Mario was designed to be completed: you rarely run out of lives, and you can save your progress every step of the way.
M.C. Kids
In M.C. Kids the Hamburglar has stolen Ronald’s magic bag and you, as Mick or Mack, must find the magic bag before Hamburglar does something we’ll all regret. You start out at Ronald’s Clubhouse and must find at least four of Ronald’s magic cards before he can send you on to Birdie’s Treehouse.
The game starts with a brief intro and then shows one of the M.C. Kids on a top-down map showing 6 levels and the clubhouse. The player can guide the kid down the connecting paths to the various levels. Upon entering a level the view changes to the traditional side view for a platform game. The player now proceeds through the level attempting to find at least one magic card and then finding the exit from the level. Once enough magic cards have been collected the player visits the host of the current land who sends the player on to the next land.
Throughout each level the player encounters various objects that may help or hinder him on his way. Springboards spring him high into the sky. Moving Platforms carry him to hidden destinations. Creatures of various sorts bite him. PickupBlocks can be carried and thrown at the creatures to knock them off the platforms.
M.C.Kids has about 43 playable levels with over 28 different creatures, 16 types of objects to manipulate and 27 distinct types of platforms, each with many variations.
Game Levels
Levels can be any size up to about 20 NES screens. The largest level requires 5120 bytes in RAM; each byte represents one 16x16 pixel tile (four 8x8 pixel characters). If we had chosen 8x8 pixel tiles, the same maps would have required four times the memory or 20480 bytes. The levels are stored compressed in ROM, in about one-third the uncompressed size. Without compression, we couldn’t have even fit half of the levels.
By unpacking the levels into RAM, we gained the ability to change the level during play. For example, the player can pick things up like Arches, Blocks, 1Ups, Cards and so forth that start off as part of the level. We attempted to reduce the cartridge cost by designing the game without the optional 8K program RAM. Each 16x16 tile would have a flag represented by one bit in RAM; the entire map’s flags would take 640 bytes to represent. Each bit would represent whether the tile should be displayed as itself or as its alternate (see description of the seventh tileset byte, below). However, we deemed this solution sub-optimal, and we lobbied successfully for the extra 8K of program RAM. Without the extra RAM, we would have most likely have been forced to redesign the game either so levels didn’t have to be modifed or so that it only scrolled in one direction. Super Mario Bros 1 has no RAM, and their solution was to only scroll in one direction. By scrolling in only one direction, the program does not need to remember items collected or affected by the player, because once an item has scrolled off the screen, it will never be seen again.
Tilesets
Each tile type has associated with it seven attribute bytes. The first four bytes define which characters to put in screen memory for each corner of the tile. The fifth byte defines which colorset the tile uses (0..255). The sixth byte specifies which type of tile it is (0..255). Some of the type values are: 0 = Sky, 1= Solid, 2 = Sloped left, $30 = Arch, $31 = Card, $17 = Falling Bridge. The seventh byte defines what the tile may change to if necessary. (E.g., collecting an Arch changes it to a blank sky tile, digging a piece of sand tile changes it to a dino bone tile.)
Each tile also has 5 collision routines (see Collisions below), 2 contour tables and various flags including:
AT_BEHIND: If an object touches (collides with) this tile the object’s sprites should be displayed behind the tile. This is used for tiles like clouds, lava and fences.
AT_EYES: If the player collides with this tile, eye sprites will be displayed. This makes the player’s eyes show through the clouds.
AT_ABOVE: If a hill tile can be placed on top of this tile this flag will be set. (See Collisions, problem 1)
Each Tileset may contain up to 64 characters and at most 64 tiles. A tileset can use no more than 4 colorsets (since the NES can only display 4 character palettes).
Each level in the game may consist of up to four different tilesets. Every level uses the GLOBALS tileset that contains global items like the ending line, golden arches, pickup blocks, etc. Other tilesets include GRASS, FOREST, and LAVA where the GRASS tileset has lots of green tiles, the FOREST tileset has tiles for trees and leaves and the LAVA tileset has lava and rocks and burning bridge tiles. There are about 44 tilesets in M.C. Kids to choose from.
In the above example the tile at position 0,0 in the map is retrieved. It is tile 4. Looking into the tables we pull out the four characters that make up tile 4 and place them in their proper positions to create a 1Up block (extra life). We also note that the tile uses colorset 1 and is of type X.
Shapes and Animation
A shape is several 8x8 sprites grouped together. There are 364 shapes, and 213 “animations” using those shapes. The shape tables take almost 8K to represent and we used a fairly compact format for the majority of shapes. There are two formats. The first format requires sprites to be placed in an 8x8 grid:
Colorset (0-15),
X Pixel offset (+/- 127)
Y Pixel offset (+/- 127)
Width in 8x8 sprites
Height in 8x8 sprites
(Width by Height sprite numbers (0-127))
The second format allows the sprites to be placed anywhere relative to each other:
Colorset
REPEAT {
X Pixel offset (+/- 127)
Y Pixel offset (+/- 127)
Sprite Number (0-127)
}
END Marker.
The second format also has a special “change color set” code. If the X Pixel offset is $80 (-128), then the next byte is the new colorset for the rest of the sprites. This allows one shape to use many colorsets.
I’ve also seen a more compact format, which is something like this:
Colorset (0-15),
X Pixel offset (+/- 127)
Y Pixel offset (+/- 127)
Width in 8x8 sprites
Height in 8x8 sprites
First Sprite Number (0-127)
In this format, if the first sprite number is 17, the width is two, and the height is three, then the shape would use sprites 17, 18, 19, 20, 21 and 22.
Shapes default to facing right. Flipping a shape faces it to the left. Most shape’s “hot spots” are at the bottom center pixel:
An animation specifies the order and duration for a list of shapes:
SPGopher1,4
SPGopher2,4
0
The ’0’ marks the end of the animation at which point it repeats. When the animation starts to repeat, the system notifies the object routine, which can then modify its behavior. (The Object routine will be explained in Part Two.)
The duration is represented by six bits, so the longest any given shape can remain displayed is 63 ticks (63/60 second). The other two bits specify flipping the shape in the X or Y direction. This flipping information is in addition to the object-controlled flipping of a shape.
If I were to do it again, I would add positional information into the system so that an animation could move an object. a
Part Two of this article will discuss objects, collisions, and terrain.
_________________________________________________________________________________________________________
Lessons from Patton Strikes Back
Chris Crawford
This essay will not be a chronological history of the Patton Strikes Back project. Instead, it will be an anecdotal history, flitting from point to point in the history of the project to make its points.
Lesson 1: Start with a clear mission statement
This was one of the best things I did with this project. From the very outset, I knew exactly what I wanted to accomplish with the design. Too many designers, I suspect, start off with fuzzy goals. The worst manifestation of this is the inane goal, "We’re gonna make this the greatest game of its type ever made!" That’s not a goal, that’s a fantasy. Sure, it’s good to have fantasies, but their pragmatic value is almost nil.
A clear mission statement is useful because it has direct pragmatic value during the course of a project. The essence of game design is decision-making; a designer makes thousands of decisions during the course of a project. These are never easy or simple decisions. You are not presented with choices between the beautiful, glorious, wonderful way to do the job and the ugly, scuzzy, nasty way to do it. Your choice is always between options with different merits. Option A has better graphics; Option B has better sound. Option A has better gameplay, while B offers a better user interface. "A" takes more RAM, but "B" guzzles more cycles. "A" will be harder to program, but "B" will require more expensive artwork. How then do you choose between the two options?
The nitwits among us will immediately pipe up with a seemingly simple answer: "I’ll just evaluate the merits of the two options, and I’ll pick the better option." Right -- and maybe you’ll get your game finished in time to take advantage of the new 80886 features. You don’t have time to carefully weigh all the factors. You need to make a decision NOW!
This is one advantage of the clear mission statement: it simplifies the decision-making process. Instead of asking, "Which option is better?" you need instead ask only, "Which option better fits my mission statement?" This latter question is more precise, more specific, and therefore easier to answer. More important, it is faster to answer. The bulk of a game designer’s important work is making decisions about what to include and what to pass up; anything that makes this difficult process faster and more reliable is worthwhile.
With Patton Strikes Back, I established a clear mission statement in the very first week of work: this was to be "a wargame for the rest of us." I believe that there are too many complex wargames, games designed for the hobbyists and wargame fanatics. I wanted to make a game that would show regular people just how interesting a wargame could be. This meant that I would have to risk the ire of the aficionados and design a game that would emphasize ease of use and accessibility over complexity, a game in which it is more important to be up and playing in ten minutes than to be still playing after 100 hours. The precise mission statement made the entire design process move more quickly.
Lesson #2: From Miss Goody Two-Shoes to Hairy Hacker
Programmers are always conflicted over the problem of hacking. We all know that we really shouldn’t hack our code, that it should be clean, well-designed code with good structure. But structure takes planning and time, and ofttimes we don’t know enough about our destination to plan our route that carefully, or we’re in too much of a rush to plan, so we hack. Yet we also know that hacked code is so brittle that, over the long run, it takes more time to debug and maintain than properly structured code. Hence the continuing dilemma: should we be Goodie Two-Shoes programmers or hackers?
This is one of those religious issues for which one man’s opinion is just as good as another’s, but I finally came up with an approach that seems clear to me. The value of Goody Two-Shoes code lies in the ease with which it can be modified and corrected after it has been written. Game projects tend to be fire-and-forget; once it’s out the door, we no longer have the option of modification or correction. This implies that our need for Goody Two-Shoes code diminishes late in the project, when we are pressed for time anyway. On the other hand, the early stages of a game project have us writing code that we know will change considerably later on. This suggests that we start the project writing Goody Two-Shoes code and gradually shift our emphasis to hacking as the deadline closes in on us.
However, there is another time scale to consider: the short-term time scale in which we write up a single feature. Most game programming is in some way experimental; any feature that is fully understood is probably obsolete in our fast-moving industry. Thus, we spend a lot of time inventing wheels. You can’t plan such code in advance; you just have to wade in and hack until you figure it out. The conclusion I came to is this: hack first, then recode it right.
So we get opposite recommendations for different time scales. For the long time scale, structure, then hack; for the short time scale, hack, then structure. If you think of this as a religious issue, I think you’ll find my solution very Eastern.
Lesson #3: Don’t be seduced by the cleverness of your own ideas.
This was the single biggest mistake I made with Patton Strikes Back. I came up with a truly clever idea: a large-scale scrolling tactical map in which unit sizes would be indicative of unit strengths. Now, this is indeed a damn good idea, and I was justifiably proud of it. But it caused too many problems. The IBM PC translation just couldn’t be done. The tactical map turned out to be clumsy to use. Most players eschewed it. I should have had the courage to dump a clever idea that, in the final analysis, created more problems than it solved. I didn’t, and the game suffered for it.
Lesson #4: Bake the cake first, then add the icing
Publishers sell games in the same way that bakers sell cake. The customer doesn’t taste the cake until he gets it home; all he sees in the store is the icing. So bakers don’t sell cake; they sell icing. In the same way, most publishers don’t give a damn about gameplay (cake); all they care about are the graphics and sound (icing). So when you show off your game to a prospective publisher, he won’t ask about the gameplay, he’ll want to know about the icing. Eager to make the sale, you’ll get sucked into a lengthy discussion of the finer points of icing, and end up making lots of promises to go home and improve the icing before the publisher makes a commitment to the product.
Of course, once you’ve got the contract, things don’t change; the publisher will continue to decry the many cosmetic deficiencies in the product, so you’ll spend all your time beefing up the icing, adding more curlicues and multicolor roses and three-color borders. You tell yourself that you’ll get to the gameplay sometime soon, but the demands from the publisher never stop, and you never get time to bake the cake. You’ll end up with a beautiful mound of icing with no cake inside -- which is in fact the way most games ship.
With Patton Strikes Back, I baked the cake before I even showed it to any publisher. I designed and developed the game first. I finished all the basic game structures, wrote and tuned the artificial intelligence, even got much of the play balance worked out. Only then did I show it to publishers. Guess what they wanted? More icing! At that point, it was easy. Having finished the cake, it was easy to pile the icing on. I added Multimedia Newsreels with Actual Combat Footage and Realistic Digitized Combat Sounds wowie-zowie! I added personal anecdotes with Actual Digitized Photographs. It was easy. It was mindless. And it made the publisher so happy.
It’s a lot easier to bake the cake and then add the icing than the other way around. Ever tried to slip a cake under a pile of icing?
Lesson #5: There ain’t no rest of us
The game was released to the world in December of 1991. It received excellent reviews. Indeed, I have yet to encounter a single negative or even lukewarm review. Unfortunately, it has not sold well. I have broken even on my out-of-pocket costs, not much more. It would seem that "the rest of us" aren’t buying computer wargames. The aficionados certainly hated it. "Too easy to beat," they sniffed. "Only good for a few dozen hours of play." Without the support of the aficionados, the game withered. It’s still on the shelves, largely because of continuing favorable reviews and a steep price reduction. But I will never make a significant income from the game. Lesson #5 is, I think, the most important lesson to learn from Patton Strikes Back.
_________________________________________________________________________________________________________
