Date: Sat, 6 Apr 1996 18:50:59 -0800 (PST)
From: Ken Jordan
Subject: Ken Jordan's AR perspective (very long, about 20K!)

Hello,

I just got back from the 10'th annual Computer Games Developers
Conference in San Jose where I ran into Philip Price (who has
recently re-entered the game business). We talked a bit about the old
days and Alternate Reality and I was inspired to write this long
winded message. Since this mailing list is just starting up I thought
some of you might find this interesting and at least it would be a
good way to introduce myself and start some discussion.

***** Ken Jordan's perspective on Alternate Reality *****

[ A.K.A. The AR:The Dungeon IAQ (Infrequently Asked Questions) :-) ]

v1.0 04/06/06

[ NOTE: This is about events that occured close to ten years ago, so
if you think I'm remembering any of this wrong please feel free to
refresh my memory. ]

I first encountered Alternate Reality when my friend Jim Ratcliff
(who was a programmer working at DataSoft) showed me a video tape
demo of this new Atari game in development which was written by some
guys in Hawaii at a company called Paradise Programming. It was
visually stunning and had a texture mapped scrolling 3-D look that
was amazing and quite a bit cooler than other popular FRP games of
the time (e.g., Wizardry with B&W line drawings or tile mapped 2-D
Ultima). The design of the game (as described to me by Jim) also
sounded quite unique with an alter-ego flavor that remembers many
stats about the player. Your aren't just eight bytes and an
inventory, you have a past and your actions may have future
consequences. I think this was sometime in late 1983 or possibly 1984.

