This week I cover two more Games by Apollo, Space Cavern and Racquteball! Space Cavern programmer Dan Oliver generously gave his time to answer my questions this week, and that Q & A will be posted to the blog shortly. Next week will be Blueprint and Solar Fox by CBS Electronics. Upcoming games include Stampede and Ice Hockey by
Activision; Othello and RealSports Baseball by Atari; Fast Eddie and
Deadly Duck By Sirius/20th Century Fox; and Surround and A Game of
Concentration (aka Hunt 'n' Score) by Atari. If you have any stories or memories you'd like to share about these games or any games I've covered so far, send them to 2600gamebygame@comcast.net. Everything gets read or played on the show. Thank you all so much for listening!
Pertinent Links
Atari Age thread with lots of contributions from Dan Oliver
Dan Oliver's web site
Telepathy on Atari Protos site
How to Beat the Home Video Games - Space Cavern
Find Us Around The Web
Wednesday, February 26, 2014
Wednesday, February 12, 2014
CX 2637, Dodge 'Em, and CX 2638, Missile Command!
Sorry about the lateness of the episode my friends! This one is about Dodge 'Em and Missile Command by Atari. Missile Command was definitely one of my favorites as a kid, not as much these days but only because my horizon has been broadened. Next week is Racquetball and Space Cavern by Games by Apollo. Upcoming games include Blueprint and Solar Fox by CBS Electronics; Stampede and Ice Hockey by
Activision; Othello and RealSports Baseball by Atari; Fast Eddie and
Deadly Duck By Sirius/20th Century Fox; and Surround and A Game of
Concentration (aka Hunt 'n' Score) by Atari. Send your stories and
memories for any of these games to 2600gamebygame@comcast.net. I love getting your feedback, and I read all of the submissions on the show! Thanks so much for listening!
Pertinent Links
Head On on KLOV
Missile Command at KLOV
Favorite Atari 2600 Games of Focus RS: Missile Command!
Favorite Atari 2600 Games of Focus RS: Dodge 'Em!
How To Beat The Home Video Games: Missile Command
Missile Command Kids Stuff album
Missile Command TB (Trak Ball) by Thomas Jentsch
Brian's blog about Missile Command
Missile Command Game Matrix
Bruce Lee - Be Water
Pertinent Links
Head On on KLOV
Missile Command at KLOV
Favorite Atari 2600 Games of Focus RS: Missile Command!
Favorite Atari 2600 Games of Focus RS: Dodge 'Em!
How To Beat The Home Video Games: Missile Command
Missile Command Kids Stuff album
Missile Command TB (Trak Ball) by Thomas Jentsch
Brian's blog about Missile Command
Missile Command Game Matrix
Bruce Lee - Be Water
Friday, February 7, 2014
Q&A with Imagic's Michael Greene
If you heard episode 48, you know that I was in touch with No Escape programmer Michael Greene. He gave a lot of his time to answer these questions, and he also gave his permission for me to post his answers here. Big thanks to him, and I hope you enjoy reading it!
I was really lucky to have some good high school history teachers as well. Two of them were both really good at getting you to forget what you know now and place yourself in the shoes of the people faced with making decisions at the time. Not only did you have to deal with incomplete information, you had to take in the prejudices of the age - the later being really, really difficult to do but helped immensely in making sense out of decisions that seem wacko today.
I spent way too long getting my degree. Can't believe how patient my parents were in retrospect. A few courses stand out - took an intro to genetics class as a junior that was great. Got a D and felt lucky. The course was graded on the curve and there were folks in that class that may end up getting a Nobel - they're blow away brilliant. Re-took the course to erase the D and did fine the second time around but it taught me a clear lesson - I wasn't going to be a first-class researcher if I had to take a course twice when my potential competitors could ace it in one go.
I like women so I left after my freshmen year. Couldn't get into Berkeley so ended up at Riverside for a year waiting to get into Berkeley. On a whim, I went down to UCSD to see the campus and really liked what I saw so applied there as well. Got in. How I did I have no idea. I was sitting in the Dean's office waiting for the Dean to meet with me and the incoming freshmen class SAT scores were on his table. The average was around 1500 with lots of perfect 1600's. I wasn't in their league and simply had to hustle to keep anywhere near them (witness the D.) Seeing that list was a serious wakeup call. It explained why so many of my friends could seldom study and ace tests where I struggled to just understand the questions. Dated a woman who had a photographic memory, could type 80 wpm with two fingers, reviewed movies on the side for the San Diego newspaper etc.
It took me a couple of years to figure out what I could do and while I was casting about, I was writing software. Took some CS courses but didn't care for them much - way too much theory which at the time, didn't appeal to me much. I understood the rationale but I was more interested in coding than talking about algorithm efficiency. I just wasn't ready for CS.
Ended up in the Econ department. I liked economic theory but gradually came to realize it was bs. The pretty curves were more speculative than based in reality. Before I realized that, I wrote a few economic simulations for one of the econ profs. He liked what he saw and hired me after I graduated to work on an econometric model of San Diego County. I was a data grunt which meant I was tasked with keypunching the data the group would dig up Lord knows where.
Long story short, the model they built sucked but looked good when it was delivered to the county. Too much curve fitting and not enough data to back up the curves or underlying economic activity.
That experience soured me on model building so I got a job as a programmer in LA. They had promised they were going to get a Burroughs computer to run the business on and UCSD was one of the few schools that had a Burroughs mainframe so I was a shoo-in for the job. The Burroughs under-delivered, the manager who bought it got fired and his boss replaced it with a 15-year old IBM 360. When I saw what a PITA JCL was and that batch programming was going to be the future at that job, I moved to System Development Corp to build a radar system for Morocco. The new boss realized he had seriously screwed up when 3 out of 4 programmers quit within a few months. The one who remained was able to command a huge pay increase. It worked out well for all of us. :)
The King of Morocco had seen a movie that had a wall-sized radar display and so he wanted one just like it. SDC sold him one and I was hired to help write the software which was going to run on Burroughs 7700. The B7700 was a 16 Mhz room-filling behemoth. That job was a lot of fun. I was working for a very competent manager who was smarter and funnier than hell.
He was responsible for the radar subsystem and had tasked me with reverse-engineering the compiler's data structures so the project could have a data dictionary generated from the programmer's code. He'd walk around to see what people were doing and noticed he frequently saw his staff waiting for a compile to finish. He got worried that perhaps the B7700 wasn't going to be up to the task of managing 2000 radar returns per minute so he sat down and wrote a couple of programs to see what was going on. He wrote a process that did nothing but generate radar packets and another program that did nothing more than receive those packets via the mechanism we were going to use in production. It could barely handle a few hundred packets doing nothing else but transmitting and receiving. Never mind generating the wall display for the King and radar consoles.
At that point, he got really worried and wrote a memo alerting his superiors of the issue. No response. That pissed him off so a few days later he wrote another memo that said the same thing but was titled "I know you're out there, I can hear you breathing." That got the necessary response and the long job of figuring out what was wrong with the hardware started.
About that time, he got recruited by a former boss of his and went to work for a company that built hard disk controllers. Back then, they were refrigerator sized and built by hand. My boss offered me a job at a 50% increase in pay and I followed him.
You might think a 16 Mhz machine could no way handle 2000 returns but there were plenty of systems back then that handled lots of work on miniscule hardware. American Airlines was running their reservation system on a slower machine and they were kicking 4000 reservations per minute which was enough to handle the country. The code had to be optimized and the OS portion barely existed - the app owned the hardware.
I consulted on HP equipment for a couple of years and between gigs saw an ad for a little card that would let you program the Atari 2600. You used a little keypad to hand enter your code and there was a small debugger that would let you set breakpoints. Built a breakout box that enabled me to write my code on a CPM-80 micro-controller and transfer the code to the Atari. Wrote some little games to learn how the 2600 worked and thought it was quite a bit of fun. I really liked the 6502 cpu as it had a clean instruction set.
Saw Demon Attack on sale and sent Imagic a letter asking if they needed programmers. I showed them my breakout box and they thought what I had been able to figure out was good enough to offer me a job.
The Imagic programmers were first rate and again, I was at the bottom of the stack. One guy, Bruce Pederson, was amazing. Without any documentation whatsoever, he attached an in-circuit emulator to a VCS and reversed the entire video architecture - including the special registers that doubled or tripled the sprites along with the requisite code timing issues. Took him two days to do it.
Later on, he ported Demon Attack to the Vic 20 in a month. Didn't read Rob Fulop's code. Just played the game for a day or so, and then sat down and coded the port from scratch. In assembly. As I recall, the sounds were spot on despite the sound hardware being completely different on the two platforms. I think he ended up as a VP at Altera the FPGA company. One of those blow-away brilliant minds.
One day, I was walking past a conference room and heard a really good synthetic voice. Poked my head in to see what was going on and learned about a software library that could compress sound down to a reasonable size and yet maintain very good fidelity. I got really excited about it because I had wanted to do a child's program to teach kids the alphabet but hadn't been able to get around the audio size issue. The library solved the issue. I pitched the idea and Talking Teacher, my last Imagic product, started up.
One of the nice things about working at Imagic was you were given a lot of latitude to figure stuff out. First thing I needed was a paint program that would produce small graphic files. I invented a gif-like format and wrote the program Imagic's artist could use to build the graphic files. That took a couple of weeks. I then attempted to build a vector-driven motion system that would compactly drive the sprites. There was going to be a lot of animation and I needed to worry about disk space constraints.
Finally, I needed a way to load everything as needed but it had to be much faster than what the Commodore could handle by default. I figured out how to program the disk controller and came up with a cross-loader that would put my code into the controller and speed up the transfer rate. Since I was only going to support my own requirements, it was several times faster than the builtin library. Had I been thinking a little bit harder, Imagic could have sold just the driver and we would have beat the guys who did exactly that by several months.
There went two months doing all that before I had line one of the product. The program shipped a few months later just as Imagic closed the doors in Saratoga.
Towards the end, we ended up with a system where we'd pay the artists, musician, and sound designer a share of the royalties. Talking Teacher got built that way though in the end, it didn't matter as there weren't any royalties.
Spent the next 8 months getting things going. First thing I did to my Mac 512 was quadruple the RAM to 2 megs to use as my development machine. I'd load the compiler, editor and code onto a RAM disk and work from that. Dave went with a hard drive instead. My environment ran circles around his as I was never waiting on IO - the CPU was my bottle neck.
We split the spelling checker code into segments. I wrote the interface and spell checker, Dave wrote the file handlers. We debuted at the January 86 Macworld when the Mac Plus came out. The Plus saved our bacon. Turned out that the Mac 512 wasn't selling - they had sold something like 8 of them nationwide in August of 85. Damn good thing I didn't know that at the time.
Dave and I had trouble getting along as business partners so we dissolved Greene-Johnson and I started Greene Inc in 87. Wrote QuickDex based on an app that Bill Atkinson wrote at that time. Robin Casady showed me the app and said he thought it needed to be a desk accessory instead. Robin was right. I spent several months writing the code and learning about Boyer-Moore's algorithm. That algorithm was at the core of the search and I believe is responsible for QuickDex's popularity. Thank god software wasn't patentable back then or QuickDex wouldn't have seen light of day.
QuickDex was doing ok but the big hit came as a result of a letter I wrote Patrick Buckland. He'd written a shareware game that had a lot of charm so I sent him his $10 fee and suggested that if he ever wanted someone in the U.S. to publish his code, I'd love to. A few months later a revised black and white Crystal Quest arrived. It was a revision of his shareware game. Just about that time, I was invited to Cupertino to see the Mac II. The obvious idea was to redo the Crystal Quest graphics to run in color before we released it. Apple gave us a loaner which went to Patrick in England.
Crystal Quest was a huge hit and Greene Inc was off and running. Meanwhile, Robin and I had been sharing advertising space in Macworld magazine and sharing booth space at Macworlds. Robin was having trouble paying his bills. He was running CasadyWare which sold fonts but they weren't moving as well as they had initially.
Robin had an asset I desperately needed - a merchant credit card account. They were really hard to come by - mail order software was a brand new thing and the banks had just been badly burned by Icon Review's flameout. The banks wouldn't let me take credit cards so I was using CasadyWare's account to bill customers. If CasadyWare died, I would be in big trouble without the merchant account. I bought CasadyWare and to keep the banks from realizing they almost got burned yet again I dissolved Greene Inc and renamed CasadyWare Casady & Greene.
Aside from day to day operations, I spent time doing two key tasks. I'd do tech support for an hour or so to get a feel for what issues bothered our customers. That helped shape rewrites of the manuals to make instructions clearer. We would run maybe 2000 manuals at a time and revise them based on that feedback.
The other payoff was we got a product out of the time I spent on tech support.
The Mac had a flat memory model which meant that any thread that misbehaved could bring down the machine. Quite frequently, we'd get a support call due to a startup program stepping on us or the OS. The problem boiled down to figuring out which program was the miscreant. After doing the same thing on multiple tech calls, it was obvious we needed a tool to automate the process for the customer and Conflict Catcher was born.
Besides tech support, I spent the balance of my time talking with the developers. We'd hash out algorithms and talk about interface design. As a publisher, we wanted our customers to be able to pick up our products and have an immediate sense of how to use it. The manual was for tips and small details - the program usage had to be self evident like a video game. A common graphics design language helps that immensely.
One of the big things the Mac brought to computers was a standard interface language. You can't imagine how big a deal that was if you haven't worked with a command line environment.
You sort of see similar things today on the iPhone. For example to delete a list item in the phone app requires a different action than deleting a to do list item in the reminder app. Same basic operation being done two entirely different ways. Back then, Apple had staff whose sole job it was was to look at third party programs and send the developers notes saying "You can do things your way but if you want to make your program sell better, try this way..." and then they'd describe the Mac way of displaying and scrolling a list or whatever. It made a hell of a difference in making the Mac what it is.
If Apple still did that, the to-do/phone apps would provide a common way to delete list items.
Microsoft's ribbon interface is an example of how badly developers can screw up interfaces. The lead developer spoke at a conference describing the process they went through and at one point he's quoting his wife yelling from another room "Honey, where's the sort tool?" When your interface gets your wife is lost, that should be a huge clue you're doing it wrong.
Just about that time, other parents started grousing about how little their children were learning. We 6 families got together and another parent and I started teaching a Mathcounts program at the middle school. We did that for a couple of years and kept being frustrated by the fact that these bright middle school kids didn't have any arithmetic. I mean on the order of not knowing that 5+3 was 8. That obviously made algebra much harder for them. They didn't have any arithmetic because calculators were introduced to them in first grade. The end result was the kids were innumerate. A glowing LCD doesn't give you a feel for the underlying arithmetic. Punch * when you meant + and sans any number sense, you won't see the error.
Based on that, Pam (Durkee) and I started Mathability. Pam and I mapped out the lesson order, calibrated the tests and then deployed them to 30 4th and 5th graders. One grading session explained to me why the teachers weren't doing it. It took for bloody ever to grade the work. So I wrote a tool we call Autograder that reads the tests, scores them and figures out which test comes next. I again lucked out because NIST published the image recognition code I needed to read the kid's handwriting.
Back then, we had to optimize and re-optimize to fit in the constraints. Moore's law covered a lot of programming warts - code too slow? Buy a faster computer. That only works on the steep portion of the Moore's curve. Now that hardware performance is leveling off, there's going to be a lot of room to speed code up by resorting to the same tricks we used back when we had to fit in 4k ROMs. Games will only get more amazing as that process plays out.
Ferg: Where and when were you born? Please be as vague as you'd like, or you can skip this one.
Michael Greene: Las Vagues in the last century. Vague enough? :)
F: What were your hobbies growing up? Did they inform the career you have today?
MG: My father and I used to solve puzzles together. He was blind and so had a lot of time at home which I was the beneficiary of.
F: What subjects did you enjoy in school? Can I assume math was a big one for you?
MG: Math was on and off. I didn't particularly care for high school math with the exception of geometry which I liked quite a bit. My Geometry teacher was a stickler for proofs and she flunked me the first go-round because I didn't do my homework. Problem solving has always been something I've enjoyed. I was really lucky to have some good high school history teachers as well. Two of them were both really good at getting you to forget what you know now and place yourself in the shoes of the people faced with making decisions at the time. Not only did you have to deal with incomplete information, you had to take in the prejudices of the age - the later being really, really difficult to do but helped immensely in making sense out of decisions that seem wacko today.
I spent way too long getting my degree. Can't believe how patient my parents were in retrospect. A few courses stand out - took an intro to genetics class as a junior that was great. Got a D and felt lucky. The course was graded on the curve and there were folks in that class that may end up getting a Nobel - they're blow away brilliant. Re-took the course to erase the D and did fine the second time around but it taught me a clear lesson - I wasn't going to be a first-class researcher if I had to take a course twice when my potential competitors could ace it in one go.
F: Where did you go to college, and what did you study there? What degree(s) did you get?
MG: Several colleges. My high school counselor forgot I existed and around February, I wandered in and asked if we shouldn't have a conversation about college. Of course, many schools had already made their selections and I ended up at Colorado School of Mines. A bad fit. 500 horny guys and 6 women in the freshmen class.I like women so I left after my freshmen year. Couldn't get into Berkeley so ended up at Riverside for a year waiting to get into Berkeley. On a whim, I went down to UCSD to see the campus and really liked what I saw so applied there as well. Got in. How I did I have no idea. I was sitting in the Dean's office waiting for the Dean to meet with me and the incoming freshmen class SAT scores were on his table. The average was around 1500 with lots of perfect 1600's. I wasn't in their league and simply had to hustle to keep anywhere near them (witness the D.) Seeing that list was a serious wakeup call. It explained why so many of my friends could seldom study and ace tests where I struggled to just understand the questions. Dated a woman who had a photographic memory, could type 80 wpm with two fingers, reviewed movies on the side for the San Diego newspaper etc.
It took me a couple of years to figure out what I could do and while I was casting about, I was writing software. Took some CS courses but didn't care for them much - way too much theory which at the time, didn't appeal to me much. I understood the rationale but I was more interested in coding than talking about algorithm efficiency. I just wasn't ready for CS.
Ended up in the Econ department. I liked economic theory but gradually came to realize it was bs. The pretty curves were more speculative than based in reality. Before I realized that, I wrote a few economic simulations for one of the econ profs. He liked what he saw and hired me after I graduated to work on an econometric model of San Diego County. I was a data grunt which meant I was tasked with keypunching the data the group would dig up Lord knows where.
Long story short, the model they built sucked but looked good when it was delivered to the county. Too much curve fitting and not enough data to back up the curves or underlying economic activity.
That experience soured me on model building so I got a job as a programmer in LA. They had promised they were going to get a Burroughs computer to run the business on and UCSD was one of the few schools that had a Burroughs mainframe so I was a shoo-in for the job. The Burroughs under-delivered, the manager who bought it got fired and his boss replaced it with a 15-year old IBM 360. When I saw what a PITA JCL was and that batch programming was going to be the future at that job, I moved to System Development Corp to build a radar system for Morocco. The new boss realized he had seriously screwed up when 3 out of 4 programmers quit within a few months. The one who remained was able to command a huge pay increase. It worked out well for all of us. :)
The King of Morocco had seen a movie that had a wall-sized radar display and so he wanted one just like it. SDC sold him one and I was hired to help write the software which was going to run on Burroughs 7700. The B7700 was a 16 Mhz room-filling behemoth. That job was a lot of fun. I was working for a very competent manager who was smarter and funnier than hell.
He was responsible for the radar subsystem and had tasked me with reverse-engineering the compiler's data structures so the project could have a data dictionary generated from the programmer's code. He'd walk around to see what people were doing and noticed he frequently saw his staff waiting for a compile to finish. He got worried that perhaps the B7700 wasn't going to be up to the task of managing 2000 radar returns per minute so he sat down and wrote a couple of programs to see what was going on. He wrote a process that did nothing but generate radar packets and another program that did nothing more than receive those packets via the mechanism we were going to use in production. It could barely handle a few hundred packets doing nothing else but transmitting and receiving. Never mind generating the wall display for the King and radar consoles.
At that point, he got really worried and wrote a memo alerting his superiors of the issue. No response. That pissed him off so a few days later he wrote another memo that said the same thing but was titled "I know you're out there, I can hear you breathing." That got the necessary response and the long job of figuring out what was wrong with the hardware started.
About that time, he got recruited by a former boss of his and went to work for a company that built hard disk controllers. Back then, they were refrigerator sized and built by hand. My boss offered me a job at a 50% increase in pay and I followed him.
You might think a 16 Mhz machine could no way handle 2000 returns but there were plenty of systems back then that handled lots of work on miniscule hardware. American Airlines was running their reservation system on a slower machine and they were kicking 4000 reservations per minute which was enough to handle the country. The code had to be optimized and the OS portion barely existed - the app owned the hardware.
F: Where did you learn programming, was it at Colorado or before that?
MG: Learned Fortran at Colorado on a 32 kbyte computer. Another room-filler albeit a small room.
F: Did you work anywhere else after college? When did you start working for Imagic? Did you work for them specifically or were you a contractor? How did that come about?
MG: My wife and I were kidnapped while we were in LA. We had planned on leaving LA to raise a family so we bumped our plans up and moved to Monterey. Continued working in my old job on a leased line. The company went tits up when the hardware guru couldn't deliver the next gen controller on time.I consulted on HP equipment for a couple of years and between gigs saw an ad for a little card that would let you program the Atari 2600. You used a little keypad to hand enter your code and there was a small debugger that would let you set breakpoints. Built a breakout box that enabled me to write my code on a CPM-80 micro-controller and transfer the code to the Atari. Wrote some little games to learn how the 2600 worked and thought it was quite a bit of fun. I really liked the 6502 cpu as it had a clean instruction set.
Saw Demon Attack on sale and sent Imagic a letter asking if they needed programmers. I showed them my breakout box and they thought what I had been able to figure out was good enough to offer me a job.
The Imagic programmers were first rate and again, I was at the bottom of the stack. One guy, Bruce Pederson, was amazing. Without any documentation whatsoever, he attached an in-circuit emulator to a VCS and reversed the entire video architecture - including the special registers that doubled or tripled the sprites along with the requisite code timing issues. Took him two days to do it.
Later on, he ported Demon Attack to the Vic 20 in a month. Didn't read Rob Fulop's code. Just played the game for a day or so, and then sat down and coded the port from scratch. In assembly. As I recall, the sounds were spot on despite the sound hardware being completely different on the two platforms. I think he ended up as a VP at Altera the FPGA company. One of those blow-away brilliant minds.
F: What types of games did you do for the 2600 before you got to Imagic, and do you still have them?
MG: I
wrote a couple of econometric models at UCSD for my econ prof's econ 1a
class. He used them as exercises for the class. They're long gone.
F: Did you do any games or any type of programming at Imagic before you started on No Escape (I am assuming again that No Escape was done before Wing War), or did you work on anything else besides those two games?
MG: No Escape was my first cart. Then Wing War. I wrote Star Wars for Parker Bothers on the Commodore 64. One day, I was walking past a conference room and heard a really good synthetic voice. Poked my head in to see what was going on and learned about a software library that could compress sound down to a reasonable size and yet maintain very good fidelity. I got really excited about it because I had wanted to do a child's program to teach kids the alphabet but hadn't been able to get around the audio size issue. The library solved the issue. I pitched the idea and Talking Teacher, my last Imagic product, started up.
One of the nice things about working at Imagic was you were given a lot of latitude to figure stuff out. First thing I needed was a paint program that would produce small graphic files. I invented a gif-like format and wrote the program Imagic's artist could use to build the graphic files. That took a couple of weeks. I then attempted to build a vector-driven motion system that would compactly drive the sprites. There was going to be a lot of animation and I needed to worry about disk space constraints.
Finally, I needed a way to load everything as needed but it had to be much faster than what the Commodore could handle by default. I figured out how to program the disk controller and came up with a cross-loader that would put my code into the controller and speed up the transfer rate. Since I was only going to support my own requirements, it was several times faster than the builtin library. Had I been thinking a little bit harder, Imagic could have sold just the driver and we would have beat the guys who did exactly that by several months.
There went two months doing all that before I had line one of the product. The program shipped a few months later just as Imagic closed the doors in Saratoga.
F: Did you choose the Greek mythology theme yourself, or was it assigned to you? If you chose it, why? Forgive me if you already listed this as one of your interests.
MG: The Greek look was the artist's idea. I had started with a different theme. The Imagic artists were great and if they came up with something, it was always much better than what I'd originally thought of.
F: How long did it take you to program the game, if you remember? Were there any particular stories you have of programming the game?
MG: About 6 months I think. I was also working with a consultant who was building a cart display box so retailers could let customers play with all the Imagic titles. You'd key in a number and that cart would load up in the VCS. I recall being appalled by the cover photo. I thought it looked god awful.
F: I found some info on you from another Atari collector about Wing War. You said you don't remember much about it, but you did mention turning it into a helicopter game. Was this because it was thought it would sell better?
MG: Boy that completely eludes me. I don't remember helicopters at all. I do recall not liking how it was turning out. I was managing some outside contractors, one of whom wrote a helicopter game.
F: Wing War is a beautiful game, and I have read that some of the Imagic games were done with graphic artists. Were both of these games done solely by you, or did you have help?
MG: I did zero art. All of the art work was done by the Imagic artists. Initially, they were just salaried. Rob Fulop came up with the idea of tipping the lead artist $2,000 for his work. We all chipped in and bought him a briefcase to stuff it with $1 bills. It was pretty funny when he opened the really nice briefcase which he had thought was the whole gift and saw the cash. The 2000 bills was also Fulop's idea - he had a great sense of humor.Towards the end, we ended up with a system where we'd pay the artists, musician, and sound designer a share of the royalties. Talking Teacher got built that way though in the end, it didn't matter as there weren't any royalties.
F: Did you put any easter eggs in your Atari games?
MG: Yeah but they're lost to history.
F: You mentioned managing outside contractors at Imagic, do you remember
who any of them were? Or any of the games they did besides the
helicopter game you mentioned?
MG: There were three different groups.
One was Indian. If I recall correctly, Hudson wrote another but that's
really foggy. There was a third but it's been so long I don't remember
specifics.
F: When did you leave Imagic?
MG: On the second to last layoff when we were occupying Activision's old haunts. Late 84, early 85 as I recall.
F: I know (from Wikipedia) that you had your own company around this time that created QuickDex, did you do the programming on that? How did your partnership with Robin Casady come about, and when did that start?
MG: Dave Johnson and I got laid off at the same time. We had been commuting together from Santa Cruz and so we got to talking about what we might do next. Dave had convinced Imagic to spring for a Mac 128 when they debuted. Dave was an optimist who ignored anything that contradicted his outlook. The original Mac required multiple disk swaps to save a file, load a program and anything else. He thought it was great. I thought it was absurd. Nice idea but no thanks if you're swapping disks all day. Apple quadrupled the RAM a few months later and that looked a lot more interesting. He convinced me we could build a spelling checker for it and do OK. Greene-Johnson was started.Spent the next 8 months getting things going. First thing I did to my Mac 512 was quadruple the RAM to 2 megs to use as my development machine. I'd load the compiler, editor and code onto a RAM disk and work from that. Dave went with a hard drive instead. My environment ran circles around his as I was never waiting on IO - the CPU was my bottle neck.
We split the spelling checker code into segments. I wrote the interface and spell checker, Dave wrote the file handlers. We debuted at the January 86 Macworld when the Mac Plus came out. The Plus saved our bacon. Turned out that the Mac 512 wasn't selling - they had sold something like 8 of them nationwide in August of 85. Damn good thing I didn't know that at the time.
Dave and I had trouble getting along as business partners so we dissolved Greene-Johnson and I started Greene Inc in 87. Wrote QuickDex based on an app that Bill Atkinson wrote at that time. Robin Casady showed me the app and said he thought it needed to be a desk accessory instead. Robin was right. I spent several months writing the code and learning about Boyer-Moore's algorithm. That algorithm was at the core of the search and I believe is responsible for QuickDex's popularity. Thank god software wasn't patentable back then or QuickDex wouldn't have seen light of day.
QuickDex was doing ok but the big hit came as a result of a letter I wrote Patrick Buckland. He'd written a shareware game that had a lot of charm so I sent him his $10 fee and suggested that if he ever wanted someone in the U.S. to publish his code, I'd love to. A few months later a revised black and white Crystal Quest arrived. It was a revision of his shareware game. Just about that time, I was invited to Cupertino to see the Mac II. The obvious idea was to redo the Crystal Quest graphics to run in color before we released it. Apple gave us a loaner which went to Patrick in England.
Crystal Quest was a huge hit and Greene Inc was off and running. Meanwhile, Robin and I had been sharing advertising space in Macworld magazine and sharing booth space at Macworlds. Robin was having trouble paying his bills. He was running CasadyWare which sold fonts but they weren't moving as well as they had initially.
Robin had an asset I desperately needed - a merchant credit card account. They were really hard to come by - mail order software was a brand new thing and the banks had just been badly burned by Icon Review's flameout. The banks wouldn't let me take credit cards so I was using CasadyWare's account to bill customers. If CasadyWare died, I would be in big trouble without the merchant account. I bought CasadyWare and to keep the banks from realizing they almost got burned yet again I dissolved Greene Inc and renamed CasadyWare Casady & Greene.
F: Casady and Greene did mostly Mac applications, and then started doing games a few years after. Did you have any hand in any of the programming for the apps or the games, or were you mostly managing?
MG: I maintained QuickDex but most of my time was spent running C&G. Where Quest had skyrocketed and then dropped off, Qdex sales continued plugging along. I would periodically sit down and work on a revision to QuickDex that included several features customers had asked for, the hard one being a free-form database that included fields if desired. Aside from day to day operations, I spent time doing two key tasks. I'd do tech support for an hour or so to get a feel for what issues bothered our customers. That helped shape rewrites of the manuals to make instructions clearer. We would run maybe 2000 manuals at a time and revise them based on that feedback.
The other payoff was we got a product out of the time I spent on tech support.
The Mac had a flat memory model which meant that any thread that misbehaved could bring down the machine. Quite frequently, we'd get a support call due to a startup program stepping on us or the OS. The problem boiled down to figuring out which program was the miscreant. After doing the same thing on multiple tech calls, it was obvious we needed a tool to automate the process for the customer and Conflict Catcher was born.
Besides tech support, I spent the balance of my time talking with the developers. We'd hash out algorithms and talk about interface design. As a publisher, we wanted our customers to be able to pick up our products and have an immediate sense of how to use it. The manual was for tips and small details - the program usage had to be self evident like a video game. A common graphics design language helps that immensely.
One of the big things the Mac brought to computers was a standard interface language. You can't imagine how big a deal that was if you haven't worked with a command line environment.
You sort of see similar things today on the iPhone. For example to delete a list item in the phone app requires a different action than deleting a to do list item in the reminder app. Same basic operation being done two entirely different ways. Back then, Apple had staff whose sole job it was was to look at third party programs and send the developers notes saying "You can do things your way but if you want to make your program sell better, try this way..." and then they'd describe the Mac way of displaying and scrolling a list or whatever. It made a hell of a difference in making the Mac what it is.
If Apple still did that, the to-do/phone apps would provide a common way to delete list items.
Microsoft's ribbon interface is an example of how badly developers can screw up interfaces. The lead developer spoke at a conference describing the process they went through and at one point he's quoting his wife yelling from another room "Honey, where's the sort tool?" When your interface gets your wife is lost, that should be a huge clue you're doing it wrong.
F: Were you still a part of Casady and Greene when it closed, or had you gone on to Math*Ability by then?
MG: I left C&G in 91.
F: How and when did you become involved with Mathability? Have you done any programming with Mathability, or with anyone else since Casady and Greene? I took the longer placement tests on your site, I was dismayed to find out how long it took me to complete them.
MG:I had enough to live on after leaving C&G so I spent the time paying a lot of attention to my boys. At some point, I realized my younger son's teacher didn't know arithmetic and was mis-teaching him. I took him to Kumon to compensate and thought it was a good idea but way too expensive to deploy in a classroom. The experience with the teacher got me to thinking about how to manage a school and how to detect incompetent staff. My son's school had clearly failed in the later case - even after I pointed out the issues with the specific teacher that teacher remained on staff for several more years.Just about that time, other parents started grousing about how little their children were learning. We 6 families got together and another parent and I started teaching a Mathcounts program at the middle school. We did that for a couple of years and kept being frustrated by the fact that these bright middle school kids didn't have any arithmetic. I mean on the order of not knowing that 5+3 was 8. That obviously made algebra much harder for them. They didn't have any arithmetic because calculators were introduced to them in first grade. The end result was the kids were innumerate. A glowing LCD doesn't give you a feel for the underlying arithmetic. Punch * when you meant + and sans any number sense, you won't see the error.
Based on that, Pam (Durkee) and I started Mathability. Pam and I mapped out the lesson order, calibrated the tests and then deployed them to 30 4th and 5th graders. One grading session explained to me why the teachers weren't doing it. It took for bloody ever to grade the work. So I wrote a tool we call Autograder that reads the tests, scores them and figures out which test comes next. I again lucked out because NIST published the image recognition code I needed to read the kid's handwriting.
F: What do you like to do for fun now?
MG: I'm working on a hardware project. More of the same - problem solving which I continue to love doing. Even if it still takes me three years and a note from God to do it.
F: I just want to mention that indirectly because of you, I might not be
doing this podcast. If you hadn't bought Casadyware, and Casady and
Greene hadn't later distributed SoundJam MP which begat iTunes, the
podcast landscape may have looked vastly different or maybe not have
existed at all. So thank you for that, and again for your answers.
MG: Jobs chose Soundjam among several possible choices. Had Soundjam not existed iTunes would have existed anyway.
F: Do you have any opinion on the video games industry today?
MG:
Damn amazing how Moore's law has played out. The industry seems to
cycle around just as it did when I was in it. Game play is important
then it's superseded by graphics which get stale and then it's game play
again. The impact phones have had is great - small form factor and
limited choices make for some really great games. Then again, Steam's
stuff is wonderful on a huge monitor.Back then, we had to optimize and re-optimize to fit in the constraints. Moore's law covered a lot of programming warts - code too slow? Buy a faster computer. That only works on the steep portion of the Moore's curve. Now that hardware performance is leveling off, there's going to be a lot of room to speed code up by resorting to the same tricks we used back when we had to fit in 4k ROMs. Games will only get more amazing as that process plays out.
Wednesday, February 5, 2014
IA 3204, Cosmic Ark, and IA 3312, No Escape!
Hi ho! Today's episode is about the Imagic games Cosmic Ark and No Escape. Love both of them, No Escape was a new one on me. I love finding these hidden gems in the 2600 library! Next week it's Missile Command and Dodge 'Em by Atari. Upcoming games include Space Cavern and Racquetball by Games by Apollo; Blueprint and Solar Fox by CBS Electronics; Stampede and Ice Hockey by Activision; Othello and RealSports Baseball by Atari; Fast Eddie and Deadly Duck By Sirius/20th Century Fox; and Surround and A Game of Concentration (aka Hunt 'n' Score) by Atari. Send your stories and memories for any of these games to 2600gamebygame@comcast.net. I read all of the submissions on the show. Eventually. :(
Be sure to keep an eye on the blog for my Q&A with No Escape programmer Michael Greene! Thank you so much for listening everyone!
Pertinent Links
Zap arcade game on KLOV
Space Zap on KLOV
How to Beat the Home Video Games - Cosmic Ark
Rob Fulop's blog about Cosmic Ark
Atari Age thread on Cosmic Ark star field
Easter egg/bug page for Cosmic Ark on 2600 Connection site
1985 Talking Teacher review by Edward Semrad
MATH*Ability video
MATH*Ability web site
Cosmic Ark source code
Favorite Atari 2600 Games of Focus RS - Cosmic Ark
Be sure to keep an eye on the blog for my Q&A with No Escape programmer Michael Greene! Thank you so much for listening everyone!
Pertinent Links
Zap arcade game on KLOV
Space Zap on KLOV
How to Beat the Home Video Games - Cosmic Ark
Rob Fulop's blog about Cosmic Ark
Atari Age thread on Cosmic Ark star field
Easter egg/bug page for Cosmic Ark on 2600 Connection site
1985 Talking Teacher review by Edward Semrad
MATH*Ability video
MATH*Ability web site
Cosmic Ark source code
Favorite Atari 2600 Games of Focus RS - Cosmic Ark
Subscribe to:
Posts (Atom)