... Steve Kranish

By Scott Stilphen

DP: What’s your educational background?

Steve Kranish: I have a BSEE from Cornell University. I focused primarily on analog hardware, and thankfully made it through school having suffered through only two CS classes. In those days, computers meant decks of punch cards, and they did not interest me.

I did take one EE course in ‘Computer Structures’ for which the semester-long lab assignment was essentially, “In groups of 8 to 10 students, build an 8-bit microcomputer, and tell me when you are done”. The biggest chips we were given were 4-bit ALUs (arithmetic logic units) and there were no tri-state bus buffers – they were too new and expensive for us to work with.

We had to create a CPU architecture and instruction set, and design all the hardware to implement it. This was in the days of paper and pencil schematics, before the first programmable logic. We really built a computer from gates and registers, and it ran!

It was probably one of the best classes I took in 5 years of college, because we had to learn how to work as an engineering team, communicating with accurate documentation. We had to make decisions as a group, and we had to make and live with compromises brought about by the reality of time and resources.  It really taught me the internals of processors. I took away a great question to ask interviewees: What exactly does a JUMP instruction do? You would be surprised how many CS majors cannot answer that…

I was a teaching assistant for the same class the following year. Professor Norman Vrana, if you are still out there, thank you!

DP: What inspired you to go into game (hardware and software) design?

Steve Kranish: I got into game programming largely by accident. I was hired into John Gates’ Applied Technology group, to investigate the application of various technologies to the dying handheld game market. I essentially became an ‘engineer at large’, working on whatever was important at the moment – for only as long as it was considered important.  A.T. was initially focused on handheld games, which had once been a big money maker for Parker. We were all part of the same group under the same pointy-hair bosses.

My entry into game programming – which was NOT appreciated by most of the other gamers at Parker Brothers (I had not gone through their interview process; I was already there) – came about when I was asked to work on the Frogger 400/800 port

DP: Were there any programmers or games that inspired you?

Steve Kranish: I think most of the game programmers at Parker did remarkable work, but most of them were working on hardware that was very different from what I worked on, so there was not much of a connection.

As for games, well, I might as well let out the ugly truth: I am not a gamer. I could put in an almost infinite amount of time playing a game I was working on, but that was it. To this day, I do not play computer games for fun.

Most of the game programmers were real gamers, playing everything they could find, and getting very good at rather challenging, complicated, or difficult games. Not me!

DP: Did you work for anyone prior to Parker Brothers (after school)?

Steve Kranish: Parker was my fourth and last job after graduating from Cornell. At just slightly over two years, it was the longest. After watching three jobs in a row disappear out from under me, I decided to try my hand at being an independent consultant – which I did for almost 15 years. After another failed experiment at the ‘employee thing’, I am back to being independent.

I have found that I am slightly better at keeping myself employed than the so-called professional managers who were supposedly being paid to do so.

DP: How did you hear about PB?  When did you start working there

Steve Kranish: I knew they were nearby, because I was living in Salem, MA at the time, only a few blocks from the printing factory. I think I responded to an advertisement in the local newspaper.

DP: What was the development process like?

Steve Kranish: I mostly worked on my own, with little supervision. I think everyone else did, too.  I basically did what I was told to do. Parker had a reversed not-invented-here policy, which openly discouraged staff from suggesting anything. The company preferred to pay good money for bad ideas from outside, than accept good ideas from inside for free.  The poor choices for arcade game translations were made entirely by Parker’s Marketing Bozos. They were NOT the result of someone playing the game and suggesting that we do a translation.

(Parker Brothers version on the left; Sierra On-Line’s version on the right)

DP: Was Frogger (for the 400/800) the only game you did that was released?  Did you also do the 5200 version (port)?

Steve Kranish: Frogger for the 400/800 and 5200 was the only title that I worked on that actually made it out the door.

I did the reverse-engineering on the Atari 5200 for Parker, and wrote the manual for porting games from the 400/800 to the 5200. The hardware is almost identical, but the memory map is different and the controller is completely different. Frogger for the 5200 was a demonstration of my work.

DP: How was it that PB ended up re-doing Sierra On-Line’s Frogger?  You mentioned Dawn Stockbridge re-did all the graphics. As a side note, 2 different programmers worked on the Sierra On-Line version (Chuck Benton and John Harris).

