Years ago, I purchased one of the first Apple II computers and began to learn how to program it.

During that time, my friend, Jeff, designed a hardware add-on board for the Apple II. I assembled the first boards for him, soldering them by hand.  His board became a success, and I wondered how I could create a similar success.

I started working for a computer store in Memphis and wrote a set of utilities that would print graphics to a dot matrix printer at various sizes and orientations.  To compete with mail-order dealers, the computer store gave it away free with the purchase of the printer.

When I mentioned to Jeff that I would like to try writing something commercial, he suggested games.

I write games for a living.

So, I quit my job and started writing a game.  My family thought I was insane for quitting my job, but I pointed out that I had actually been spending as much on computer hardware as I had been making at work.  It would have been much safer to keep the day job and work on the code at night or weekends for a while. But then, I might never have finished.

After several weeks of long hours, I had a created a game which I called "Photon Base".  I sent copies to several game publishers and they responded with varying degrees of interest.

Doug Carlston and his brother, Gary, of Broderbund Software called me and said that they liked the work.  Doug had a list of specific ideas that they wanted to see added to the game, and if I added them, they would publish it.  The game was retitled "Genetic Drift" and a story line was crafted around the improvements.  I completed the improvements and it was published in late 1981.

(click to enlarge)	(click to enlarge)
Other links:	Text of instructions	Animated title screen (added by Broderbund)

The next game was planned to have a sequence of several games in it. I coded prototypes of three of the different games and sent it off to Broderbund for their review.

One of the three games was a maze with sliding walls, monsters to shoot or avoid, and humans to rescue.  Broderbund suggested that I focus in on the maze and give it some depth and interest, rather than having multiple games that would seem unrelated.  I was particularly pleased with the large numbers of objects that were moving on the screen at the same time, and how the timings were carefully adjusted to keep game play consistent.   "Labyrinth" was published around mid-1982.

Late in the development of the game, an amusing bug showed up. As I was play testing it, one of the monsters broke out of the maze and ran right off the side of the screen. It wasn't long before the monster was writing all over memory and crashed the game. It was literally an "out-of-bounds" memory error.

(click to enlarge)

The Atari 800 was becoming popular, and Broderbund signed Corey Kosak to port Labyrinth to the Atari.  At the same time, I ported Genetic Drift. It was relatively easy as the Apple II and Atari 800 both used the 6502 processor.  The Atari had nice graphic hardware and sound support. These games were released in late 1982.

Deadly Secrets never revealed.

After that, I created one more game for Broderbund.  It was an adventure style game with graphics titled "Deadly Secrets".  There were three team members involved: story author, programmer and artist.  As the story author, I was responsible for the story line, text descriptions, commands to be used and puzzles.

Unfortunately, the programmer was unable to make it all work properly in the limited Apple II environment, and the game was never published.  It did appear in a Broderbund advertisement, and is my contribution to the vaporware market.

(click to see the full ad)

My brief foray into idealism.

I wrote two games for Penguin Software of Geneva, Illinois.  "Crime Wave" for the Apple II, in which the player controlled a police car in search of bank robbers.  If you caught up with the robbers at the bank, you had a chance to catch the running crook before they got away.

(click to enlarge)

I grew weary of the shooting and "violence" in the games even though the violence was tame compared to the games of today.

There is an essential difference between watching a violent movie and playing a violent game.  While watching the movie, you can distance yourself from the violence, always being aware that it is the character in the movie deciding to do the violent act, right or wrong.  In a violent game, it is you choosing to perform the violent act. Just like champion athletes train until their actions become second nature, violent games can train people to make violent decisions.  It might not be a good thing.

People who play violent games excessively may do so for psychological reasons.  Perhaps they seek a jolt of self-medicating adrenaline, or they need to feel powerful in the game world as opposed to feeling powerless in their real lives.

So, I mentioned to Mark Pelczarski of Penguin Software that I wanted to write something "completely non-violent".  He suggested that I port a game to the Atari that he had published for the Apple II by Eagle I. Berns and Michael Kosaka entitled "Pie Man".

It was a clever game, where pie shells came out on a conveyor belt, and you had to fill them with whipped cream and cherries, then put them up before they fell off of the end of the belt.  You had to avoid spilled flour and dodge tipsy wedding cake bakers.  I enjoyed porting the game, and it turned out well with the use of some Atari additions such as a 4 part musical soundtrack.

Unfortunately, the world was not ready to give up the really cool violent games that were coming out at about that time, and the game did not sell well. But, the popularity of Tetris, solitaire and others prove that there is a market for non-violent games and puzzles.

(click to enlarge)

One person, one game (or attack of nostalgia.)

It was a much different experience to program in the days of "one person, one game."  Now, of course, most games are created by a large team of people.  Even then, the publisher was a team member providing good ideas and support for difficult problems.

The game was the only program running in the machine, and operating system calls were well documented (and even open source, since you could read the OS code with a built-in debugger.) Now, your code is never alone in the machine.  Undocumented, proprietary and buggy operating systems and libraries make life much more difficult.

The open source movement, and the ability to read, learn from and improve any code you want to, offers some hope to the programmer interested in how things work and creating bug free code.