About half that time back, I wrote up a summary of how my
computer game "IFR (Flight Simulator)" came about.
Recently, though, I've come across some old artwork and photos
from that era. And found that folks interested enough in
the old Vic-20/Commodore 64 games to post videos to YouTube.
So...this is an update to the old writeup, with some additional
detail. I've also added some technical detail, but if you
aren't interested in code and process ideas, you can just skip
those bits.
One type of added material is kind of a follow-on to IFR.
It really changed my life, and not just in the sense of making a
lot of money. It actually directed...and helped...my
engineering career.
Introduction
I'm a bit old-fashioned. I was taught to be modest; to not
brag about my accomplishments. I've posted a lot of my
experiences over the years to the aviation newsgroups, but in
all but very few cases, they've been along the lines of "Well,
look what stupid thing I've done now...."
If I'm going to tell the "IFR Flight Simulator" story, though, I
have to abandon my usual themes of ignorance, stupidity, and
luck. Most of us have defining events of our lives, and
there's no question that "IFR" was one of the biggest ones in
mine. To tell the whole story, to fully explain how things
came about, I'll have to grit my teeth and abandon
modesty. For once, I *did* do something right.
As you'll see, though, one of my usual traits still shines
through: Luck. Luck in catching the home-computer frenzy
early, luck in making some decent decisions early-on, luck in
finding a decent, honest, company to market "IFR," and luck in
making the right friends. Especially the friends.
I'll have to apologize for any gaps or VIC-20 faux-pas in the
following. It's been a long time since I last fired up my
VIC, and I finally abandoned using Commodore computers in the
mid-90s. I kept a scrapbook from the period, which
helps. I've got all the hardware, even all the
tapes. But a subsequent move has apparently buried my
hard-copy of the code itself. So I'm going to have to
resurrect some of the programming details from rather faulty
memory.
I'm editing this on a PC with six gigabytes of memory and a
three gigahertz clock speed. There's 256 Gigabytes of Read
Only Memory in a solid state drive, with a 1 Terrabyte (1000
Gigabytes, 1,000,000 Megabytes, or 1,000,000,000 kilobytes)
conventional hard-drive for storage.
It's hard to think back over 30 years, to when I bought my first
computer. I was just out of the Air Force, freshly married,
working as a junior engineer for one of the biggest aerospace
companies in the world.
Home PCs were all the rage. It was 1982, and IBM was
selling its 8086 machine for about $2,000.
Now, $2,000 for a computer is kind of high today, but that was a
HECK of a lot of money in 1982. It was about a tenth of
what my Lieutenant's pay had been at the time I'd left the Air
Force.
Fortunately, a bunch of upstart companies were introducing
"Computers for the rest of us." There was the
Timex-Sinclair 1000, the Atari 400, the TI-99...and the
Commodore VIC-20
I was facing some minor surgery that would lay me up for a
couple of weeks, and thought that it'd be a good time to get a
computer so I'd have something to fiddle with.
We lived on a hill overlooking a shopping complex, and there
were several computer stores there. At one store, a very
earnest, *very* young man explained the virtues of the VIC-20 to
me. I was completely computer-illiterate, but Dave Paulsen
was able to make it understandable.
The VIC had a full-size keyboard, a definite
plus. In fact, the whole computer was built into the
keyboard.
It used the TV for a display device, showing 23 columns and 25
rows of rather squat characters. In addition to the full
upper-and-lower case character set (an advantage over some of
its competitors) it also had a bunch of characters shaped like
triangles, etc. that could be used to build shapes. It had
3.5K of RAM. To put things better in proportion, that's
0.0035 Meg. Clock speed was about 1 Mhz, more than a
thousand times slower than today's standard.
I paid my $300 for the computer and went home happy. After
a couple of days I was back...it was getting too tiresome to
have to retype the programs in all the time, so I sprung $40 for
the Commodore "Datasette"; their storage device using standard
cassette tapes. The Datasette was one of the drawbacks of
the VIC, as far as I was concerned...other companies' computers
used a conventional cassette recorder.
Anyway, I programmed happily away. As a newlywed in a new
job, money was tight, so I didn't buy any games. I wrote
my own. I don't recall any particular details of these
early games, except for one. It was the typical artillery
game, where you entered in the angle of the gun barrel, trying
to range in on the target. Being a Hornblower fan, I set
it up as a nautical game called "On the Uproll." The
ballistics programming was easy; I spent most of my time getting
the character-graphics navy cannon to recoil across the screen
when it fired.....
IFR started as one of these games. I've got an old flying
buddy who occasionally came to town with his wife to visit her
parents. Rick and I go waaaay back, and love to bicker
about trivia. We automatically take opposite sides of
every issue, just so we could argue it back and forth.
Anyway, Rick and I had done a lot of electronic experimenting in
our high-school days. On one of his visits, he mentioned
he was using a new transducer to build a digital airspeed
indicator for aircraft.
"G'wannnn," I told him. "As I pilot, I want an analog
needle so that trends are more obvious. Flickering numbers
don't tell you as much as a rapidly-falling needle."
We argued it back and forth, to the usual dismay of our
wives. But it didn't end when Rick went back to
Boise. By God, I *knew* I was right...and I would write a
flight simulator program with a digital airspeed readout to
prove it to Rick, the next time he came to town!
I knew displaying an outside view would be way beyond my
programming capabilities, and would probably slow the simulation
down to a crawl even if I *could* write one. The lack of
an outside view didn't bother me. At that time, visual
displays even on REAL simulators were rare, and non-existent on
the ATC-510s and war-surplus Link Trainers that were all the
simulation devices General Aviation ever saw.
The Fundamental Issue
The first problem was how to display the aircraft's
attitude. I needed an artificial horizon (AH), or the
whole thing would be a waste of time.
The ordinary character graphics were too clumsy...they weren't
set with the right charcters for all the conceivable positions
an AH would need. Besides a one-character-wide AH was too
small.
Fortunately, in reading some of the programming magazines, I
discovered how to "reprogram" character definitions to make the
character look however I wanted. I could set up a 3x3
matrix of characters for a bitmapped area for my AH. I
redefined several other characters to surround the gauges to
look like instrument bezels (frames).
But when I programmed the AH in BASIC...it was slow, horribly
slow. That was just a subroutine to draw one
instrument...how slow would it get by the time everything was
working?
I scanned though the VIC's Programmer's Reference Guide. I
had always skipped over the machine-language programming
section, but looked at it with renewed interest. I'd
recently taken an off-hours course at work on programming the
8080 processor, and noticed how a lot of the 6502 codes looked
similar. On the course I'd taken, we'd programmed EEPROMs
by entering hex codes. Reading up on the VIC, it appeared
I could POKE a decimal equivalent into the VIC memory.
Reading the RAM map carefully gave me the hints I'd needed as to
where to put the machine language code.
I still had the programming forms left over from the 8080
course. The Programmer's Guide had the appropriate hex
numbers for the 6502 operations. I hadn't heard of
assemblers or any sort of aids that would let me just enter in
the Op code itself.
Out of that ignorance, I ended up writing a simple
hex-to-decimal-to-POKE routine to program the machine
language. I wrote the Op Code (INP, ROL, etc.) on the
form, then wrote down the proper hex value. The program
let me key in the hex, which it would then convert to decimal
and POKE into memory. The program also saved the resulting
machine language program to the cassette drive.
Fortunately, allocating memory to machine code wasn't a problem
anymore. I'd spent $150 for a 16K memory expansion for the
VIC. That's about nine million dollars per Gig, BTW.
The simple program I wrote to display the AH information worked
blazingly fast...but it had a problem. I wasn't much of a
Machine Langauge programmer...I wasn't able to do more than a
"four-banger" calculator could do. I couldn't come up with
an easy way to do Sines and Cosines, so I used a "cheat" routine
to compute the relative tilt of the AH based on the roll angle
of the aircraft.
Unfortunately, the "cheat" didn't have a 90-degree point.
It worked up to about a 60-degree bank, but the line started
distorting past that.
But as I considered *why* I was writing the simulator, I
realized I didn't need it to be able to roll past 60
degrees. You don't fly aerobatics in instrument
conditions. And having the BASIC program handle the
control reversals involved with rolling inverted, etc. slowed
the program down just too much.
So I made the decison: The flight model wouldn't allow rolling
to ninety degrees or flying inverted. What to do about the
AH, though? Older model AHs couldn't handle aerobatic maneuvers
and "spilled" if their limits were exceeded. I merely put
in a subroutine into the AH machine code that changed the
display to "OFF" if roll or pitch limits were exceeded.
The other gauges were simple in comparison. Re-use the
same character graphics to form a bezel, then a line to indicate
the value. Vertical bar graphs for throttle and fuel
indicators, and some simple graphics for landing gear and flap
positions. Text at the bottom to show a "LORAN" position
(GPS wasn't down to the consumer level, yet).
The Airspeed and Altitude, of course, were Text only so I could
prove to Rick that you couldn't fly that way....
Handling
With that, it was time for the flight model. I'd played
around with the early Microsoft Flight Simulator on a friend's
IBM, and there were a couple of things I didn't like about
it. First was the keyboard interface. As a pilot, I
was offended. If I had a flight simulator, it was GOING to
be joystick only.
Second...and probably most important...I didn't like the
"remoteness" of the control feel. Too often, the airplane
operated contrarily to my actions the controls. I'd flown
a variety of aircraft and simulators, right up to a KC-135
simulator at CAP camp. I'd *never* had problems in basic
control.
So however else I worked the flight model, I would always have
it so that the airplane always responded the same way to the
joystick input (except for modes like stalls, of course).
Moving the stick to the right would immediately start a right
roll, you didn't have to "take out" previous aileron inputs
first.
Unfortunately, the VIC-20 used the Atari joysticks, which were
switch-type devices, not analogs. Pulling the stick back
activated a switch, and no matter how hard or far you pulled
back, all that would happen is that that single switch would
activate.
So control would be pretty simple. Pulling back on the
stick would give one pitch rate, and one pitch rate only.
Actually, I used the "fire" button on the stick as a rate
doubler...pressing "Fire" gave twice the rate of control.
But the pilot ALWAYS had control. Once in a roll or
pitched up or down, the airplane maintained that attitude until
the pilot changed it or the airplane stalled or crashed.
With this limitation, the fidelity of the flight model didn't
have to be too close. There was no reason to write a
complex, interactive flight model when the only controls were
the four little switches.
I started with an airspeed model, with an airspeed "delta" being
defined by the throttle position, pitch position, flap setting,
and landing gear extension. Each factor was multiplied by
a constant to set the relative impact of each factor. Also
include was an airframe drag factor that varied by the current
airspeed...otherwise, the airspeed would just keep increasing
without limit. The total "delta" was added to the current
airspeed to compute the new airspeed.
Altitude was handled similarly. The altitude delta
depended upon the pitch angle multiplied by the airspeed, with
flap position causing some altitude drop as well. An
additional decrease in altitude depended upon the amount of
roll, too...that way, the pilot needed to add some back pressure
in a turn to maintain altitude, just like a real airplane.
All of these delta factors were just simple math..though I may
have squared the airframe drag factor in the airspeed
equation. From my earlier programming, I knew that complex
math slowed down the execution speed, so I kept the math as
simple as I could.
Simple? Yes! Accurate? Well, no. But
again, the point was to make it fly right from the point of
view of the person holding the stick. It flew like
an airplane. It didn't automatically start rolling upright
when you released the stick, but some airplanes actually don't
do that.
Time to Fly...Ooops!.
The airspeed calculation looked good, the altitude calcuation
looked good, the AH was working, and the airspeed and altitude
readouts were simple PRINT statements. Time to fly!
I started the program...and immediately the altitude dropped
from zero to negative numbers. This started the second,
probably most frustrating part of programming a flight
simulator: Getting all the subsidiary rules to work right.
What had gone wrong? Well, I had nothing in the program to
detect WHEN THE AIRPLANE WAS ON THE GROUND. It just
calculated its new altitude, and the program didn't care if the
altitude was negative.
There were a lot of things like that that had to be caught and
accounted for. Like I mentioned earlier, the program would
always change attitude based on pilot input on the simple
four-switch stick. But, of course, it SHOULDN'T do it when the
airplane was sitting still on the ground! And if the
airplane is rolling along at 25 MPH, moving the stick back
should lift the nose off the ground...but the effectiveness
should be less than when the plane is moving at 75 MPH, and
moving the stick to either side shouldn't cause the plane to
bank. If the plane is banking at 45 degrees, moving the stick
back shouldn't cause pitch-up at the same rate as in level
flight.
The computer, of course, didn't know it was simulating an
airplane. All it knew was the programming I told it. So I
had to set a number of flags, gimmick some of the basic flight
equations, and include IF-THEN statements to cover wide variety
of flight conditions.
With the basic laws set, it was time to tweak the flight-dynamic
constants. I wanted the airplane to fly like a common
light aircraft, so I diddled the constants to produce the proper
rates of climb and cruise speeds for the Cessna 172.
This was one of the more enjoyable aspects, since it involved
"test flying" the simulator. Establish level flight, then
drop the flaps...how much should the airspeed sag, and how
should the altitude start dropping? If it seemed too much
or too little, change the constant for that factor and try it
again.
(It was necessary to have the altitude decrease with flaps
lowering...the pilot had to apply power and pitch up to maintain
altitude. The plane thus ended in a nose-high pitch
attitude in level flight...just the sort of realistic effect I
was looking for.)
I got the flight dynamics working pretty good. The only
unrealistic result is that the Best Rate of Climb speed came out
at about 90 MPH...a bit more than the actual 172RG.
Considering the simplicity of the model, though, I was happy
overall.
And wonder of wonders, Rick had been right. Flying
with the digital airspeed and altitude displays wasn't much
different than using analog gauges. I hadn't flown
regularly since going into the Air Force six years
earlier. I *really* enjoyed "test flying" the simulator.
With the dynamics up to snuff, it came time for the REAL fun
programming: Problem subroutines!
Something I didn't mention earlier is that I had
some prior flight simulator experience, in that I helped restore
a WWII model Link Trainer a few years' prior to IFR. The
Link is an analog computer in vacuum (uses a vacuum system to
"store" altitude, has an vacuum manifold for the airspeed value,
etc. I ended up using the Link Trainer systems as direct
inspirations for IFR.
Take stalls. On the Link Trainer, a pendulum is held
forward by the airspeed vacuum manifold and the pitch
position. If the airspeed drops too low for the current
pitch angle, the pendulum drops back, leaking vacuum out of the
altitude storage tank. It also triggers another pendulum,
which drops left or right depending upon rudder position and
puts the Link into a spin.
I pulled the same sort of thing with IFR. I wanted stalls
to be a BAD thing, not the gentle experience they often
are. So when the airspeed dropped below the limit value
(set by bank angle and flap position), the nose dropped a LOT
and the plane ALWAYS spun. I didn't have rudder pedals, so
had a random number generator pick the spin direction if wings
were level, or spun the opposite direction from the bank if the
plane was tilted.
I once accidentally spun an airplane...with Rick in the back
seat, in fact. I was in a tight left turn when, all by
itself, the plane rolled in the opposite direction and the nose
dropped to point us nearly at the ground. I remember the
panicked feeling in my gut when that happened...and was glad I
was able to reproduce it in IFR.
Turbulence generation came almost directly from the Link.
The Link used vacuum bags to control the fuselage
attitude. A small motor turned a set of cams, which could
be cranked into close to a set of keys like a piano. When
a cam hit a key, vacuum was leaked from one of the bags.
In IFR's case, I generated a random number and XORed it with the
output from the joystick! A magazine mentioned the memory
locations that set the display X and Y positions, so when
turbulence bumped the airplane, I had the instrument panel jerk
up/down/left/right as appropriate.
Other subroutines were fun. Fly too fast and exceed Red
Line? Do burst of white noise for a loud rushing noise
from the speaker, and have the airplane pitch down at 45
degrees, rocking the wings as it plummeted into the ground.
Land gear up? Shake the panel up and down with a scraping
sound from the speaker as the plane slides on its belly with the
screen shaking and scraping noise reducing as the plane slows to
a stop.
Crash into the ground or land with too much bank? Change
the screen to RED with an explosion.
Land going too fast? Have the pitch pop up as the plane
bounces.
Land off the runway? Increase the drag factor due to the
mud, and shake the screen as the plane taxis over rough
ground. Use the random number generator to taxi the plane
into a "Tree" on occasion to discourage off-runway operations.
Other instruments were added. I added a turn needle,
basically as a backup for if the AH spilled. Fuel quantity
was easy, and fuel burn rate worked linearly with throttle
position. A VSI was simple enough.
On the Map
Once the flight model and the instruments were
working, it was time to actually fly the plane SOMEWHERE.
I drew up a map, including four airports and a mountain
range. There ws a high straight pass on one leg of the
L-shaped range, and a lower Z-shaped pass on the other
leg. I used an ordinary Sine/Cosine calculation with the
speed to determine the movement over the map, and a simple
machine language routine to determine the height of the ground
at any particular location. Postion was given to the pilot by a
digital display of Latitude and Longitude at the bottom of the
screen.
Or at least, they were similar to Lat and Long. The map
itself was initially 256 miles across (don'cha love 8-bit
systems). I started by displaying the numbers as Lat and
Longs...but soon realized that 256 miles doesn't cause a real
big difference in lat and long (about 4 degrees total, in
fact). I didn't want to be flying by noting the fourth
decimal places, so I dropped the total map scale down from 256
miles. On my first flight betwen the two farthest-apart
runways, I soon realized that my actual time in flight would
approach *two hours*...most of which was the droning along in
flight that's the most boring part of flying. So I scaled
the map down by a factor of ten.
One other item that came out of this was the addition of a
"pause" key. I had deliberately not included one ("There
ain't no pause in a real airplane"). Then I got a phone
call one day while on a tight approach....
One other reach at realism worked out better. I didn't
like having an "end flight" key that worked in the air, because,
again, you just can't quit flying when you want to. But
then I decided to make it work in the air as well...but when you
hit the "e" key in flight, the words EJECT would flash on the
screen....and the instrument panel would shoot out the bottom of
the display accompanied by a loud WHOOOOSH!
Flyability Problems
But while I was adding all the heading and position calculations
and the tests to determine when to enter the special
subroutines, bad things were happening to the flyability of the
aircraft. It was taking over a second to cycle through all
the calculations...which meant that the joystick postion was
only being read once a second, and thus the aircraft attitude
would only be updated at the same rate. This gave an incredibly
ponderous control feel..and it tooks something like ten second
to roll 45 degrees.
The solution was simple: I just called the stick-reading and
attitude-display subroutine *four* times instead of once during
the full cycle of the calculations and subroutines. While
it didn't affect the flight calculations, this quadrupled the
apparent control rate. The instruments updated once a second as
before, but at least the airplane seemed a lot more nimble.
On the Market?
I eventually had the program working pretty well. I'd
developed the Saturday habit of stopping by the store where I'd
bought the VIC, and I'd enjoyed chatting with David, who'd sold
me my computer. One Saturday I brought by a tape with the
working version of IFR. We loaded up the program, and I
let him fly around for a while.
"Y'know," said David. "You could probably sell this."
I was a bit stunned. I wasn't that familiar with the games
on the market for the VIC; I had enjoyed just writing my own.
But it sure sounded good. While we were better-off than
many newlyweds, we certainly didn't feel that comfortable,
financially. My wife was going to school full-time, with
only a part-time job on Saturdays. "It'd be nice to make
enough money back to pay for the computer," she said. "And
a new convertible top for the VW," I dreamed.
So, what the heck. I wasn't sure how, exactly, to keep
myself from getting ripped off. I called around and got
the forms to apply for a copyright. Scanning through the
ads in the computer magazines yielded the names of about six
companies whose product ads also invited submissions of new
programs. I filed the copyright report, and sent a query
letter off to the companies.. "I have written a program
for the VIC-20 in which you might be interested. IFR is a
realistic simulation of instrument flight...." To show I
was at least SOMEWHAT cagy, I included a comment as to how I'd
already filed for a copyright.
Most of companies responded favorably, willing to examine the
program. A couple of them made me a bit skittish. The one
from Academy Software impressed me the most: It was
professional, it mentioned that I didn't have to wait to get the
copyright verification back before I was protected (very true),
and included a signed non-disclosure agreement.
I sent the program in to them, and they loved
it. They called, offering me a 15% royalty on sales.
At the time, I'd had absolutely no experience in any sort of
royalty sales. I went to take to David at the computer
store. He allowed it sounded fairly good, except for the
lack of an advance on royalties. But we knew software sales were
iffy at best, so that was no big drawback.
This being the usual Saturday mill-around at the computer store,
there were a number of other fellow computer geeks around.
"Man, why give THEM all the gravy," said one. "Publish it
yourself!"
I didn't really consider that option. There were a number
of self-published programs at the store...tapes in plastic bags,
with mimeographed instructions and cheesy-looking art. I
felt that a publisher that could afford to advertise in COMPUTE!
probably had pretty good marketing and distribution.
Besides, I just didn't want the hassle of doing it all myself.
So I signed, in March 1983. They came back with a set of
desired changes, most of which I felt were pretty reasonable.
One, though, rather threw me. I'd written the program on
my VIC, which, with the 16K memory expansion added to the 3.5K
internal, had a total memory of 19.5K. I knew most folks
wouldn't have that pricy expansion, so I'd written it to run
within the 11.5K that an 8K RAM cartridge would give.
Academy wanted to shorten it further...so that it'd fit on an 8K
ROM chip. "If we limit it to folks who have memory
cartridges, we'll cut down on sales," said Academy's Bob
Weidner. "We'd have to bring it out on both tape and disk,
too."
In any case, the thought that IFR would come out as a cartridge
really pumped me up. I quickly cut the required 4K out of
the program, mostly by eliminating the detailed crash modes and
the ejection seat. But as I kept looking at the program, I found
unneeded and duplicated code. I quickly trimmed enough
that I was able to replace the deleted features.
All I had for a storage device was the cassette drive, and
Academy quickly got tired of having to load in tapes. They
sprung me a $200 advance so that I could buy a disk drive for my
VIC. The reality of having a big 180k storage device was a
minor consideration, next to NOT having to take five minutes to
read the program from a cassette tape.
We needed an instruction manual,
too. I didn't have a printer for my VIC (or for that
matter, any sort of word processor) so I went to my friends Judy
and Bo Stringer's place and used their IBM. I learned
Wordstar as I went, ending up with about twenty pages. I
drew the maps by hand, which Academy redrew in decent format.
Versions went back and forth as bugs were
eliminated. Finally, in July, I received the first FEDEX
package of my life: An IFR cartridge, and a sample of the cover
art to go with the instructions. I opened the package and
just started laughing: The cover art was PERFECT! A
head-on, wide-angle view of a Cessna landing in the rain, with a
narrow mountain pass in the background and the inset of a sweaty
hand on a joystick in front of the IFR panel.
A real joy it was, too, when I plugged the cartridge into my
VIC. Power switch on, and there it was... "IFR (FLIGHT
SIMULATOR) By Ron Wanttaja." No loading, no waiting.
Just like an Atari game.
Showtime
Right about the same time, an advertisement in the Seattle Times
newspaper caught my eye. Compufair, the first-ever
citywide computer fair aimed at general users, was being held in
the Seattle Center Exhibition Hall (a leftover from the 1962
World's Fair) in September 1983. As part of the program,
they were having a contest... for "Individual innovators or
anyone else with a bright new idea in computing." Seven
finalists would be picked for the "Cloud Nine Idea" contest, and
all would receive free display booths at Compufair. The
winner would receive $1000!
I put in an entry, and on August 30th, received notice that I
was a finalist. I would get a free booth, a table, and a
couple of chairs...everything else was up to me. I had two
weeks to put it all together.
Academy was thrilled...except the production plans for the IFR
cartridge would make it JUST miss the show date. Instead,
they printed up advertising sheets with coupons for $10 off the
mail-order price of $40. Plus a nice blow-up of the cover
of the program box.
Now, how can I spiff up the booth? Judy Stringer
volunteered to sew up fluffy clouds for the backdrop. I
had a 727 pilot seat I'd bought from Boeing Surplus and a B-50
autopilot joystick that I'd bolted to it (I'd built an A-D
converter to allow it to work with the VIC). I bought some
particle board and cut out a 1/4 scale Cessna rudder, covered it
in white contact paper, then put "IFR" slanting down the tail
just like Boeing put the model numbers on its new jetliners.
Somehow we were ready by the weekend of the show. Bo and
Judy hauled our TV, the pilot chair, and the rest of the gear
down to the Center on Thursday. Friday morning the show
started.
I damn near talked myself hoarse. I usually had a pretty
good crowd. A lot of pilots came by, and several of them managed
to take off, fly to the other airport, and fly a successful
instrument approach. Many wanted to buy the program, and
were a bit disappointed when all I had were order sheets.
I still remember one older man. His arms were loaded with
purchases, and he was being followed by his wife, who had a
suffering expression. He saw my booth, and his eyes
positively lit up. He almost ran over to try his luck
flying the program. Turns out he was an airline pilot.
The local CBS affiliate even did a live report from the fair for
their noon news show...with me sitting in the pilot chair,
flying IFR, while the reporter interviewed me on the air.
Sunday noon came the announcement of the winner. It wasn't
me...but the winner had a cool teaching program that he needed
money to bring market, so it was a good choice. I'd given
away all my discount certificates, and turned down about a
half-dozen offers to buy the 727 seat....
So there was my moment in the limelight...fun while it
lasted. I took Bo and Judy and David out for dinner that
Sunday night, after we took down the display.
It Gets Surreal...but in a GOOD Way
Back at my engineering job on Monday, it was like Cinderella
back scrubbing the hearth. The ball was over...or so I
thought.
I got a call from Bob at Academy in the middle of the
week. "We just got a massive order from Toys-R-Us.
Your royalty on that sale comes to eighteen thousand dollars."
I was absolutely, totally stunned. That was about 75% of
my annual salary at that time. All in one sale.
I couldn't stay at work. I went home, and called my wife's
school. I'm sure she (and everyone else) thought there was some
sort of dire emergency. Everyone else probably STILL
thought so when I told her the news...she screamed, long and
loud.
We went out to eat that night, too.
Commodore 64 Version
As the VIC version of IFR wrapped up a couple of
months earlier, Academy asked me to do a Commodore 64
conversion, and I was right in the middle of THAT project.
The Toy-R-Us order included orders for the C-64 version, so we
had to get it competed and published in time to get it in the
stores before the Christmas rush.
The C-64 version was about the same as the VIC.... except now I
went with gauges for the airspeed and altitude, instead of the
text readout in the Vic version. Rick had been right, but
I still preferred the look of gauges. I added a digital
readout of the last two digits of the altitude.
The Attitude Indicator was now in color, twin fuel tanks and a
DME (Distance Measuring Equipment) were added. Everything
else worked the same. The 6502 machine code worked the
same on the 6510, with some minor changes necessary.
We made it, with a month to spare. I had
been haunting the local Toy-R-Us, and it was another big thrill
to see the red (VIC version) and black (C-64 version) boxes on
the shelves, proclaiming "IFR FLIGHT SIMULATOR by Ron
Wanttaja." The chain started advertising for
Christmas..and there was IFR, in the ads. Academy printed
up posters, which Toys-R-Us displayed in their computer
area. Academy added IFR to their full-page ads in
the computer magazines.
One hell of a feeling.
The Reviews are Out!
The reviews started coming out. They all seemed to take
the "There I was" approach... "Ceiling is 200 feet in light
rain...." The reviews extolled the play and interface of
the game, with the only negatives referring to the rather crude
depiction of the panel. A fair hit.
Academy passed on a few fan letters, too. One was written
on stationery from the Hotel Lexington in New York, from a 747
pilot who just loved the program. I got letters from happy
mothers, telling me how their kids had developed an interesting
in aviation science from playing with my program. Once
letter was from the "Institute of Social Sciences" in The Hague,
with some small suggestions but a closing comment calling it the
"Best simulation I have yet seen." Some letters expressed
admiration at how well the airplane model worked, others asked
about how some of the little tricks were done.
Not every one was positive, of course. One writer stated
his opinion clearly and distinctly: "It stinks!" He didn't
like the lack of an outside view...again, a fair hit.
First Year's Results
All this trickled in during 1984, the first full year of
release. Personally, I was waiting for my first royalty
check. The contract specified the delay between sales and
royalties, so I knew the first one of my quarterly payments
would come out about mid-August.
Good timing, really. I was turning 30 that month, with the
visions of over-the-hilldom dancing through my head. I was
looking for a nice check to make it seem like I'd accomplished
something with my life.
It did. It was a tad over $25,000....more than my yearly
salary. I had driven home from work to open the envelope
when my wife said it had arrived. I drove back to work
laughing maniacally all the way. I deposited the check,
keeping out $500, which I gave to my wife for a shopping spree.
The next quarterly payment came in mid-November. It, too
was over $25,000.
We opened up an interest-bearing checking account to deposit
this windfall. We nicknamed the checkbook, "Bottomless."
Our friends Bo and Judy took a trip, and I picked them up at the
airport. On the way home, I said, "Hey, there's an
interesting airplane at that little airstrip near your
place. Let me show you."
We drove onto the ramp and stopped in front of a Cessna
150. "What do you think?"
They looked on silently for a moment. "What's so
interesting about it?"
"I bought it, yesterday." After thirty years of dreaming,
I finally owned my own airplane.
Fortunately, my wife and I have simple tastes. We didn't
go crazy buying sports cars, stereos, or trips to Europe on the
Concorde. Other than the airplane, there was only one major
expense: We finally had the down payment to buy our own home.
Oddly enough, though, the VW never *did* get a new top.
We had some taxes to worry about, though. One of the
secretaries at work had a daughter who'd just started a tax
company, so we worked with her. Income Averaging was still
allowed, so the big windfall of that year was softened by my
lower salaries in years past (including the last year or two I
was in the Air Force). Still, my engineering salary that
year all went to pay the tax bill.
Fall-Off
That second $25,000 royalty was the peak, though.
Royalties for the second year were about a third of the first
year, and subsequent years showed similar drops. Commodore
came out with a new set of computers, the Commodore 16 and
PLUS/4, and, per Academy's request, I ported IFR to those
platforms. Due to the rarity of joysticks for these
computers, I had to break down an allow optional keyboard
control. It was mostly for naught, though, as the
computers flopped in the US, Pretty soon my annual royalties
dropped to below $1,000.
Other things were happening in my life, though. In 1985,
my airplane suffered an engine failure due to bad
gasoline. I managed to nurse the glide to a safe landing
at my home field, then wrote up a report of the incident for the
Usenet newsgroup net.aviation. Response was positive, and
I decided to work on the tale a bit and submit it to FLYING
magazine. They bought it, my first sale as a freelance
writer.
I eventually sold the Cessna and joined a local Flying Club
flying a small homebuilt open-cockit airplane called a "Fly
Baby." I submitted an article to PRIVATE PILOT magazine
about the airplane...but the editor of a sister magazine
intercepted the article, and felt it worked far better in HIS
magazine: KITPLANES. He called me and invited me to send
him lots more articles...just the thing a freelancer dreams of.
His name was familiar, though. Eventually, I looked in my
scrapbook. He had written a report on flight simulators for an
aviation magazine back in 1986. He had panned IFR.
I kidded him about it, but he kept buying my articles.
Within a year, a book publisher had talked to him about writing
a book on building homebuilt airplanes. He didn't have the time
to do it...but told them to contact me. TAB Books sent me
a letter inviting me to write a such book for them. The
book turned out to be 100,000 words long, and was written on the
Commodore 128 left over from my IFR days.
KITPLANE CONSTRUCTION was published in 1991. The first
edition came out in five printings, with the second edition
published in 1996, and a third edition ten years later.
The book even won a journalism award.
Back in 1986, I started working on a novel about a young boy in
the US Navy during the War of 1812. Working title for the
book: ON THE UPROLL, the same name I'd used for that
cannon-firing game I'd originally written for the VIC. Not
quite as much success on that; I sent it to publisher after
publisher. The name eventually morphed to THE KEY TO HONOR.
Fast-forward back to 1994. I was facing the big 4-0.
Like my 30th birthday, I needed a bit of perking up. It
came late, but it came: Two months after my birthday, a
publisher enthusiastically bought THE KEY TO HONOR and asked if
I could make a series of it. I also wrote a sequel, THE
PRICE OF COMMAND, published a few years later. Eventually
will write some more, once I had time.
The Work Impact
All through this, I kept working at my aerospace job. A
bit after IFR had come out, me and a co-worker were trying to
figure out how much of the ground a satellite could see from a
certain altitude and position. We were squatting down with
a globe and a ruler, squinting at this faux Earth and trying to
sketch the visibility contour on a hard-copy map.
"Damn," I said. "There's got to be a way to do this on a
PC."
So...I started writing a program. Didn't
know squat about orbit mechanics, so I grabbed a basic
textbook ("The Fundamentals of Astrodynamics") and started
to see what it took. I learned how to compute the ground
track of a satellite, worked out how to draw a Mercator map on
the computer screen, then figured out how to combine them.
I had used an orbit-analysis program on a big computer earlier,
and stole its name: "Interactive Globe and Orbit Mapping
and Display" (IGOMAD).
With the basic capability, it was that hard to figure out how to
compute visibility contours, beam footprints, and most of the
other features the big guys would be doing ten years
later. It was an easy modification to kick out files that
gave the geometry (azimuth, elevation, and range) whenever a
satellite went over a given ground target, or just a set of
rise-set times. These were all time-consuming computations, but
I used the speed-up tricks I'd learned on IFR to make the run
times acceptable. I could use the data to perform trade
studies and pick the right combinations of satellites and
orbits.
There were other bits of IFR's DNA in IGOMAD. Remember the
story about the plane "falling" when the program first started
because the program didn't know about "ground"? That an
other experiences had made me VERY careful about not assuming
that there weren't any "gotchas." I did a lot of
cross-checking out output, to ensure what was being computed was
what I assumed was being computed.
In addition, I'd learned how to program sequentially without
having to plan everything in advance. In IFR, I'd program
in a basic feature (such as computing whether a plane is rising
or falling) and add code to it to perform more and more detailed
function. I learned how to track the capabilities in my
head and understand where things were going.
IGOMAD itself wasn't the end. I'd be assigned to another
program, and the need would be slightly different. So I
added a feature to the main program, or did a custom
version. IGOAPE, IGOPOP, IGOBATS, IGOPISS (don't ask),
even IGOMARS (IGOMAD plotted against Mars instead of the
Earth). At one point, I was assigned to an early UAV
program, and developed IGOFLY...a simplified mission-planning
tool that included computing when the UAV would be able to talk
to a relay satellite.
Keep in mind that I'm not officially a
programmer. I was never brought on to a program to "write
code", I was sent there to answer questions, usually about
mission performance and the ideal orbital population. How
often does a satellite view a given ground target? How
does it improve with a different inclination or orbit
altitude? My job was to answer questions like these, and
the best way to do it usually turned out to be some sort of
simulation. Even when commercial orbit-analysis tools
became available, IGOMAD still filled a niche because I was able
to incorporate unusual features or limitations of the space
systems we were examining.
Not that long ago, I developed a version that completely
simulated a proposed space system, right down to how the ground
communications antennas and ground command software
worked. It used IGOMAD orbit files as inputs, and let one
vary particular settings (such the number of satellites and
their orbits, the number and locations of the ground antennas,
the magnitudes of system constraints, and the amount of ground
processing time) to support trades to figure out the best
settings. This program had the highly prosaic title of
"Mission Model."
The Government decided to bring in consultants to, basically,
duplicate my work and provide confirmation. I spent a
couple hours explaining what Mission Model did, and how it
implemented some really strange limitations our system
had. Then the consultants declined the job. They
were using, basically, commercial packages that couldn't factor
in the realities of our system. They couldn't modify their
tools, like I could. Learning programming flexibility with
IFR paid off again.
There was only one time my IFR work directly crossed my
professional sphere. I was tasked to lead a team to
develop a Space Station assembly simulator, using a 737 flight
simulation cab. At the time, one project I was working on
was a Shuttle Flight Simulator, and I got concerned about a
potential conflict of interest. So I contacted my work
legal department to get a reading.
I gave them the background, and they were curious about
IFR. One of the lawyers said to me. "Our company
develops flight simulators, as well. We think we might own
the rights to your flight simulator."
Did what was probably the best thing I could have done: I
laughed in his face. "Does this massive, international
aerospace company want to claim ownership of a video
game?" Pushing back was all it took. They cleared me
to continue with my separate, private, Space Shuttle simulation
as well.
But No IFR II
But...nothing came of it. The computer gaming industry was
not longer the province of individual hackers like myself.
Games were built by teams now; able to merge multiple talents
together and crank out high-quality products a lot quicker.
Immediately after IFR for the Commodore 64 came out, I started
working on an improved version. I made the graphics looked
better, I enlarged the attitude indicator, and made it so it
could load several maps it. It was designated "IFR
II".
I stopped by Toys-R-Us once to check that they still had the big
"IFR" poster in their software area. I heard a guy ask the
clerk if they had "Flight Simulator 2" yet.
I felt pretty darned good...until I realized he was NOT
referring to IFR II. A company called "Sublogic" had
developed a flight simulator with an outside display for the IBM
PC, and they were apparently getting ready to produce a version
for the C-64 and the Apple II. "Sublogic Flight Simulator
2" came out about a year after IFR, and, of course, blew IFR
sales away. Never mind that it was slow and clunky, people
wanted that outside view.
Haven't heard of "Sublogic Flight Simulator", you say? It
had been previously licensed for use on the IBM PC and renamed,
"Microsoft Flight Simulator." Sublogic was coming out with
a Commodore 64 version, and that's what folks were waiting for.
I was lucky IFR had come out when it did.
Luck
"Lucky," of course, sums things up pretty well. I was
never so much a good programmer as a lucky one...I hit the
market with the right product at the right time. I'm lucky
at the variety of decisions resulted in just the right
combination of accuracy and playability. I'm lucky in my wife,
who tolerated the distraction and lack of attention that
development of the program engendered (and who proudly wore the
"Computer Widow" T-Shirt I bought her). I'm lucky in my
choice of Academy, with them turning out to be 100% honest and
upfront. I'm especially lucky in my friends, from Rick
Reierson to David Paulsen to Bo and Judy Stringer and a host of
others who helped.
Thanks, guys. It was a heck of a ride while it lasted....
The VIC had a full-size keyboard, a definite
plus. In fact, the whole computer was built into the
keyboard.
Something I didn't mention earlier is that I had
some prior flight simulator experience, in that I helped restore
a WWII model Link Trainer a few years' prior to IFR. The
Link is an analog computer in vacuum (uses a vacuum system to
"store" altitude, has an vacuum manifold for the airspeed value,
etc. I ended up using the Link Trainer systems as direct
inspirations for IFR.
Once the flight model and the instruments were
working, it was time to actually fly the plane SOMEWHERE.
I drew up a map, including four airports and a mountain
range. There ws a high straight pass on one leg of the
L-shaped range, and a lower Z-shaped pass on the other
leg. I used an ordinary Sine/Cosine calculation with the
speed to determine the movement over the map, and a simple
machine language routine to determine the height of the ground
at any particular location. Postion was given to the pilot by a
digital display of Latitude and Longitude at the bottom of the
screen.
I sent the program in to them, and they loved
it. They called, offering me a 15% royalty on sales.
Versions went back and forth as bugs were
eliminated. Finally, in July, I received the first FEDEX
package of my life: An IFR cartridge, and a sample of the cover
art to go with the instructions. I opened the package and
just started laughing: The cover art was PERFECT! A
head-on, wide-angle view of a Cessna landing in the rain, with a
narrow mountain pass in the background and the inset of a sweaty
hand on a joystick in front of the IFR panel.
As the VIC version of IFR wrapped up a couple of
months earlier, Academy asked me to do a Commodore 64
conversion, and I was right in the middle of THAT project.
The Toy-R-Us order included orders for the C-64 version, so we
had to get it competed and published in time to get it in the
stores before the Christmas rush.
We made it, with a month to spare. I had
been haunting the local Toy-R-Us, and it was another big thrill
to see the red (VIC version) and black (C-64 version) boxes on
the shelves, proclaiming "IFR FLIGHT SIMULATOR by Ron
Wanttaja." The chain started advertising for
Christmas..and there was IFR, in the ads. Academy printed
up posters, which Toys-R-Us displayed in their computer
area. Academy added IFR to their full-page ads in
the computer magazines.
So...I started writing a program. Didn't
know squat about orbit mechanics, so I grabbed a basic
textbook ("The Fundamentals of Astrodynamics") and started
to see what it took. I learned how to compute the ground
track of a satellite, worked out how to draw a Mercator map on
the computer screen, then figured out how to combine them.
I had used an orbit-analysis program on a big computer earlier,
and stole its name: "Interactive Globe and Orbit Mapping
and Display" (IGOMAD). 
Keep in mind that I'm not officially a
programmer. I was never brought on to a program to "write
code", I was sent there to answer questions, usually about
mission performance and the ideal orbital population. How
often does a satellite view a given ground target? How
does it improve with a different inclination or orbit
altitude? My job was to answer questions like these, and
the best way to do it usually turned out to be some sort of
simulation. Even when commercial orbit-analysis tools
became available, IGOMAD still filled a niche because I was able
to incorporate unusual features or limitations of the space
systems we were examining.