Steve Kranish: With the success of Frogger for the 2600, Parker management wanted to move it to other platforms as quickly as possible. Parker had the rights to do (Frogger) cartridges for all platforms, but had ignored other formats. Sierra had released a pretty good rendition of the game for the Atari 400/800 computers on disk and cassette, so Parker management negotiated a deal with Sierra to use their game as the basis for a cartridge version. There was just one little catch: Sierra did not have the source code. And neither did John Harris, who had written it. He apparently had just one copy of the source, and he LOST it.  So I was handed the cassette version, and asked if I could turn it into a cartridge. “Oh, and could I get it into 8K? Oh, and could I get it done in 6 weeks, so it could be shipped before the end of the fiscal year? And could I make it a two-player game? And change the graphics? And, and...”

DP: How difficult was it to work under these circumstances?

Steve Kranish: The cassette version loaded into a 13K RAM image. Some of it was code, some was graphics, and some was debris. Harris did his development work directly on an Atari, with a cassette, so he had to work on little blocks at a time, and they were scattered about in memory. I had some real development tools that allowed me to work on the entire program at one time.

Rex Bradford (or maybe Dave Lamkins or Jim McGuiness) had written a 3 path 6502 disassembler which was used to help investigate and reverse-engineer the 2600. The 6502 has instructions that are 1, 2, and 3 bytes long, so the 3 paths provided all of the possibilities, plus a dump of everything as potential (bitmap) graphics.

It was up to me to sort through all of this, and figure out what was what. I went through the disassembler output, which was a 2 inch-thick printed listing, and figured out what everything was.  I then removed the debris, started to comment the code (so I could figure out what it did), and reorganized it all into a coherent form. If you disassembled the code today, you would find that it is structured top-down, with all the graphics together near the end (higher addresses).

Figuring out someone else’s code in this way – starting out with only the object code, and no other documentation – provides some interesting insight into someone else’s thought process. I used a printed listing of the entire game and a pile of colored markers to comment the code and designate different sections. This may seem very old-school, but sometimes it is the only way to figure out complicated code, and when I need to, I still work that way.

For about 6 weeks, I read listings, typed, rode my bicycle, and occasionally slept. In the end, I had an 8K, 2-player game, with revised graphics that change on each level. Why does the sidewalk keep changing? Because we could do it, and had room for the code and graphics, that’s why.  Dawn Stockbridge redesigned the graphics, and helped me figure out some of the code. I don’t remember much about the music. 

DP: Did you have any contact with John Harris, or any help from him?

Steve Kranish: I did get to meet John Harris at one point, late in the project. He was one of those people who apparently thought he was so smart that he did not need to finish high school. But he did not know how to button his shirt correctly. And where is he now?

DP: What was the story behind the cartridge (shell) for Frogger?

Steve Kranish: Near the end of the project, I looked in on the mechanical engineering department, where they were designing the plastic case for the cartridge. I borrowed some of the (plastic) test shots and quickly discovered that although they fit the 800 just fine, they did not fit in the Atari 400, which had a large metal casting as part of its base, and a different size opening for the cartridge. Concerned that this problem would quickly render my by-the-end-of-the-fiscal-year deadline pointless, I told the director of Mechanical Engineering about the fit problem. It seemed like the right thing to do.

It wasn’t. In the highly politicized world of Parker management, I had apparently denied my boss’s boss, the director of Electrical Engineering, the opportunity to embarrass the director of Mechanical Engineering at a management meeting. So the only thank you I received was that they did not actually fire me for this ‘corporaticus giganticus’ transgression (huh?), although I got pretty close. Yes, we had pointy-hair bosses at Parker Brothers.

DP: Are there Easter eggs in any of your titles? 

Steve Kranish: Pretty much everyone who had already released a game had put one in theirs, so I figured that I would too, with Frogger. On level 6 or 7 (I don’t remember which), when you jumped on the ‘lady frog’, the frog would change to my initials (BK). I could not play to that point; I had to force numbers into the processor with an emulator to test the code. After I was all done, and had left town on a week-long bicycle trip (and was therefore VERY unreachable), a game tester found it.

From what I was told, the (pointy-hair) management went ballistic. Having recently lost the ‘Gang of 5’ to Activision, including one engineer who did not even  finish the project he was working on, Parker’s hopelessly paranoid management overlooked my insane efforts to get the game done on time as they had requested, and assumed that I, too, was going to leave, so I must have somehow sabotaged the game. I don’t know if any cartridges with the Easter egg made it out the door, but they had someone remove it. This was not hard to do, because I had commented every line of code, which made it easy to find.

