Some memories of my stint at Atari, brought to the surface by a cow-orker who, it turns out, did a lot of work on some Atari platforms in the mid and late 80s, and we got to talking a couple days ago…
The 400/800 Super Pac-Man Cartridge
The reason that Super Pac-Man is the best arcade conversion that I ever did is that nobody really cared about it. I knew from the very first that it was a “loser” title, an oddball member of the Pac-Man pantheon that no one really understood, and the likelyhood of the cartridge actually shipping was pretty low. During development it was an orphan in marketing, and I swear there were at least three back-to-back Mondays when a new marketroid appeared in my office, said “I’m responsible for this game, tell me about it,” then I’d never see them again. Since no one truly cared, I got a good solid nine months of development time on the game — when most titles were being shoved out the door, ready or not — with around six calendar months, and I think that the extra effort shows.
How it happened: After shipping Donkey Kong I wound up with a terrible manager. I was itching to work on another title as hot as ‘Kong had been, but everyone else seemed to be getting the interesting work. Weeks went by while I twiddled my thumbs [I wasn’t goofing off, I was reading some CS texts, mucking with the shiny new Vaxes our group had been given, and writing some development tools, but still…]. Finally I was told to look at “Kangaroo” and “Arabian,” two games that I thought were really bad. I wrote some nasty memos about how miserable those two games were.
Finally my boss said, “Okay, work on this Super Pac-Man thing.” It sure looked better than Kangaroo, or (shudder) Arabian.
The department bought an arcade machine that I could play, and people pretty much forgot about me. Nobody cared. Apparently someone in marketing would draw the occasional short straw and show up in my office, then they’d have their heads chopped off or something because I never got another visit. Atari was pretty turbulent back then. It was easy to get lost in the shuffles.
You’d think that the conversions group would have help from the companies who wrote the arcade games we were reimplementing — listings, design documents, the opportunity to talk to the original engineers, that kind of thing — but in fact Atari had negotiated nothing but a license to make a cartridge version of the game. Atari even had to buy their own copy of the arcade game. This was pretty classic negotiating for Atari: Negotiate a hot deal with no thought to the technical issues, then wonder why the engineering didn’t “just happen” in a week or two.
Things like listings might not have helped anyway. In the consumer games industry, commenting code was kind of a luxury; you shipped something that played okay and moved on to the next title. There was essentially no code re-use. The 400/800 Pac-Man cartridge TWO comments; I forget the first, but the second was something like “ha ha,” at the single point in the ROM’s copy protection where it stored to itself in a rather lame attempt at committing suicide.
What we did in the absence of help from the original authors of a game was: We’d play the arcade game, video tape the action and use that as a basis for the artwork and finer points of the game play. We had to get pretty good at the arcade version.
The best commented code I ever saw in the games industry was the stuff responsible for actually doing the “quarter sucking” in the arcade machines. Talk about tough! It had to deal with real-world timing, anti-theft issues, international currency, and things like the coin box getting full. If this code failed and swallowed the customers’ money, they might destroy the machine in revenge.
Machine Resource Allocation
On the 400/800 I noticed that people knee-jerked toward using the player-missile hardware way too early in the design process, and that these special resources tended to blind people to the box’s real power. It was like all the whizzy hardware was allocated in the first five minutes and creative alternatives were never considered — “Of course the thing that the user controls has to be a player object.” The result was sometimes bad game play and poor looking games.
For instance: Hardware collision detection sucks in a lot of instances, but people used it because it was there to be used. The player loses a life because one of his outlying pixels happened to hit a single enemy pixel — that’s really unforgiving, and games that used it irritated the heck out of me. You know the tension when a Pac-ghost is right on your tail and you whip around a corner and get that last dot just as the ghost is about to eat you? You can’t get that feeling with pixel-perfect collision detection, the game just bloody clobbers you, and it feels mechanical and unfair. It’s like playing a tax accountant, not a fun opponent. Games like Caverns of Mars were particularly bad; real space ship crashes are messy and probably involve big noises and fire and rolling bits of fuselage. Crashing in ‘Caverns was like having a pocket calculator say “E” at you for dividing by zero; one of your ship’s pixels overlapped one of the cavern’s pixels, whoopee, game over.
So collisions in Super Pac-Man were done with cross-shaped bounding boxes on the player and the ghosts. You could overlap the ghosts slightly, get away with it and feel like you cheated the game a little.
I used character cell animation (in graphics mode 5, and that’s probably meaningful to a disturbing number of you out there) to get an extra color in the ghosts. The “super” Pac Man was seventeen pixels across rather than sixteen simply because the extra pixel made the circle a lot prettier, so it used two 8-pixel-wide players and a single extra pixel from a missile. I think I used the remaining missiles to add even more colors to the ghosts, maybe animate the eyes. (NB: A “player” is an 8-pixel wide mono-color vertical stripe the height of the screen, and a missile is a 2-pixel wide stripe. There are 4 players and 4 missiles, and they can be repositioned horizontally on a scanline-by-scanline basis).
Other touches: People complained that the cartridge versions of games didn’t have the “cartoons” (cut scenes) from the arcade. I wrote a little bytecode engine and stuck those in. I didn’t know how the ghosts “found” the Pac-Man, so there’s an N-ply recursive search algorithm in there and the ghosts search deeper in the maze as the game gets harder. I tried to duplicate some of the ghost movement patterns, but probably didn’t succeed.
Like Donkey Kong, at one point the game was about 20K of code (for a 16K cartridge), so things had to get smaller. I went for features first, then started cutting. The sound tables were the first to go on a diet. I forget most of the crunching process, but my roommate tells me that I used to come home and proudly say “I saved 18 bytes today.”
One fine day, the marketroid du jour walked into my office and asked me if I could jazz the game up a little. “Say, could you add some easter eggs?”
“I don’t know. Some secret thing that people would have to find.”
I have to admit to a complete lack of creative interest at this point. Also, there were only about 200 bytes of ROM left over, so the easter egg couldn’t be terribly extravagant. I’m afraid I utterly failed at coming up with something interesting. Then again, Atari was in the newspaper every few days with something new falling off and making loud financial noises. Most of us were pretty beaten up, morale-wise.
If you didn’t do anything to prevent it, 400/800 game cartridges could be copied to disk and then just re-loaded at the same address and run from RAM. Cartridges were starting to have some simple copy protection — mostly just code that pretty blatantly scribbled to the ROM space, trying to wipe out other code and cause a crash. In Super Pac-Man I had time to be more clever. There were several levels of protection, including some “bait” code that stomped the ROM, but if you modified the bait then game would notice that and collapse in more subtle ways.
The clever stuff involved decrypting some code in an interrupt handler over several minutes, which (when finally run) changed some constants around in the ROM that in turn caused a crash a while later. It took about two weeks to get all of this working and tested. I’d gotten my start in the games industry by cracking protection on a few disk-based titles, so this was fun to do.
A fairly prolific pirate of Atari games lived in my apartment complex. Now, the way that you got a ROM burned in the Home Computer Division of Atari was that you asked the duping lab to do it, and this lab leaked unreleased games like crazy. I was unsurprised when this pirate got hold of a fairly complete copy of the game. I asked him how long it had taken to crack. “That was a hard one,” he said, “It took us nearly three days.”
The version of Super Pac-Man that’s available for download on various web sites appears to be a late copy that leaked from the lab. There was a nasty bug that I fixed pretty late in the game, but I really don’t know if the images floating around out there have the fix or not, or even how many versions actually leaked.
I heard a rumor that Super Pac-Man was actually going to go to manufacturing, then a week or two later the Tramiels bought Atari and things got really different. I never touched 400/800 development again, except to write some development tools.
More later. I’ve got some Atari ST stuff outlined . . .