In early 1998 I talked to Richard "Rick" Maurer, of Atari 2600 Maze Craze and Space Invaders fame, for an article in the issue of Computer Graphics that I edited. The article never made it into print, but here are Richard's wonderful memories.
When I started at Atari, I read the docs on the registers for the 2600 and for the 6502. Then I read some existing games to understand what this concept of a kernel really meant. And what it means is every cycle of your computer is devoted to drawing the screen during the approximately 192 scan lines when the screen is visible. The only time to think, check collisions, keep score, is during the 70 scan lines when the blackened beam returns to the top. This concept astonished me then, and still astonishes.
It was such a complete melding of hardware and software, with the goal of being functional, yet low-cost. My first thought was "How primitive, we have to feed this machine every visible scan line. The software is supposed to operate the hardware, not devote its life to the hardware ". Another way to look at it was that the cheap microprocessor was a new thing. Just a few years before, the smartest chip in an arcade game was a four-bit adder
Games weren't assigned then. I knew how the console worked, so I scouted around for a game idea. Visited the arcades. Space Invaders just wowed me, especially the sound. So I came back and told people I would do that, they said OK. The first milestone was to design a kernel, and then get it stable enough so that you can actually see something, right or wrong, on the screen. After a few months, I got it to where it was fun to play. But few seemed to be interested in it, nobody wanted to play it, I never heard anybody talking about the arcade game. Maybe it was because it was originally an arcade game. There was a big discussion about which was better, an original game, or a clone of a successful arcade game. But nobody was playing my game, and I enjoyed playing several other games in development, so I thought there was something wrong with my game, even though I enjoyed it, besides the amount of flicker which bothered me greatly.
So I searched around for another game. What became Maze Craze was inspired by a game I enjoyed playing, done by Mike Glass for Channel F. What inspired him, I don't know. I figured that at least the kernel development for Space Invaders was a good learning experience. I deliberately made Maze Craze without a score. I worked for a few months on Maze Craze, and then...
One day, the management was in a tither (Nolan was gone by then). Some of them had found out how many quarters were going from customer' pockets into the Space Invaders machines (there were rumors of shortages of the standard arcade coin in Japan). They had a licence deal. They wanted someone to work on the game, and found it was already in progress, so I went back to it.
Perhaps it was the few months of intermission, but I was soon able to solve the flicker problem and the basic game was in place. Then I added my variations, and spent days trying to get the sound right. And I was constantly tuning, trying to figure out what made the game fun, as it could not be an exact copy of the arcade. I only saw the arcade game from the outside.
I was using convenient art for the invaders, and realized it needed better pictures. As some of the box art was well thought of, I asked if the box artist could draw the invader pictures on graph paper. Management said they'd get back to me. Several days passed. My code and I wanted to know if a two cycle picture would work, or if it needed four and how tall they had to be. And despite the earlier tither, I never did get to even talk to the artist. So I drew my own pictures, they came out better than I expected, so I didn't push the artist angle.
Finally I was satisfied; all the features I wanted were in. Up till then I used good structured programming, with many general cases. But the code was 7K and it needed to fit in 4K. So for the next three months, I scrunched code. After the first month it was ten bytes here, three bytes here, 1 byte here. Of course I also tuned the game, and even added a feature or two that cost bytes (painful). The last month was spent scrunging one or two bytes at a time. It ended with branches to branches in another routine with the same condition, all to save a byte. I wondered if anyone who read it could see the original intent and believe this was ever structured code.
Games are always at the cutting edge. We always are being boxed in by conflicting requirements. In 2600 days, it was RAM, CPU time, code space, CPU registers, player 0 register, player 1 register, missile 0, missile 1, and exact kernel timing. Today it is RAM, CPU time, code space, texture space, CPU cache, texture cache, draw time, transfer time, sound RAM, sound voices, CD buffer, CD transfer speed. The feeling is familiar. What is different is you can no longer feel your way along, throwing out weeks of work, improving vast sections of the design, when this throws out not only your own work, but that of ten other people.
It has only been a few years since games advanced beyond what I could in 1982 conceive of as economic for the home, and my dream machine is not far off. The games of two generations from now will be just astounding, that's just five years folks, and the next generation will make the Sega Genesis look as primitive as the 2600 does today. But I don't think it can compare to the thrill of someone who is 28 today, who was nine when most of the world went from nothing to Asteroids and Tempest at the arcade and the Atari 2600 at home.