When I returned, I came even closer to being fired. The ‘completion bonus’ which other engineers have mentioned (and for me was never actually defined) was withheld, and ultimately never paid. No one would tell me what, if any, impact all my work had on the bottom line for the fiscal year. I have absolutely no idea how many Frogger 400/800 or 5200 cartridges were sold.  No doubt about it, we had pointy-haired bosses at Parker.

DP: Besides Dawn, did you work with any other graphics or sound artists?  If so, do you recall who helped with what?

Steve Kranish: There was another artist, who did all of the storyboards for Baker’s Dozen, but I don’t remember his name.

DP: What kind of game was Baker’s Dozen?

Steve Kranish: Think Super Cobra. Now think Frogger. OK, now push the 'BLEND' button. The idea was to do a cave-with-obstacles game for the non-violent audience that loved Frogger. The scene was an automated bakery, with conveyors, robots throwing pies, bins of flour, etc. I think it had a lot of potential. Marketing was, as always, an obstacle. Another obstacle was ME - as a non-gamer, I was unlikely to come up with the best game ideas. I don't recall if this actually got past the basic artwork and storyboard stage. I don't think I have the artwork anymore.

DP: I’m surprised PB didn’t immediately start up the video game division doing versions of their board games, but they seemed to change their mind around 83-84 when they advertised Risk.  Why were they so hesitant to dip into their own (proven) catalog of games, instead buying up arcade licenses?

Steve Kranish: Umm.. are you asking me why a company run by certified, licensed Marketing Bozos with MBAs and other fancy degrees didn’t try to maximize (oh, excuse me, ‘leverage’) the value of existing games and licenses by extending them to the video game line? Lack of vision? Lack of brains? Lack of a blatant, obvious example to copy? Bracy, Stearns, would you care to comment?

Maybe using a game that was already in-house would have violated the reversed not-invented-here policy :)

DP: You mentioned that you hope to continue working on Risk at some point, even though you no longer have a copy of the source code…

Steve Kranish: I would still like to put in the map, and maybe a few other things.  I have talked with Dawn about creating the map graphics.

DP: What can you tell me about Project Zelda, PB’s top-secret project to distribute games online (via cable)? You were mostly responsible for the hardware end of it, correct?  Can you explain how it was to work, and whether or not you finished it?  Did you work on any other aspect of Zelda?

Steve Kranish: In the 1982-83 timeframe, the only distribution channel for games was physical hardware, and cartridges dominated the market. Someone – I don’t know who – decided there must be another way to distribute games. The chosen solution was the rapidly expanding field of cable TV. This was during the time when Beverly, MA was first wired for coax, so we had cable access available locally.

The basic idea was that Parker would provide a TV channel signal to cable operators that contained the multiplexed (interleaved) data for a number of game cartridges (I think the number was 20). Parker would sell – or the cable operators would subsidize – a special cartridge for the Atari 2600 that would plug into the 2600, and had a cable that would connect to your cable box.

I don’t remember a lot of the technical details. But if you go through the rough math, 20 games at 8K x 8 bits, multiplexed together with a selected game download time of 10 seconds requires about 2160 bits per TV frame, or about 9 bits per line. So we must have encoded it into the horizontal retrace time; we certainly did not need the entire channel bandwidth.

My role in Project Zelda was to design the head end hardware. This was a rack full of boards with slots for Atari 2600 cartridges, plus a few other boards. The output of the system was a single serial data cable, with the contents of the cartridges multiplexed into a single serial bitstream. The available games could be changed by simply changing the cartridges that were plugged in. This bitstream would be encoded into a video signal, but I don’t think we ever got that far.

To explain the rest of the system, I need to introduce a few people who may not have been mentioned in other interviews about Parker Brothers, because they were not directly involved in game design.

The cartridge that plugged into the Atari 2600 was designed by Milan Merhar. If Milan is mentioned at all, it is usually as ‘one of the engineers’, which is a gross understatement. Milan was/is one of the most brilliant engineers I have ever met. He knew what he was doing, and his stuff worked – and worked well.

