Chapter 16. Energy Czar

In early 1980, having met my obligation to design a game for the Video Computer System (VCS), I eagerly set to work learning the Home Computer System (HCS). It was quite a challenge; the documentation was fragmented and not very helpful. At the same time, I was casting about for a game idea. I proposed to my supervisor, Dale Yocum, that I build an educational game on energy/environment/economics issues. As it happens, I had built a crude version of such a game and declared it on my Inventions and Patents agreement with Atari, so it was technically my property. He agreed that, if I could build a game good enough to pass muster with marketing, then Atari would pay me $2,000 for my rights to the design. I set to work on initial design considerations and then made my first design presentation to the marketing staff.

The marketing people at Atari had a tough job. They had to sell home computers into homes that didn't know what a computer was. They had to work with geeky programmers who saw all software as a gift bestowed on users by beneficent programmers who knew what was best for users. And they had absolutely no market history on which to draw; this was completely virgin territory.

One of the few decisions that they were confident in was the decision to clearly differentiate the home computer from the videogames machine. They did not want the HCS to be dismissed as a toy, nor did they want it cannibalizing sales of the VCS. So the rule was simple: no more games. A bunch of games had been produced for the HCS during its design phase, including Star Raiders, which was what we now call a "killer app"; people were willing to buy the computer just to play the game. This and the other games provided a strong starting library; now we had to flesh out the line with serious applications. Therefore, marketing made it known that for the time being, it would approve no more games proposals.

Dale and I had therefore agreed to present the design as an "educational simulation," not a game. I was understandably nervous on the morning of the presentation; I had 30 minutes to make my case to these strangers. Still, my experience as a public speaker served me well, and in my allotted time, I made all the important points. At the end of my presentation, the VP of marketing, a brilliant and thoroughly likable fellow named Peter Rosenthal, fixed me with a hard stare and asked me, "Is this a game?" I gulped; I could see the suspicion in his eyes. "No, no," I assured him. "It's an educational simulation!" I declared with hopeful confidence. "I don't know," Peter mulled skeptically. "It sure looks fun to me." I was dismissed and waited in anxious helplessness for several days. Then one day Dale came into my office and announced the good news: The project had been approved.

The basic design was ridiculously simple: It was just a small set of coupled first-order differential equations Lunar Lander writ large. The player could set taxes or subsidies on each of several different energy sources: oil, coal, natural gas, nuclear, solar, and wind. The taxes gained from one energy source could be used to subsidize another. Each energy source generated a certain amount of pollution. The player then balanced the tax structure to obtain the best combination of energy prices and low pollution.

The program was written entirely in BASIC. I had the skills to write it in Assembler, but it was so much easier to work in BASIC that all of us just assumed that we'd use BASIC. The program did nothing more than display bar graphs of the various numbers coming out of the simulation. I jazzed it up a little by adding sounds as the bars were drawn. Right at the end of the project, while marketing was reviewing it, I figured out display list interrupts on the Atari and how to set them up in BASIC. This enabled me to draw the bar charts in many different colors.

The only interesting design lesson from this project was the fight I had with my supervisor, Dale Yocum, over user friendliness. At that time, I was very much the programming geek. I clearly recall an unpleasant meeting with Dale where he picked through my software, demonstrating points of confusion. What would happen if the user did this at such and such a point? What if he did that? The problems he was citing were all matters of input bounds, such as if the player typed a 9 when the largest admissible value was a 5, for example, or a D when the only meaningful inputs were A, B, or C. I thought his objections were silly if the user were serious about using the program, it was reasonable for me to demand that he read the manual. I didn't say it, but I was giving voice to one of the oldest cop-outs used by programmers: the disdainful command "RTFM!" (Read The Manual!) Programmers seem to feel that, having laid down the rules and regulations of the program, they have satisfied their responsibilities; any user too lazy to read and obey those rules and regulations deserves everything he gets. And I was right there with them, my nose in the air and my self-righteousness waving proudly.

Dale was endlessly patient with me, trying to explain that paying customers shouldn't have to undergo such treatment; our job was to make their experience as pleasant and rewarding as possible. I wouldn't budge. So Dale appealed to my vanity, pointing out that poorly human-engineered programs were a dime a dozen and that only a few could boast truly clean user interfaces. It didn't work; my stubbornness exceeded my vanity. In the end, Dale had to order me to fix the problems.

LESSON 36

Young programmers can be stubborn asses.

I have come a long ways since then, and I now embrace user friendliness to a degree that goes well beyond what most programmers are comfortable with. I'm also more open to suggestions that I don't like hearing. But it's important to remember that, in my own youth and the youth of the industry, the concept of user friendliness was poorly developed and had little support.