Lessons from the Atari Age
An article in Sunday's Boston Globe reminded me of some lessons learned early in my career. The interview with Nick Montfort discussed the early days of home video games, specifically the Atari 2600 game system. This was the first mass market home video game system. It used software cartridges for each game, leading to quite a large market for game sales.
Right out of MIT, I worked at a company called General Computer Corporation, now GCC Printers. The company had struck a deal with Atari to develop home versions of popular arcade games. As Nick Montfort mentioned, the graphics system of the Atari 2600 was very crude. If you look at the original games developed by Atari, such as Pac Man, you'd be disappointed. The graphics, the game play, the sounds, and the whole experience was unsatisfying. Obviously, having limited hardware made it very challenging to develop a great game.
But, the first lesson I learned at GCC was to question everything I had learned before. At college, we learned structured programming, which basically means "follow the rules." It certainly works well and is the right thing to do. But, it only works when the hardware has the resources to support it. With the Atari 2600, the hardware resources were incredibly constrained. It sounds almost prehistoric to say that the system had 128 bytes (not kilo- or megabytes, just bytes) of RAM to store the state of the game. The cartridges generally had
8K 4K (and later 16K 8K) of ROM to store the game code. An empty Word document is bigger than this.
When faced with incredible constraints, we had to innovate. Here's a screenshot from Pac-Man, developed by Atari:
And, a screen shot from Ms. Pac-Man, developed by GCC (not me).
You can see that Ms. Pac-Man had more detail to the characters and the 'fruit' prizes. And, the main character would rotate when it moved in different directions. Now, these both pale in comparison to the types of graphics done today. But, those two games were developed on the same hardware. The difference wasn't that our engineers were smarter. It was that we we willing to question all the assumptions. There was documentation that Atari wrote that described how to use the graphics chip in the 2600. The early games they wrote took that as gospel. We took it as a challenge to be overcome. We looked for tricks and hacks that would let us work around the limitations of that hardware, rather than being limited by it. It was the most fun I've ever had with a computer!
By the way, Nick Montfort gave a tight schedule as one reason why the original Pac-Man game was poorly done. Our typical game development time for a 2600 game was 2-3 months with 2 engineers, plus graphics and sound designers. Time was just another constraint to overcome, mostly with caffeine.
The lesson for today is that we are again in a time of resource limitations. It's a time to question the assumptions and to use that resource limitation as an opportunity rather than a barrier. You can do a lot with a little if you think outside the box. And, that's where the biggest wins will come from.
(Note: GCC had a great team of engineers that I was proud to be a part of. We worked hard, had fun, and achieved a lot. The original team inspired me to work harder than I ever did in my life. Thanks to them, I had many opportunities. For those of you who are curious, the primary game projects I worked on at GCC were (for the 2600): Phoenix, Jungle Hunt, Battlezone, and Joust (better screenshot here), and for the 7800, Desert Falcon.)
(Second Note: These old games are still popular today because of their simplicity. Sometimes, you just want to play a basic game that you can walk away from. You kind of already know how to play, and a game is over in a few minutes. The casual games are one reason why older people, like me, are back into playing computer games.)
Updated to fix broken Joust links. Also, my former colleagues confirmed that I was wrong about the cartridge capacity in my original post. Now corrected.