Much of the hardware for Zelda was built by our lead technician, Bill Kaczor. If I remember correctly, Bill had learned electronics in the military. But he did not approach things with a strictly do-what-you-are-told mentality. He wanted to understand - in detail - what he was doing, and he did it very well. When I gave Bill a schematic, he would study it, and if I had mixed up some lines or done something wrong, he would catch the error and correct it. When Bill was done building something, the board matched the schematic, and if the design was correct, the board would work - the first time. He checked every wire, so he knew it was correct. He built a whole stack of the cartridge serializer boards, and they all worked. Unfortunately for me, someone else built the last few – and they so screwed up and took so long to debug that it would have been quicker to build them myself.

If they handed out licenses for electronic technicians, Bill would have qualified as a ‘Master Technician Plus’. Most of us who did hardware work thought he should have been promoted to Engineer, but I don’t think that was what he wanted. He wasn’t a game designer – or even a gamer per se, he was one of those people who worked quietly behind the scenes, and made it all possible. And he is a good example of why associating a single game designer’s name with a project is unfair to all the other people who really have something – sometimes a lot - to do with the project.

I have long since lost track of Milan and Bill, so I don’t know where they work today. Wherever they are, I hope they are appreciated more than we were at Parker.

According to Ray Miller, he wrote the game selection menu program that ran on Milan’s cartridge. Although it looked like a simple application, this could not have been trivial; keep in mind that the menu contents would change frequently, so they have to be downloaded before they could be displayed.

There was also an RF engineer, whose name I cannot recall. If I remember correctly, he was hired straight out of school. I think he was involved in encoding the serial bitstream into a video signal.

We built everything I have described here, and it all worked. A cable ran over the wall from my cubicle to Milan’s, carrying the serialized data. Milan’s cartridge decoded the serial stream, and downloaded the games selected from Ray’s menu. You could change games by simply resetting the Atari system, which would bring up the menu again.

In an engineering group where the typical project involved just one engineer for 3 or 4 months, assigning 5 or more engineers and technicians to a single project for 6 months was a major commitment.

Parker was supposed to buy a satellite transponder, which would have required real money, to make this all possible, but that never happened.

Like everything else I did for the Applied Technology group, Zelda was thrown away. The official story, as it was fed to me, was that because Atari was (at that time) owned by Warner Brothers and Warner was a partner in Warner-Amex Cable (a major cable TV company at that time), then Warner must be planning to do the same thing. With their access to cable operators, and deeper pockets, there was no way that Parker would be able to compete with them. There may be other versions of this story that were fed to other participants. I don’t know if there was a shred of truth in this version of the story, but Atari never announced anything resembling Zelda. From what I have heard about the goings-on inside Atari, they made Parker look like a civilized, organized, well run, fast-moving company.

Zelda would have put Parker directly into the distribution business, competing with its major customers such as Toys-R-Us. This would have been good for Parker’s video game business, because Toy-R-Us and their competitors were running the video game business into the ground by filling ‘discount bins’ with lots of awful $5 cartridges that sucked up money that really would have been better spent on good games. Having customers purchase good games that keep them happy and interested would have been in everyone’s best interest – except perhaps the companies that produced the dreck that went straight into the discount bins. Atari’s ‘ET’ debacle only made matters worse, putting discount-bin-quality games on the full price shelves – with a full price tag.  As a direct distributor of (video game) content, Parker would have even been in a position to handle material from other video game producers, if it wanted to. This could have given it a very dominant position in the business. The channel was to have been used to milk a little more money from older games, and provide ‘teaser’ access to new games that would be available for a few days, and then taken off the channel for a few months, to encourage cartridge sales.  But putting Parker in direct competition with its biggest customers would have been very bad for the traditional (paper) side of the business, which needed Toys-R-Us and the like as a distribution channel.

So it is possible that this conflict of interests played a major role in the demise of Zelda. This sort of decision would have been made by the same Marketing Bozos that I have mentioned elsewhere, so one can reasonably assume it was just as well-thought out.  Maybe Zelda would have saved the video game business for Parker. Maybe it would have helped everyone in the business. Maybe. We’ll never know.

DP: Where did the “Zelda” name come from, since this became the name of one of Nintendo’s most successful video game properties!

Steve Kranish: It was probably John Gates’ idea. Zelda was a name, and nothing more. Engineering projects need names that have nothing to with what they will be called when, if ever, they are shipped. Project names help to identify a project within engineering, even if no one has any idea what it will ultimately be called.  If engineering let the Marketing Bozos decide the name, we would have had to change it every time they changed their mind about it, which would have easily taken up all of our time.

Years later, when I ran the engineering group at another company, I got to assign the names. For a while I used obscure, defunct airlines, such as Laker and Allegheny. Then we moved on to obscure British beers, such as Bellhaven. Projects need a name, that’s all!