At the time I was a programmer working full time converting Sega
coin-op arcade games to home computers and consoles working for a
company called MCT that also made an Apple ][ speedup card called
"SpeeDemon". Then in 1985 after Sega pulled the plug on its home
computer software division and the launch of the Amiga was delayed
(again, but at least I got to play with Amiga prototype #8) MCT
decided to lay me off and focus on the hardware market. I was forced
to get another job and went to DataSoft and got a contract to program
home productivity software for the Tandy Color Computer (with another
guy, David Joiner [who wrote Faery Tale and was one of the founders
of the Dreamers Guild] who had also just been hired, but thats
another story...). Luckily for me, after working on the CoCo database
for a couple of months Ron Fortier [now at Epyx I think] who was
working on the C-64 version of Alternate Reality:The City, decided
(wisely) to leave DataSoft. I was hired full time to help work on
finishing AR and complete the C-64 version. By this time I believe
that DataSoft had somehow convinced Philip Price to leave Hawaii and
he was living in a rented room in Jim Ratcliff's house where I was
also renting a room. [ WARNING: Don't try this at home kids! When you
have have three computer programmers working long hours to complete a
project together all day, you should probably not also live together
in the same house at night. :-) ]

Somewhere during this time DataSoft's founder (Pat Ketchum (sp?))
decided to pull out and folded the company. However, Ted Hoffman [now
at MindScape] and Sam Poole [now President of Maxis] who were working
in the business side of DataSoft got together and worked out a deal
to buy DataSofts remaining assets and use the DataSoft name as a
trademark for a new company called "IntelliCreations" (actually, it
was called "H+P software", but very rapidly after startup they
received a call from lawyers at HP who were not amused :-). They did
this largely because they felt that the Alternate Reality series was
a valuable asset (I think the City had _just_ been released for the
Atari when DataSoft folded.) Its interesting that before Sam and Ted
actually got the new company started the Gillette razor company (who
was a major investor in DataSoft) actually paid Jim Ratcliff and
myself directly for a few months to keep work on the AR City Apple ][
and C-64 ports progressing (the checks we were paid with actually
came from the Jafra cosmetics company - kind of strange we thought).

Sometime in all this (I am not positive of the exact sequence of
events), Philip Price decided that he needed to actually get paid for
his work (since he wasn't getting a salary from DataSoft and was just
given enough cash to barely eat and make rent as advances) he went
and got a "real job" working on military computer stuff [like stealth
bomber radar, I believe].

Jim Ratcliff and I finished up the Apple ][ and C-64 ports and
IntelliCreations starting shipping AR:The City in decent quantities
for 8-bit systems (Atari 8-bit, C-64 and Apple ][.) [ Later,
IntelliCreations would get James Garon to write _two_ Tandy Color
Computer versions one for regular CoCos _and_ one for OS-9 CoCos. ]

Now, Philip had designed the City and the Dungeon as one game and
they were only split up in an effort to get something to market more
quickly (by Marsten, even before DataSoft entered the picture). We
knew that we needed to get the Dungeon out so the City players would
have some quests to undertake with characters they had built up in
the City. There was our problem. Philip was already working for
another company so we would have to make the Dungeon with only some
part time consulting and guidance from Philip and Gary Gilbertson.

Phil had intended that the Dungeon would use mostly the same engine
as the City with some new modules and code to "patch" the City and
complete the "mesh" of the two games (and in fact he did have a
prototype running). With Phil gone, and the original code ported to
several platforms (using incompatible assemblers) we had a big
development problem on our hands. Complicating this was the fact that
the City code was a bit of a mess at this point as last minute fixes
were added at a rapid rate on top of code that had evolved over a
long period of time and been ported to machines that are very
different from the original Atari. Phil had most of the program
structure in his head but at IntelliCreations we were leery of trying
to modify the City to make the Dungeon without him. A decision was
made to make a new portable engine that would run on all three 8-bit
machines and have clear modularity to make future scenarios easier
and faster to create. We also planned to enhance some of the features
of the City engine and add some feature that had been left out and
add some of our own new ideas.

At this point Jim Ratcliff [now at NovaLogic], John Butrovich [now
also at NovaLogic] and Richard Mirsky [I've lost touch with Rick]
started work on the City by making a portable engine for the 16-bit
Atari ST, Macintosh and Amiga machines (which we expected to take
over in the next few years). This new engine had many new features
some of which we wanted in the 8-bit Dungeon.

Dan Pinal [now at Mass Media, where I still work with him] and myself
were left with the task of designing and developing the new 8-bit
portable engine which would be used on the Dungeon and future
scenarios. We started with some notes and story line from Phil and
Gary Gilbertson as well as some ideas from a story consultant hired
by IntelliCreations (he submitted an entire design, but we ended up
not using most of it).

This was, as you might imagine, quite a difficult job given the size
of the game and the state of development tools of the time (i.e.,
Apple ][s, 140k 5 1/4 floppy disks and no usable debuggers). Phil had
taken quite a while to get the City developed and we were adding even
more technical wrinkles with future expandability and portability.

Working with Dan and the other people at IntelliCreations was a
pretty good time in my life (I was about 22 at the time) even though
it took 18 months from start to ship, with many long days and late
night pizzas. Needless to say, we were way behind schedule (which is
unheard of in this business ;-). The Dungeon was actually released in
November 1987 for Atari and C-64 (however, the first shipment had
some bad bugs that were fixed in the 1.1 release).

Dan and myself were charged with designing and developing the game
with me being in charge of the C-64 port and Dan in charge of the
Atari port. Another fellow who joined us later, Robin Huff [current
whereabouts unknown] did the Apple port. However, the Dungeon was
very much a joint effort (we would often just ask questions and reach
consensus talking over the cubicle walls that separated us).

However, when we were done, we did accomplish most of our goals
(except the deadlines...). The Dungeon used a basic kernel "operating
system" that was different on the Apple, Atari and C-64 and handled
low-level disk, keyboard, sound and some graphics with the majority
of the game code completely shared between platforms. The game was
written in 100% assembly language (as all good games of the time
were) using the Merlin assembler on the Apple ][ and downloaded to
the target platforms using a parallel cable and custom software
(except for the Apple where you would just place the floppies in
another machine).

The main thing we had to sacrifice was going back to the City. We
toyed with ideas where we would "translate" the players character
back to City format and try to keep the Dungeon data until the
character returned or even re-make the City using the new Dungeon
engine but in the end for a variety of reasons we had to preclude
going back to the original City and wrote "customs" to translate the
City characters stats to better match reality in the Dungeon (where
for instance you can't carry a zillion items because they have
weight). I know that this was a sore point for many City fans (who
had seemingly wandered around during the whole 18 months while we
were writing the Dungeon amassing incredible fortunes and stats) but
at least you might better understand why we did this. [At that time
we still had hopes that we could "whip up" a City using the new
engine but we thought "lets wait until we finish the other *5*
scenarios Phil envisioned first!" :-) ]

-*- Here are some random notes on the 8-bit Dungeon development: -*-

I created the map editor (which ran on a C-64) and designed the map
layout with the first level based on the City map layout and with the
successive levels decreasing in size in an attempt to simulate the
geometry of a spaceship and reduce the game size (which we would have
to populate). You may have noticed my initials "KJ" and Dan's
initials "DP" in the map (carrying on the tradition started by Phil
in the City). Like the City the Dungeon maze was convoluted and had
lots of secret passages. Also, there is a Blue Oyster Cult symbol and
several other strange patterns here and there. The map data used four
bytes per map cell instead of the City's two bytes (as I recall).
This allowed us to encode more information about different types of
walls, doors and arches and location specific information (i.e.,
fixed monsters, fixed treasures and teleporters). It also made the
Dungeon's 64x64 first level consume way too much memory (16K, or one
third of our total memory). This is why we divided the levels into
32x32 pieces (or smaller) to fit in a 4K map buffer.

Dan created the combat system taking a cue from the City and adding
elements he liked from his experience playing D&D, Rune Quest and
other traditional RPGs. He added several different outcomes and
presented the combat results in a (somewhat) English fashion (we were
one of the first games to get that plural thing right also - not "you
have encountered 1 skeleton(s)").

We both collaborated (along with Jim Ratcliff and John Butrovich) on
the object system which was powerful enough to describe many unusual
objects and object behavior. The items in AR the Dungeon (other than
generic coins and stuff) can actually have "properties" attached to
them which are actually programmed instructions interpreted by the
engine. These instructions can act based on time, stat values or
other objects and modify stat values and other objects. This allows
objects to have a large range of special behavior which would enrich
the game and give items a unique feel we missed in other games where
all the items seemed so generic. Objects would be somewhat randomized
when they were created (i.e., added into the active queue by the
"treasure" module) so that two items which seem the same probably
will have slightly different properties (and a history - swords
break, spells expire and magic items fail). An examples of a complex
object would be the sword which decides it doesn't like your attitude
and starts yelling and doing bad things. Other things such as
diseases, curses and spells are actually objects with properties in
the Dungeon. Dan and I also tried to create more types of objects
than any other computer RPG we had played at that point since we felt
that it was getting new stuff and new capabilities was one of the
main things that would help keep the game interesting.

One of our other pet peeves with computer RPGs was the "eight slot"
item limits that many games had. Where you could carry only (for
instance) eight items at a time no matter what the size or weight
(e.g., eight feathers and you would be unable to pick up a BB). We
therefore decided to limit a players inventory using the players
stats and taking into consideration the weight and bulk of the items
(i.e., if you are stronger you can carry more). This did pose a
dilemma in that on 48k (or even 64k) computer the object queue could
only be of limited size (8K as I recall, with objects ranging from 16
bytes to about 64 bytes). Since bad things would happen if this queue
filled up (like objects losing properties or crashing the game) we
had to limit the number of active objects in the game universe at any
one time. Since we disliked totally artificial limits we decided to
write our "garbage collection" routine into the story line as the
Devourer (and had Gary write him into some of the songs). As the
amount of free memory in the object queue gets smaller the percentage
chance of encountering a devourer would increase (with the
probability getting near 100% when memory was critically low). Many
players thought this was a cruel joke to keep them from keeping neat
items they found and we received many complaints about our necessary
friend. Some adventurers, knowing that a Devourer might be lurking
around the next corner, thought that it would be a good idea to carry
extra items just in case he showed up (thereby, assuring he would
show up). The Devourer would always show a preference for heavier
items (like armor and weapons) and would stay away from one-of-a-kind
items. We probably should have explained the behavior of the Devourer
in the documentation but we thought that players would figure it our
themselves. We still felt it was better than a hard limit on
inventories but in a way, we made it hard on ourselves by having so
many unique and useful items in the Dungeon that players wanted to
keep them _all_.

I re-wrote the 3D graphics code with help from Jim Ratcliff (and
after studying Phil's original City code). The Dungeons texture
mapping routine was optimized enough to draw the Dungeon walls about
as fast as the original City code even though the Dungeon included
transparency (windows and arches) and rendered the full walls (the
City rendered only the top half and vertically mirrored the bottom
half (using graphics hardware for instance on the Atari)). As far as
I know Philip Price with the City was the first person to use texture
mapped 3D walls in a computer game (now a staple in modern games like
Castle Wolfenstien 3-D and Doom). When developing the Dungeon we even
played with the idea of allowing 360 degree rotation (ala Wolfenstien
3-D) instead of 90 degree angles only (since our rendering code had
no real problem doing this) but ruled it out as too radical a change
from the City (if only we had known...). In the Dungeon I also used a
technique to minimize the aliasing of wall textures in the distance
by using several wall textures sizes each 1/2 the size of the
previous texture (so a wall texture could have more detail close up
but as it got farther away it would become mostly a solid color and
have less detail). At the recent CGDC I attended, I heard a talk by
Michael Abrash [who is working at id software on Quake the sequel to
Doom] who described using this technique in Quake and hearing that it
is officially called "mip mapping" (for midpoint mapping). Kind of
cool that we did this ten years ago (though we didn't have a cool
jargon name for it :-).

The music for the Dungeon was all still done by Gary Gilbertson.
After sending Gary Gilbertson information about our Dungeon design
and talking over the phone he wrote the music for the Dungeon while
living in Hawaii. He using a more portable music notation system than
was used on the City (it still was based on assembler macros, and was
not too easy to use). We had a difficult time translating the music
and instruments exactly as he wanted on all the systems but his
talent was still evident (IMHO).

When the Dungeon was done the source code, artwork and numerous
support utilities for it fit on 40 Apple ][ disks and took several
days to do a completely re-build (with lots of floppy disk swapping).
[ I still have a copy of the disks in my garage but I have no easy
way to transfer them from the Apple to a PC. Besides, I don't think I
personally have any rights to release anything. ]

The "Damion and Pythias shoppe" was inspired by a comic strip "Life
in Hell" featuring "Akbar and Jeff" by Matt Groening [of Simpsons
fame now] which was in the L.A. Weekly free newspaper. Thats why they
do math wrong and are generally sleazy (we figured "heck, what other
type of people would be doing business in a dungeon anyways?").

The Enchantress was modeled after one of our game artists Bonnie Long
Hemsath [now at New World Computing] who is a bit of a crystal
enchantress herself.

There was a small hexadecimal debugger built into the Dungeon (if the
game has crashed on you, you may have seen it). We used it to debug
the game and as a universal "cheat code" to allow us to modify game
variables and stats during development and testing. I can't remember
exactly how to enable it, but as I recall you had to name your
character a special name ("Adept" or something) and hit a function
key (like option on the Atari or f4 on the C-64). Another debugging
aid could be enabled by typing DataSoft's phone number (as printed on
the box) while in the stairway module. This would give you a helpful
spell called "Tactical Nuke" :-).

The Dungeon used DataSoft's patented "weak bit" disk based copy
protection scheme (which almost all games had some form of at this
time). It worked by encoding invalid bit patterns in some disk
sectors then at run time the software would read those sectors
several times and make sure the bits were "flaky" (sometimes a 1
sometimes a 0). On the C-64 John Butrovich went one step farther by
writing a special fast-loader DOS that lived inside the disk drive
using overlays from track 0 within a giant sector that was physically
too big to be created on a Commodore 1542 type disk drive (so it
couldn't be duplicated on normal hardware). We didn't worry about
people copying the C-64 version much, but with the Atari (and I think
the Apple) we also added some subtle checks a various points during
the game which would eventually cause pirated copies (and early buggy
Atari 1.0 versions...Oops!) to force an encounter with FBI agents
(who would make short work of adventures attacking with weapons like
"the long arm of the law"). At this point I'm very glad to see
cracked versions of AR up on the net. I just wish the PC emulators
worked better (or at all) with them.

-*- end of random notes -*-

Unfortunately for us, as the Dungeon started shipping we saw the
8-bit market starting to wane and the 16-bit machines began to vie
for dominance. Dan and I started work on the 16-bit Dungeon engine
this time our target was The PC/AT with EGA and the Amiga (with
porting to the Atari ST in mind).

The 16-bit Dungeon had numerous improvements over the 8-bit version
but was to be basically the same game written in C now and with much
improved graphics and more of everything (since memory and disk
limits were much less restrictive). We worked on it for about 6 or 8
months when IntelliCreations was bought by Software Toolworks (mainly
to get our office building and warehouse it seemed). Software
Toolworks told Dan and I to take our development machines home and
finish up the 16-bit Dungeon there. After a few months with us trying
to carry on at home and with the Dungeon about 70-80% complete (all
artwork completed and most of the modules completed) Software
Toolworks decided to lay off Dan and myself because they didn't think
the RPG market was large enough to justify further investment and
effort by Software Toolworks.

The final AR tally (all the AR versions that were ever made):

Atari 8-bit City
 C-64 City port
 Apple ][ City port
  Tandy Color Computer City re-write
   Tandy Color Computer w/OS-9 City (may not have been released)

Atari 16-bit City
Macintosh 512K 16-bit City
 Amiga 16-bit City ported from ST
 PC/XT CGA 16-bit City ported from ST (done by a contractor)

Atari 8-bit Dungeon
C-64 8-bit Dungeon
 Apple ][ 8-bit Dungeon

IBM PC/AT EGA 16-bit Dungeon (never completed)
Amiga 512K 16-bit Dungeon (never completed)

Well, thats pretty much my AR story (and a large chunk of my life).
I'm amazed that your still reading this after all that :-). I moved
right on after this experience and am still working in the game
development industry (15+ years now) where I earn a nice living and
more importantly I really like my work (currently at Mass Media and
still working with Dan Pinal). Feel free to ask me any questions (or
better yet, post them to the AR list), but I'll tell you now, don't
ask me to "Work on AR in my spare time with a group of coders over
the Internet" :-). These days I have a wife ;-), and I already spend
far too much of my time typing with my carpel tunneled fingers while
basking under the glow of a CRT.

I am proud to have worked on Alternate Reality and looking back I
consider it to have been one of the high points of my career. Since
that time the game development industry has changed so much that now
I've had to focus mainly on the technical issues and leave the game
design (or lack thereof :-) to other people.

Thanks to all of you who have played AR and enjoyed it. I enjoyed my
part in helping to make Alternate Reality become an actual reality.

If anyone can continue the AR saga it will probably have to be Philip
Price himself (but I suspect he is interested in other game ideas
these days and may want to move forward...).


Take it easy,

Ken Jordan (aka "The Adept")
Software Tools Manager - Mass Media


Company Web Page: http://www.massmedia.com