Programming For Pac-Man And Pengo Hardware Game Design Considerations Scott Lawrence yorgle@gmail.com 2001-February-11 This document and all of the information in it is freely distributable. I only ask that you leave it intact, without modifying its contents. Enjoy! The most recent version of this document can be found at: http://code.google.com/p/bleu-romtools/ ======================================== GAME DESIGN ======================================== Contents: Keep It Simple Hardware Limitations Gameplay States Game Responsiveness Consideration ---------------------------------------- Keep It Simple This should be the number one consideration for every design. Complex games will require more complex code, and chances are, will be more complex to play and program. If you're working with new hardware, or have an idea as good as "Defender" then go for it, but chances are that you have neither. Keep your game design simple. Regardless of your final project size and complexity, you should always start small. Figure out some subset of the final game to make first. Then once you have something that you're comfortable with, expand upon it. Always save aside versions of your work, and always test! Constantly playtest your game. Give it to friends that you trust to test it. Pay people to test it, whatever... but constantly test it! Even if you've only added a small piece of functionality or a bug-fix, you still better make sure you didn't break something else. It's a pain, but you have to it. And obviously, if it's simpler, it will be easier to test, and there is less chance of something going wrong, or for unfindable bugs to develop. ---------------------------------------- Hardware Limitations Obviously, it would be silly to design a game for the hardware platform that would be impossible to implement. In some cases, there are workarounds, and clever tricks you can pull, but in general, you're not usually that lucky. You have a very limited amount of cpu time, number of colors, number of floating sprites, ram, etc. If you look at the game "Pengo", you might notice that it only supports 6 floating sprites, however, at any time, you have: Pengo, four snow-bees, a sliding block, a disintegrating block, a shaking wall, a hatching egg, etc. The way they do all of that simultaneously is to be clever with the foreground and background. You won't notice if something moves from the front to the back unless attention is brought to it. Disintegrating blocks, shaking walls, and half of the hatching egg animation, along with the maze itself are all in background tiles. The animations of some of these are just redrawn a frame at a time, as needed. The other parts are all done in floating sprites. At any time you will have one floating sprite for Pengo, four for snow-bees, and one for a sliding ice block. That's it. Everything else is in the bacground tiles. You can overcome limitations of your hardware by pulling clever tricks like this. moving things from the foreground to the background when they stop, without bringing attention to it. You can bring attention to it by changing its color, position, etc. The best way to really get a full grasp of the hardware is to experiment with it. Write test code to see how it performs. That's how I learned as much as I did about this hardware. Once you have a decent grasp of what it is capable of, then you can start to figure out the fine details of your game. Also know the limitations of your tools. If you are using a C-compiler, realize that it can never make code as small as coding directly in asm. That's due to the overhead of the C compiler. If you're getting close to the limitations of your ROM space, don't expect the compiler to be able to optimize it down. Be prepared to take the generated asm files, and hand optimize it if it really is that important that you have those few extra bytes. Since this hardware is not capable of scrolling finely, you will be limited to 'board' based games. You will not be able to implement side scrolling games without them looking hideously blocky. This is why most of the 'old style' games had boards where you could see everything on screen at once... there never was anything lurking on the map "just off screen". So be aware of the types of games you will and will not be able to implement on the hardware. You may want to switch to a platform that supports more floating sprites, like Dig-Dug or Galaga if you need more than 6 available. Most of the games of that era have similar hardware. With current tools like MAME and various disassemblers, It should be fairly easy to figure out how those platforms work once you have a decent understanding of this one. ---------------------------------------- Gameplay States Every arcade game, whether it be the latest Virtua Whoopass, or the oldest black and white racing game pretty much follow the same pattern for their state machine. The following states usually occur: Attract sequence - show a title screen with copyright information - show the high scores with initials or names - show instructions for how to play the game - demonstrate how to play the game - repeat until coins are dropped in. Coin insert screen - prompt the user to drop in more coins if they want two-players - sometimes this is just displayed as a number of credits during the attract sequence, replaced by a "press start" when appropriate Game play - This is up to you. The user will play the game until their lives run out or they run out of credits. - When they die that last time, perhaps prompt for more credits to continue. (This option should be disableable by the operator, either via an onscreen menu or dipswitch.) - Otherwise, check their score against the high score table. - If it belongs in there, prompt them for initials. - Some games prompt you for a complete name for the number-one position. (Tempest 2000 is one of them.) There are some games where the score granularity is based on multiples of 100 rather than for example Pac-Man which has a score based on multiples of 10. What those games do is that every time the player continues, it increments her/his score by one. They do this so any player can look at a high score of "392,119,142" and know that they continued 42 times to get such an outrageous score. The new Namco "Galaga/Ms.Pac-Man" machine should do this, but it does not. ---------------------------------------- Game Responsiveness As mentioned in the "Coding Tactics" document, one thing that can really annoy players is if their movements or coin drops do not register. One way you can account for this is to have a small event handler in the VBLANK timing interrupt. If a coin is dropped in, increment some counter somewhere... if the user just moved up, note it somewhere in ram. In the very least you should count coin drops here, so that you don't have to check for it everywhere in your code. But remember to keep your irq handler short so that it doesn't re-enter itself, which would be bad. One of the problems with the above state diagram is that you will either have to litter your code with "if"s or use the dreaded "goto" if you program in C. For example, if you're in the middle of displaying gameplay, and the user drops in a quarter, it should immediately go to the "press start" screen. You could either litter your code with if statements around everything checking for the number of credits inserted, or you could change the return value on the stack from whithin the IRQ handler to be the "press start" screen, or you could have a few well placed "if"s which check to see if coins have been dropped, and if so, goto the end of the current routine. There are many ways of doing this. Pick your favorite, experiment... but never lose quarters. Players and Operators will not like you if you do. ---------------------------------------- Consideration If you intend for your romset to be used 'in industry' or out in an arcade somewhere, it'd probably be a good idea to have some sort of Rack test of some kind on power up. Ie; the first thing you should do is clear the screen, draw some stuff, play with the floating sprite hardware, and then clear and reset it all back to 0's again. In the very least, it lets them see that the game is resetting. ;)