DP: Were there any games or projects that you worked on that ultimately never got released or even finished, besides Risk and Project Zelda? 

Steve Kranish: Everything I did for Applied Technology was thrown away, including Zelda. I did a lot of reverse-engineering work, and studied game cartridge piracy issues. I wrote a manual describing how to dump any Atari 400/800 game cartridge to a cassette for later use

DP: Do you recall any titles or projects that other programmers were working on, possibly that were never released, or finished? 

Steve Kranish: I can’t help you with any of these – except Sky Skipper. That was a truly insipid arcade game; in fact it was so bad that I was the only one in the office who was willing to play it (I am not a gamer, remember?) so I became the local expert and could answer questions for whoever got stuck writing the port. The Marketing Bozos had agreed to sell it in hopes that doing so would provide access to future games, which I don’t think ever happened.

The Sky Skipper that we had in the office was a table model, rather than an upright arcade game. The monitor was under a glass top. I think the idea was that one had to be drinking to be willing to pay money to play such a stupid game, and the table top provided someplace to put your drink while you played. This does not explain my willingness to play it; I do not drink.

DP: With your games, were there any features you would have liked to added, or any known bugs or glitches that gave you trouble (or never got resolved)?

Steve Kranish: Do you mean like being allowed to actually finish something? :)

DP: What was the easiest/hardest part of designing Frogger, Risk, and Zelda?  If you had a chance to redo any of them over, what would you change or what would you have done differently?

Steve Kranish: I think all three projects would have been helped immeasurably by marching the Marketing Bozos that ultimately screwed them up, up to the roof of the building, and pushed them off. Risk died from general malaise, and Zelda was killed off by a complete lack of guts.  I would still like to put in the map, and maybe a few other things.  I have talked with Dawn about creating the map graphics.

DP: What were some of your experiences working for Parker Bros? Any stories or anecdotes from those days that you recall?

Steve Kranish: I think I have covered everything that I care to share about engineering. So I will add a few about management and honesty.

In early 1983, it seemed that the sky was the limit in video games, and the electronics group at Parker was expanding rapidly. We were largely sequestered on the fourth floor of an addition to the ‘building that Merlin built’, and had run out of space. Management decided that the easiest or best way to get us more space was to move the department out of the building entirely. Perhaps that was the real objective, anyway. Parker leased space at a much less-interesting building about half a mile away, and we were scheduled to move in over the summer. We would trade our peaceful views of trees and a lake for a steady stream of traffic outside our door.

Then the first hints of a downturn in the industry appeared. This did not stop expansion of the department, but some pointy-hair manager decided that moving the department out of the building would ‘send the wrong message’ to General Mills management. So the move was off. But what message was being sent to whom? The company had leased the space, so they had to pay for it, right? What message did THAT send, to lease the space, and then leave it empty?

Lacking the additional space that the move would have provided, put still more people involved in the charade of department expansion.  Our large cubicles were torn down and replaced with smaller ones, so there would be room for a few more suckers, oh, pardon me, employees.  Summer turned to fall, and the company continued to add staff, albeit at a slow rate. It is worth noting here that Parker was a slow-moving, conservative company. In a high-tech business that can make sudden turns and twists, this was a company that could not decide whether or not to pick its nose in less than 3 months. With an ample supply of bad news – the Christmas 1983 orders were placed over the summer, so management knew exactly what was coming - they continued the charade that if we kept costs under control, everything would be fine.

One poor sucker was hired – and relocated – just a month before things really imploded. For the life of me, I cannot believe that management did not know exactly what was coming, and when it would happen. This poor person (sorry, I don’t remember their name) was little more than a sacrificial lamb, about to be slaughtered just to keep up the charade. Maybe their life turned out OK, and maybe they wound up in a better job – but the company and its pointy-hair management had absolutely no business or right to turn someone’s life completely upside down just to keep a lie going a little longer.

By the end of October, the rumors about an impending layoff were flying fast and furious. I was about to walk by my boss’s boss – the director of Electrical Engineering – in a stairwell, when I decided it would a good time to corner him and ask him what was going on. Good corporate soldier that he was – he, OK, I will be blunt here – he lied to me. I cannot offer a quote here, because I don’t remember the details of the conversation. But he admitted to nothing. Of course, I knew something big was about to happen. The Marketing Bozos had stopped coming by to check up on Risk a month or two before. Someone must have forgotten to tell them what their role in the charade was. So I knew Risk was toast, I just didn’t know when it would pop up.

