October 1st, 2007 by Rob

Spring, 1984. The videogame business was taking a severe nosedive. Leaving Imagic had been difficult for me. I missed the infrastructure of the organization I had been a founding member of. I missed the security of a regular paycheck, as well as the quarterly royalties from Demon Attack, Cosmic Ark, and Fathom. Most of all, I missed my colleagues, some of whom I had worked side-by-side with since I started at Atari. It was hard for me to accept that Imagic was gone. I didn’t really understand what had happened. We had all worked hard, we had done some great games that enjoyed a lot of market success, we were in all the game magazines. The creeping thought that “videogames are really over” was not a possibility I was prepared to accept. Not yet.

I had my mind made up to make a game on my own. It would be so easy … a piece of cake. I purchased a Kontron development system, a 6502 compiler, and some office equipment, and had everything delivered to a little office I had rented a few miles from my Palo Alto apartment. I even had a vague notion of a game that I thought was a “natural” at the time.

The early 1980s had featured the introduction of several low cost home computers. “Programming” was all the rage in high schools. Technology ‘bandits’ known as “Hackers” were becoming cultural icons. And in the world of stuff for kids, robots had essentially taken over popular culture. Robots were EVERYWHERE. I’d walk into a newstand, robots were on the cover of major magazines. I’d turn on the TV on Saturday morning, most of the shows featured armies of robots forever battling, speaking in deep mech like voices. Toys R Us morphed into Transformers R’ Us. Many robots came from Japan, the hippest ones of all still featuring their original Kanji packaging, which instantly branded the contents as obviously MUCH cooler since it was Japanese.

I set out to make a game featuring a programmable robot. Such occured to me at the time as a “natural”. My goal was to create a simple and fun programming game, with the principal challenge consisting of the experience of “debugging” - doing the basic “how did I blow it THIS time” shuffle .. a familiar dance near and dear to the heart on anybody whose written even the simplest BASIC program.

The idea was pretty basic. A robot on the screen would be controlled by a linear series of ‘commands’, it’s program if you will. There would be four commands to start with … consisting of the most primitive things a robot could be told to do. The player needed to get the robot to acheive a number of onscreen objectives.

Actionauts (the early working name was “Microbots”) consists of two screens. The main play screen features a single robot in a simple playfield maze, a “target”, in this case a piece of cheese, and a vertically scrolling command display at the bottom of the screen. Every time a command rolls off the screen, the robot ‘executes’ that command. Player control in this mode is limited to setting the speed of the system, indicated at the bottom right, and starting/stopping the robot’s execution of it’s commands. The object of the game is to create the proper sequence of instructions so that the Robot reaches the cheese.

ACTIONAUTS MAIN SCREEN

Obviously the Robot won’t always get to the cheese, due to faulty ‘logic’ on the part of the player. When the robot crashes and can no longer make any progress, the player can switch to the “program editor”, where they have control over the sequence of commands the robot will execute when it next ‘runs’.

Switiching modes causes the program screen to segue front and center (I was especially proud of the seamless segue effect which helped keep continuity as to “where” the player was in relation to the two screens.

On the programming screen, users scroll a blinking cursor up and down through the various commands, with left/right joystick used to scroll through the four possible commands for each ‘link’ in the chain. When the player thinks the sequence is “ready” … a quick tap of the joystick returns to the Main Screen, where the robot runs through the program again.

ACTIONAUTS PROGRAMMING SCREEN

The play challenge in the game comes primarily from “debugging” .. with the player needing to remember what the robot last did, what went wrong, and find /fix the appropriate command (s). There are nine playfields in the game.

By June, 1984 it become pretty clear that there was no longer any sort of viable market for Stella games. At that time, Actionauts was basically in it’s current state. The program editor screen was there, the interface reasonably smooth, and pretty easy to get around. The Main Screen was functional, yet not “polished” in terms of visual appeal. I had planned a more robotic looking central character, and the cheese was just a cardboard ‘prop’ simply to get the game functional. also had always intended a secondary character, primarily to serve as ‘conflict’ in later levels. I also was planning to add a significant number of additional levels beyond the nine that now exist. In terms of development, I consider Actionauts about 1/2 way completed.

People ask why the back end of the game is solid, while the front end is not as polished. Such is because I was then, and still am today, a firm believer in building games “backwards” In other words, I get the game up and going as soon as possible, typically crafting the first level to be as hard as I think it should be. Then I build backwards from the hardest level. This way, the first level of the game, which is the one that the player will see right away, is only undertaken when I know as MUCH as possible about the contents of the game itself. Also, by the end, I’m about as good as I’m ever are going to get at crafting levels for this particular game, which is important because it’s the early levels that get the most play. A lot of designers build their games front-to-back, so that the first levels the player encountered, are also the first levels the designer had built. Night Driver was the only game I did front to back. And such is why Night Driver has a gawd awful ramp in terms of moving the player through a learning curve. And that’s why Actionauts isn’t as polished when one first fires it up … I started at the end, with the programming part … and never got to the ‘beginning’ since there was not a lot for the player to do on the main screen but watch his little robot do it’s thing.

It wasn’t an easy decision to abandon Actionauts when I did … it was going to the last CES in June of that year that sealed the coffin shut. I eventually put a lot of the ideas that came out of Actionauts into a more sophisticated version for the Commodore 64.

But that’s a story for another day.

Classic game collectors interested in receiving information about acquiring a privately released copy of Actionauts can register by clicking the link below to get on the mailing list … or HERE to read frequently asked questions about how the sale will be conducted.

ACTIONAUTS MAILING LIST SIGNUP