8,732
edits
Changes
→Interview
==Interview==
The following is from an interview done by Gary M. Kaplan that appeared in the 19823 1982 Vol. 1, No. 5 issue of 99'er Magazine, pages 34-35, pages 47-48 and page 52:<ref>An Interview with John C. Plaster - Designer and Programmer of "Tombstone City:21st Century" - ''99'er Magazine: 1982 Vol. 1, No. 5, pgs. 34-35, 47-48 and 52''</ref>
[[image:Jim Dramis - Designer's Spotlight.jpg|400px|thumb|left|An Interview with John C. Plaster - Designer and Programmer of "Tombstone City:21st Century"]]
'''JCP:''' Actually not. I first started on 9900 coding about two weeks before I began the game, and that was because of another project-a numeric expression interpreter. Before that, I was involved in two major projects. The first was the ''Personal Real Estate'' done in GPL [Graphic Programming Language]; the second was also written in GPL, and that was the Milliken Math Series.
'''GMK:''' Did you find that programming in GPL was easier or more difficult than in 9900 Assembly Language?
'''JCP:''' Some things are easier in GPL, but overall, it's probably easier to learn and program in 9900 code. 9900 to me is very straightforward, easy-to-learn Assembly Language. It was easier than the IBM Assembler I learned in college. I don't think a person would really have any problem learning it. You have to get down the four or five basic routines that allow you to interface with the screen and sound. That sort of thing, I think, is fairly well explained in the Editor/Assembler manual. Once you've got that down, then it is a very straightforward process.
'''GMK:''' What steps were involved in the actual development of the game?
'''JCP:''' First, I very quickly started putting things up on the screen. I was thinking that if you start with a spaceship, then you've got to have something attacking the ship ... so I next put a couple of monsters on the screen. Then once you have the monsters, you've got to determine how they are going to be generated. That was probably the main element in the game - how the monsters were to be generated. One of the hurdles I had to overcome was keeping track of the monsters on the screen while generating new monsters. I kept track of the monsters in a linked-list type structure, and because of the limitations in CPU memory, I had to restrict the number of monsters that could appear on the screen to about nine. Then I had to resolve how the monsters would actually be generated. I ended up doing this with a screen search, where every so often the screen is actually searched to find a generating pair of saguaro cactus.
'''GMK:''' Were there any other major hurdles in the game's design?
'''JCP:''' That was about it, except for how the spaceship actually started out on the screen. This was another design element that had to be resolved. That's how the "safe area" [inside the grid] came about.
'''GMK:''' Was your game design seriously constrained by any memory limitations imposed on you?
'''JCP:''' No, the game is really a pretty simple model. It's not a very complicated game, and I didn't utilize all of the system capabilities in it. I didn't really come up with a feature that l wanted to implement but couldn't because of the system. Everything that I wanted I was able to implement with very little trouble. The only thing I could call a limitation was the amount of CPU memory, but the limits that were placed on me were probably good anyway.
'''GMK:''' How so?
JCP: We only have about
180 bytes of usable CPU
memory. This is where I kept
my linked list for my monsters.
Because of its size, I
was limited to maybe nine
monsters. I said that was probably
good meaning that if I
had fifteen monsters that
would have probably made
the game too difficult. As far
as chip utilization goes, the
game has one GROM and one
ROM inside the Command
Module. The GROM chip was
used for the graphics, and the
ROM chip for the 9900 code
-the ac tual programming of
the game. I used all the memory
available in the ROM, and
had quite a bit left over in the
GROM. If I needed to, I
could have put some of the
data I had in the ROM into
the GROM.
GMK: Did the basic game
scenario change any as the
programming evolved?
JCP: First of all, there
wasn't any real scenario at
the beginning. It was just a
capture-type game-monsters
attack ships, and ships shoot
monsters. When the game was
just about completed, a full
scenario was developed to fit
the game elements. Management
really had some problems
rationalizing my Western-
type background with a
space theme. At first, my
scenario consisted of an old
ghost town being taken over
by the government for a nuclear
power site, with the inevi
table nuclear accident oc-
==Game Credits for John Plaster==