I had worked on a number of interesting projects at Parker, and almost all of them were thrown away, leaving nothing but obscure documentation and dusty hardware. I am one of those engineers who does a lousy job of separating himself from his work; I developed some attachment to almost everything that I worked on. My first job did not work out at all as had been promised, so I left. The next two jobs had disappeared out from under me. I knew what is was like to be laid off, and I knew that it generally meant that whatever you were working on was going to be discarded.

So I did what a lot of engineers do – I took a bunch of stuff home. Nothing with intrinsic or monetary value, just drawings from Baker’s Dozen, schematics from Zelda, listings for Frogger, a copy of the 5200 conversion manual. The layoff had not happened yet, so no one was going to stop me from taking stuff, as we all worked at home sometimes anyway. I figured that if nothing happened, I would just bring it back. And if something did happen, no one was going to miss it anyway – it would have just gone into a dumpster.

The following morning, when I came in, there was a uniformed guard standing by the front door. The charade was over, and I was out of the building for good before lunch. I did get an exit interview, which consisted mostly of “Sign this document or you will not even get the measly two weeks of severance we are offering”.

I was part of a ‘graduating class’ of 70 people. More followed in the spring of 1984. Within a year, everyone from the electronics group was gone, except the director. He had built it up from nothing, and hired and fired some of the best engineers and technicians I have ever worked with, and now he was selling off the last of the lab and office equipment at scrap prices. I bought a logic analyzer that served me well for many years; I don’t remember what they sold for new, but I paid $500 for it.

During most of my time at Parker, the company was headed by Randolph (Ranny) Barton, who was the last of the Parker family to run it. Ranny’s mother was a Parker. I don’t blame Ranny for what ultimately happened; most the decisions were made either by General Mills, who owned the company at the time, or their gang of so-called managers and Marketing Bozos. Their egotistical and self-serving shenanigans are well covered, in detail I could not possibly provide, by Ellen Wojahn’s book, “Playing By Different Rules” (Amacom Books, Saranac Lake, New York, U.S.A., 1988). Wojahn’s book is a quick read, and provides a wonderful insight into just how quickly and completely a few people can destroy a company that has been around for decades – while claiming that what they are doing is good for the company.  For a used copy, try either www.abebooks.com or http://www.bookfinder.com/ (and expect to pay about the same as a cup of coffee), or Amazon.com for a new copy. The book was republished in 2003, long after there was anything left of Parker Brothers. Republishing a book after 15 years is unusual, so I must not be the only person who thinks it is a fascinating study of mismanagement.

In its simplest terms, the collapse of Parker was brought about by the same thing that quickly kills a surprising number of large companies – an unwillingness to respond to a world that changes around them. This is usually brought about by an unwillingness to even believe that the world is changing in a way they did not plan for.  Parker is hardly alone. Here in Massachusetts, we have lost plenty of companies – large and small – to the same stupid style of ‘management’.  Data General, Wang, and Prime all come to mind. DEC and Polaroid pretty much set the gold standard for destroying perfectly good companies which once had breath-taking market shares. On a global stage, General Motors is headed down the same path. The details are different for each company, but the root cause is the same: large, ponderous companies abhor change.  Nothing changes much – even Enron succumbed to essentially the same problem. For them, the change was that after years of running charades in the dark, someone turned on the lights and started looking at what they were doing.

