John Plaster
| John C. Plaster | |
|---|---|
 John C. Plaster from 99'er Magazine | |
| Alma mater | Texas Tech |
| Occupation | Software Programmer |
John C. Plaster was a software programmer and game designer working for Texas Instruments. He created two well-known games for the TI-99/4A. In 1981, he released his game Tombstone City, and in 1982, Chisholm Trail was released.
Interview
The following is from an interview done by Gary M. Kaplan that appeared in the 1982 Vol. 1, No. 5 issue of 99'er Magazine, pages 34-35, pages 47-48 and page 52:[1]
GMK: Have you programmed many games?
JCP: Tombstone City was the first. I've since programmed one other, and started work on a third.
GMK: What experiences have you had that you think contributed to your desire and ability to design computer games?
JCP: Nothing special, really. I just had a regular childhood ... played things like checkers, Old Maid, and poker. I never had played any arcade games before I designed Tombstone City.
GMK: Are you an artistic or creative person in other fields or activities?
JCP: I don't know that I'm that creative in other areas. I have a pure math background-that's what I majored in in school ... so maybe I have more of a logical-type mind than a creative mind.
GMK: What jobs have you had before coming to work at TI?
JCP: I guess I've only had three jobs in my life. My first job was working for my dad, a farmer in Canyon, Texas. I worked with him on the farm up until the time I went to college. I got my B.A. at Rice University, and spent a year at the University of Arizona doing graduate work. I completed my Masters and PhD in math at Texas Tech. That was where I worked as a TA [teaching assistant]. I also spent one semester at Abilene Christian University.
GMK: How did you start getting involved in computer games, and where did the idea for Tombstone City come from?
JCP: I just started playing around in 9900 [Assembly Language for the TI-99/4A] code. I really wasn't intending to write a game when I started ... I just drew a spaceship on the screen and played with it. I was probably influenced by the fact that most of the arcade games I was familiar with were space oriented. As far as the background of Tombstone, I spent a year at the University of Tucson in Arizona. The saguaro cactus found in the game comes from my living in Arizona.
GMK: How about specifics of the game ... how did these develop?
JCP: It was really what you'd consider spontaneous. I started putting the game together in April, and got a working version of it in May. There really wasn't a whole lot of forethought to it. I started putting it on the screen as fast as I thought of it. So, from the conception of the idea, to completion of the basics, we're talking about a four-week period.
GMK: From that whirlwind timetable, it would appear that you have had quite a bit of experience in 9900 Assembly Language coding.
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 actual 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 inevitable nuclear accident occurring that causes the monsters to be generated ... Somewhere along the line, management got upset by the idea of anything nuclear happening - especially a nuclear accident - so that scenario was completely thrown out, and eventually settled on the present Tombstone City: 21st Century [in which players find themselves in the 21st Century in an Old West ghost town threatened by an invading hoard of green alien monsters-villainous creatures called morgs who live on tumbleweeds and people].
GMK: Did you get help from others during the development process, or did you work entirely on your own?
JCP: Before I could start doing the game, I needed some help from the systems programmers to show me how to access the sound and get things up on the screen. As for the programming, that was all done by myself. There were several people who offered criticism.
GMK: Was this criticism given during the actual "play-testing" period?
JCP: Yes. One of the main criticisms was that the game was hard to play. At first there wasn't a white background for a cactus indicating where the monster was coming out. In my mind, you really didn't need that extra help because the monster still comes out in a totally predictable place. It is really very simple - the generation is done from the top of the screen to the bottom, and from left to right. But maybe having the white square helps a little bit so you really don't have to actually think about where the monster is coming from.
GMK: Were there any other criticisms during the period of play-testing?
JCP: I guess that was the main one. Later, toward the end of the process when more people had played it, people discovered that they could sit on the first screen and just shoot tumbleweeds all the time to run up a high score. This was a criticism that was not resolved in the released version, although that [technique of scoring] was not the way the game was intended to be played.
GMK: When someone criticized part of the game how did you handle it?
JCP: There were really different levels of criticism. For example, there was a suggestion to maybe change the spaceship to a six-shooter. That type of criticism I threw out because I could clearly picture a six-shooter, and I knew I didn't want it. Other levels of criticism, like the white background indicating where the monster comes out, I had my doubts about; but I went ahead and implemented it, and felt that it was probably a good feature after I played it awhile.
GMK: Is Tombstone City more a game of strategy or skill, or a combination of both?
JCP: When the game is played as it was intended to be played, I think it can be very much a game of strategy. It does take some dexterity to manipulate the keyboard, however. Some people really have a problem using the keyboard, so from that sense, it is a game of skill. Due to the speed of reaction of the keyboard, I prefer to play the game this way rather than with joysticks. In my opinion, once you get used to the keyboard, it is very fast-and to me, it's very easy to play.
GMK: I found the joystick reaction quite fast when compared with a game like The Attack. How do you account for such a difference in speed?
JCP: The big difference between the two is because The Attack is written in GPL, a pseudo-assembler language. Tombstone was written in 9900 code, and 9900 code is, of course, quite a bit faster than GPL. In the GPL version of The Attack, I'm pretty sure they were utilizing the full speed of GPL, whereas in Tombstone we actually had to put in delay loops to keep the ship from moving too fast.
GMK: What features or elements of strategy did you put into the game that a typical player might miss seeing?
JCP: After you've played the game a while, I don't think there are really any hidden features, but there are some basic strategies that a first-time user might not realize. One of those features is what I call "dragging." That is where you have a lot of generating pairs of cacti all lined up in a row, and when the monster has generated from the first pair, you shoot it-destroying the first generating pair, and then you drag the monster over to the next generating pair and kill it next to those; it kills that generating pair, and then you drag the monster on and on until maybe you've got six generating pairs wiped out from a single monster. You do all this by positioning your spaceship so that the monster has to go by a generating pair of cactus in order to come get you. It's a chain reaction type set-up.
GMK: What do you feel is the most challenging aspect of the game?
JCP: Certainly, the hardest level to play on is Level 3, so that would present the most challenge. It is also very challenging to get yourself trapped in the safe area and allow nine monsters to be on the outside. From this position, it is very hard to recover.
GMK: Is it really possible to play well on Level 3?
JCP: Yes. I quit playing on Levels 1 and 2, since I found they could be mastered fairly easily. Level 3 I still haven't been able to master, so it is still very challenging.
GMK: When one becomes a better player of Tombstone and is able to score s significantly higher and advance farther, it appears that the game takes on a different character and becomes more addictive. Is this a fair assessment, and if so, how did you achieve it?
JCP: I think that's a fair assessment. I really didn't have in mind what would happen on the higher levels - when you have more cactus out there to start with. That's when the game, to me, becomes more interesting . . . when you've got maybe twenty generating pairs out on the screen to start with. since I didn't intend it to, or even realize it would be this way, it was actually an accident.
GMK: You must have become quite happy when you discovered this . . .
JCP: Yes, happy that it did become more interesting at that level, but maybe a little disappointed that it wasn't that interesting when you first started playing it.
GMK: How did you feel letting the game go after the final polishing was done?
JCP: Overall, I felt pretty good about the game. I was a little upset about a few things. One thing that I guess didn't make a whole lot of difference was the title of the game. They changed it from its original title to Tombstone City: 21st Century-the 21st Century to sort of justify the Western-based conflict. The other thing that I had to change was the actual tombstones to saguaro cactus. What are saguaro now, were originally old Western-type crosses-with the two sticks forming a cross. That was objected to because of religious reasons. It made a little bit more sense originally when you actually had the tombstones in there. So when the tombstones were taken out and replaced with the saguaro cactus, it didn't make as much sense to me ... but I guess it's not a big difference.
GMK: When you finally let the game go, were there any things that you thought about that you might have liked to have added?
JCP: I thought about several things I could have added, but I was still pleased with the play of the game. You can go on and on with games, but there has to be a cut-off somewhere. Since I was pretty well satisfied with the point I had reached, I was ready to let it go.
GMK: What did you learn from the experience of designing and programming this game?
JCP: Well, of course, the main thing was learning the 9900 code. I was really impressed with the capabilities of the home computer-in the speed we could actually get from the 9900. I now realize that graphics are probably the most important thing in a game. I think you can probably be all right by throwing graphics on the screen and designing the game around your graphics rather than designing the game first, and then doing the graphics. Sometimes it works better one way, sometimes the other. But a lot of times your graphics influence how the game is going to be played.
GMK: Does this reasoning also hold true for sound effects?
JCP: To me, sound isn't that important. The sound, I think, can be added as an afterthought. If you have a game that plays well, I think that should be the thing that holds the interest of the user. The sound should be just a fringe benefit.
GMK: What are your personal high scores on each of the three levels?
JCP: On Level 1, I never really played for a score - it's really a slow level. On Level 2, my high score was 528,000 occurring on Day 42. On Level 3, my high score was 136,500. That occurred on Day 13.
GMK: Do you think it's possible for other players without the intimate knowledge of the game that you obviously have-to score this high?
JCP: Yes. Once you reach a certain point on Level 2, your score can almost go on indefinitely. On Level 3, I was never able to get past Day 13. I think that a person would have to spend a lot of time to get a high score on Day 13, although it probably isn't impossible.
GMK: What final tip s can you offer to players of the game?
JCP: The whole key for beginning players is to kill the monsters immediately when they've generated. This [advice] also goes for any player, regardless of skill. You must know beforehand when the monster is coming out, and exactly where it is coming out from so that you can immediately shoot it to destroy the generating pair. For the more advanced player, keeping the safe area clear is probably the most important thing; you can't afford to kill the monsters next to the safe area. If this happens, try to set it up where you can use your "dragging" tactic to move the cactus away from the safe area.
GMK: One final question. In Level 3, how can you stay alive the longest?
JCP: In Level 3, you just cannot afford to make mistakes - you cannot kill the monster and form another generating pair. If you start forming other generating pairs by your mistakes, it becomes almost irrecoverable after you get so many on the screen ...
Game Credits for John Plaster
References
- ↑ 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
