What did you need to be qualified applying for a job as videogame developer?
To be a game developer in the late 1970's, you needed first of all to be a proficient programmer in microprocessor assembly, and you had to have an intimate sense of what the hardware could and couldn't do, so you could push it to its limits. (The limits of the day were hugely primitive by modern standards, but they were impressive at the time.)
Given that technical base in hardware and microprocessor programming, you could develop game software. But if the games were to be any good, you'd also need to bring to the table a sense of game play, plus some artistry and artistic vision. And finally, you'd need to have ideas for what games to develop.
In my case, I had the right technical skills and a good sense of whether a game was "working" or not. So I was in a position to develop good games if I could draw on some additional skills. I was fortunate to be able to work with a couple of people who did great art (and who understood the limitations of the systems, so they could draw pictures the hardware could display without choking). The early game themes were requests from Mattel, so we had a broad sense of what was wanted (for example, Baseball or Blackjack), although of course the real work is largely in the details.
Did you work on some Mattel products before Intellivision?
My introduction to the Intellivision experimental prototype was in December of 1977. I had done some small work on Mattel handheld LED games during the summer. More relevantly to my gaming experience, I had developed the software for the arcade game of Star Fire during the fall of 1977 (although that game didn't appear on the market for another year).
How many people worked on the EXEC? How was the project organized and planned?
The EXEC might be described as the Intellivision operating system. It resided in an internal 4k ROM in the main unit, and it would handle a lot of general game maintenance, allowing the individual cartridges to devote their resources to the specifics of the individual games.
I programmed the EXEC by myself. I had the general idea of what I thought it should do, and those ideas became clearer as I developed the Baseball and Blackjack & Poker games. As we brought other game designers on board, I got input from them as well. It was a difficult period, trying to decide exactly what the EXEC should and shouldn't be doing. The idea was to provide just enough structure and support to work hand-in-glove with a game cartridge. But if I imposed too much structure on the game, then it would limit its horizons. On the other hand, for the EXEC to be maximally effective at taking the burden off the individual cartridges, it would have to make a number of assumptions about how the cartridges would function.
In the end, the EXEC ended up creating a primitive sort of event-driven object-oriented environment. The Intellivision graphics hardware supported eight "moving objects", as they were called. The EXEC would interpret cartridge data structures to define how those objects would be displayed and animated. They could be set in motion, and the cartridge would be notified when they reached a particular destination or interacted with another object. The EXEC also handled timing and the title screen and background setup and hardware resource management and sundry other details.
Would you introduce the genesis of the PicSe? What was the expected target for this one?
"PicSe" (pronounced "Pixie") was an acronym for "picture sequencer", and it was a sort of EXEC for the ill-fated Keyboard Component. This was Mattel's grand plan to convert the Intellivision into an honest-to-gosh home computer (this being before ordinary humans had home computers, so it was a visionary project). The Keyboard Component included a keyboard and a four-track cassette tape unit (two tracks for digital data, two tracks for audio; of each pair of tracks, one was read-only and one was read/write). We were developing cartridges (tape cassettes, not ROMs) with a variety of instructional and interactive themes. The tape format freed us of size limitations, so we could include almost unlimited program material, dynamically loaded. A typical cartridge would present a series of video animations. For example, a Jack LaLanne exercise cartridge would illustrate a figure going through the motions of sit-ups, push-ups, whatever. A cartridge to teach you French or Spanish would show an animated face of your speaking teacher.
The PicSe would be at the heart of the various cartridges, in that it would read and process a home-grown "picture language". We created tools for animators to build an animation sequence, thus developing an efficient process to craft and portray a long series of scenes that would be selected under program control. This would be synchronized to tape movement, such that audio data would play in harmony with the video animation. We even synchronized the lips of the "speaking" language teacher to the audio track. There were clever optimizations, such as double-buffering to allow one block of code to execute while its successor was being loaded. All in all, it was a highly complex package.
Audio and digital data could also be saved and played back. For example, in the language cartridge, the user's voice would be contrasted with the teacher's pronunciation. In the exercise cartridge, the user's statistics would be gathered and stored, so that his progress could be monitored and the regimen could dynamically be made easier or more difficult. In a financial package, stock data could be input over time so the computer could analyze and report the trends.
This was all a big effort involving a number of smart, dedicated people. Unfortunately, they weren't able to bring the Keyboard Component to market with reliable hardware at an acceptable price. There was a test market in Fresno for a short period. Those were the only Keyboard Components ever sold to the public.
To summarize, the PicSe was part of a larger development effort that was far ahead of its time, and produced some rather amazing (if I do say so myself) results. But it never reached the market. (In its place, Mattel later released a cheap, crummy keyboard, but this obligatory "keyboard component" has nothing to do with what we worked on.)
You developed also for Atari VCS. Which of the two console was easier to program? Which one you like more?
The Atari VCS represented an earlier generation of technology than the Intellivision, and it was relatively primitive. It was very difficult to develop software for the VCS. Its CPU essentially had to dynamically guide the trace down the screen, setting up the image line-by-line. That is to say, the VCS had to do mostly in software what the Intellivision graphics chip mostly did in hardware. So the VCS was more limited in its graphic display, and very challenging to work with.
Do some of the games you developed were your original ideas?
For the most part, I was requested to develop a particular theme. On my games for Mattel, they had asked, for example, for a baseball game. I was also given graphics prepared by artists. Aside from doing the programming, I was primarily responsible for doing the detail work to transform the concept into a workable game. Depending upon whom you talk to, this is either the heart of the creative process or a trivial detail that you can assign to any technician.
When I worked for Activision, we developed our own game concepts. For my Activision games - Beamrider and Steamroller - I give credit to Tom Loughry for creating the theme and graphics.
Are there projects that you did not / could not develop?
I'm not sure if this is quite what you're asking, but my greatest regret was the cancellation of the Keyboard Component. We did a really amazing job on that.
What is your preferred project you worked on?
In a way, I've liked everything I've done. My favorite single-player may be Beamrider, and my favorite two-player was Baseball. The arcade game of Fire One! may have been the most elaborate environment I ever created, so it's got a special place in my heart. The Keyboard Component project was one of the greatest collaborative efforts I ever worked on.
What is your best memory of your gaming background?
I was just a kid out of college, really, and I got a huge kick out of going to a trade show or a major store and seeing stuff I developed on the shelves. And I also enjoyed the idea that my work was being used and enjoyed all over the world. I'm happy that people still remember the old games.
What do you do today? Are you still involved in the game industry?
These days I'm developing control software for equipment that measures the hysteresis (memory) of thin-film magnetic materials. So, broadly speaking, I'm doing the same work I've always done: Programming systems to make it easy for the operator to complete his task. It used to be entertainment and now it’s test equipment, but that's what I do, bridge the gap between the hardware and the user.
The modern game industry is vastly different from the classic days. It's more like movie-making and less like engineering. I have no involvement in it, and that's fine by me. In my heart, I'm an engineer, not a game designer.
The last generation games are very different from the origin. Do you like videogames of today?
This may sound odd, but I'm not really a gamer, and I never have been. I was always most animated by making the computer do exciting things for me and for others. I liked to develop games because other people liked games. I'm not saying that I disliked games. I've enjoyed some games that caught my eye. Some of these modern games amaze me. They're almost miraculous in their ability to immerse you in an alien environment. I've found, for example, Half Life 2 to be entirely addicting. And I bought the most recent Leisure Suit Larry outing because I'm a long-term fan. So, yes, I have to say I like the new games. But I can't really compare them to the classic games. They're an entirely different animal. |