Today, Parker Brothers is just one of a large basket of brand names owned by Hasbro. At least the name survived; when was the last time you saw the name ‘Selchow and Righter’ on a box?  If you look at the Hasbro web site, they have a history of each of the well known companies that they have absorbed, including Parker Brothers (http://www.hasbro.com/default.cfm?page=ci_history_pb). My time at Parker is covered entirely by the SPACE BETWEEN THE TWO SENTENCES in this paragraph, which makes no mention of Atari:

“Within an 18-month period, PARKER BROTHERS had developed the capability of producing a variety of electronic products, including MERLIN, the number-one selling hand-held electronic game in 1980. With the introduction of the NINTENDO ENTERTAINMENT SYSTEMS™, GAME BOY AND SEGA™ GENESIS SYSTEMS™, PARKER BROTHERS kept pace with the times and developed video versions of its classics such as the MONOPOLY game, CLUE, RISK and BOGGLE.”

It is probably worth mentioning that during 1983, I saw what would later become known as the Nintendo Entertainment System in Rich Stearns’ office, years before it was introduced to the US public. Perhaps Parker could have become Nintendo’s U.S. distributor? Nah…

DP: Since PB, have you stayed within the field of game design?

Steve Kranish: I was involved in non-curriculum educational games for several customers through most of the 80’s. I did not design the games, but I was involved in hardware bindings, cross-platform portable I/O systems, and general implementation. Most of this work was done for Spinnaker Software.

DP: Can you describe your career, between then and now?

Steve Kranish: As I said before, after my job at Parker vanished, I decided there was no point in continuing to pretend that other people were going to bother to keep me employed, even if that was what they were paid to do. For a few years, I worked on the previously mentioned non-curriculum educational games.

The closest I ever came to a pure game was a technology demonstration that I created for Spinnaker Software and SOCS to show to Mattel.  SOCS (don’t ask what it means, I don’t remember) had developed a small format (CD size) laserdisc player based on the CAV (constant angular velocity) system, which put a single frame of data on each track. This player could move its head some number of tracks during the video vertical retrace time, so it was possible to seamlessly change within a limited number of video sequences or paths, under user control.

Why did this matter? Let’s put it in a little bit of perspective. This was the mid-80’s, and an Intel 286 was still considered a high end computer. Standard color video was still IBM’s CGA with 320x200 in a few, poorly selected colors. The CPU did not have enough processing power to generate graphics in real-time, and the video card did not have the ability to handle it, anyway. There was no hardware acceleration.  The technology demonstration was to show how SOCS video player would be able to create a first-person point-of-view maze game, which by today’s standards would be a plain vanilla shoot-em-up. I think that the laserdisc arcade games of the day had some of this capability, but this was to be even more sophisticated, and designed for the home market.

The complete system consisted of an Intel 286-based PC, two high-end laserdisc players that accepted an external video sync, a video signal generator, a video overlay card, and a custom synchronous video switch that I built. The two players were synchronized by the video signal generator, and their outputs were multiplexed together by the video switch, which would only toggle during the vertical blanking (retrace) period. The output of the switch went into the video overlay card, so the PC could generate graphics on top of the disc player output.  The late Steve Yelick of Spinnaker Software was responsible for the video content on the discs, and ran the project.  I got the entire demo working with just a few weeks of work. You could walk around a maze of  ‘T’ intersections, steering with a joystick. At each intersection, you had two choices – go one way, and the video would continue from the disc being played; go the other and the video would seamlessly switch to the second disc, which was already queued up with the appropriate sequence.  If you fired at something, the video overlay card would overlay a ‘splat’ sequence on top of the maze video from the discs. The overlay also provided scores, crosshairs and the like.

For its time it was pretty impressive, and much better than the simplistic laserdisc based arcade games of the day, because the scene transitions were instantaneous and seamless – the player never knew what was going on behind the screen. It was a real-time, seamless, continuous maze game. The usual reaction was, “Holy SH*T!”

The demo was shown to Mattel, but they did not bite – perhaps being bitten too much before by the Intellivision. The only feedback that I remember was that the Marketing Bozos at Mattel did not like my ‘splat sequences’. I don’t think they understood the underlying technology or what it meant. Leave it to them to completely miss the important stuff, and whine about the things that really don’t matter.

The longer the demo sat in someone’s office, the less valuable it became, because processing power caught up with it. If it had somehow become a product, I think it would have been pretty short-lived.

I drifted back into hardware design for a while, and have largely settled into developing small embedded systems. Most of my work is in the consumer electronics area. I did some industrial electronic design work – I designed and built multi-channel audio systems that are used in many nuclear power plant control training simulators. The largest of these systems had 40 independent audio channels – meaning it could have driven 40 separate speakers – for a room that was about 10 feet square. Take a guess what kind of nuke plant simulator that was used for…

I did burn through two more jobs before returning to consulting. I was the Chief EE for a consumer audio company, working on multimedia and home theater speaker systems. A side effect of that job was that my house became populated with speakers. There must be more than 40 scattered around the house now. Just like at Parker, I worked with a great bunch of engineers doing fun stuff, and got jerked around by a bunch of Marketing Bozos.

Then I spent 3 years at Motorola learning more than you would ever care to know about the internals of inkjet printers. Motorola’s Semiconductor Product Sector (now Freescale Semiconductor) was a major chip vendor to several of the big printer companies.  I was working on software for a system-on-a-chip printer that could be sold in blister packages for $30 without losing money (in case you did not know, most low-cost printers are sold at a loss, to sucker you into buying cartridges).  The entire project, and the underlying technology and everything associated with it, was all thrown away when some bean counter concluded that there was a greater short-term tax benefit in closing our little office than in laying off a similar number of people elsewhere in the company. The long-term value of the work that all of us were doing - with annual potential market of $300M to $500M - apparently did not enter into the equation.

For the last couple of years, I have been focusing on embedded wireless applications, such as 802.15.4 and Zigbee. There are not a lot of customers who are interested in it, but there are even fewer engineers who know anything about it.

DP: Do you still own any of your games for these systems, either as a keepsake, or to show friends or family?

Steve Kranish: I think I have Frogger for the 400/800 and 5200 in boxes, and I have the last version of Risk, in an EPROM cartridge.  I also have the security stamp, used to mark paper copies of documentation for Zelda. It says: “BURN BEFORE READING. Project Zelda”.  I have a separate “BURN BEFORE READING” stamp that I used on my own paper documentation for many years. Now that I mostly create electronic documents, the drawings usually have a similar “DELETE BEFORE READING” watermark.

I also have all of the schematics for the head-end hardware for Zelda, but you aren’t supposed to know that :)

DP: Which of your titles are your favorite, and what types of games in general

Steve Kranish: I still like Frogger, and I have an Atari emulator on an office PC so I can play it.

DP: What are your thoughts on how the industry has evolved?

Steve Kranish: I never had any interest in shoot-em-up type games, then or now. Most of what I see is far, far, too violent. Whatever happened to just hopping across the street?

Some closing thoughts:

Why am I writing all this now? Shouldn't I just bask in the semi-glory of having completed a few games that made it out the door, and are still remembered by a few game fans?

Why? I'll tell you why. My experiences at Parker shaped much of the engineering career that followed it. I was so disgusted about having again entrusted my professional life to incompetent and dishonest management, that it was my LAST job for almost 15 years. And perhaps someone else, early in their career and as idealistic as I was, can learn something from this.

We did a lot of fun things at Parker. There really were days when we went to the office and played games all day. I even had the opportunity to work with the traditional game design staff - a small group of great people who knew games - ALL games – inside-out and backwards. These were the folks who turned the bad ideas licensed by the Marketing Bozos into playable games. I remember spending days helping to test board game concepts.

I liked my job, and wanted to keep it. I wanted to do a good job for the company. I liked my 6 mile bicycle commute, even if the conservative company did not appreciate my walking in the building in cycling clothes. I liked what we did, and I liked the people I worked with. I had no interest in 'climbing the ladder' or finding some way to make the company pay me lots of money. I wanted to be an engineer, and I really liked working with toys and games. I didn't want anyone else's job, title, or office; I just wanted mine.

But despite being in the fun and games business, Parker was not a fun company. It was a conservative, ponderous company, protective of its position in the world, and I think, baffled by the world changing around it. We - the entire electronics group - were a disruptive influence on the company at all levels, and we all chafed wherever we had contact. Before we arrived, the Marketing Bozos had complete control over everything. If they wanted a board square or card to be red, it became red; if they wanted it to be green, it became green. With the arrival of this group of bright, young engineers, they no longer had as much control. Everything we sent out the door was 100% programmer's prerogative, and they hated us for it.

I repeatedly ran afoul of what I came to see as unwritten 'corporaticus giganticus' rules - I was a good fit for the electronics group, but not the rest of the company. As long as I stayed away from the rest of the company, I was “OK”, but sometimes the rest of the company wouldn't stay away from me. I think that part of the problem is simply that, management (at companies that do fun stuff) know they don't need to treat their employees very well. They just figure that people will put up with all sorts of abuse, just to be able to work there. If you don't believe me, take a good, long look at the consumer audio industry.

From the outside, a company that does fun stuff looks like fun and games. From the inside, it may be very, very different. Things aren't always what they appear to be.

In a high-tech field where pretty much everything is scrap in 5 years or less, I have always been in awe of stonemasons. They build stuff that lasts! I am glad to see people maintain an interest in my/our work.

(Please consider all answers here to be copyright© 2007 Steve Kranish, with a release to Digital Press to publish it online at its website. It is not to be subsequently re-published or distributed without my permission.)

 Return to Digital Press Home