Jim Dramis

Jim Dramis
Jim Dramis from 99'er Magazine
Alma mater	Kent State University
Occupation	Software Programmer

Jim Dramis was a computer programmer for Texas Instruments (TI) programming some of the most memorable video games for the computer including Car Wars, Munch Man, and Parsec.

Interview

The following is from an interview done by Gary M. Kaplan that appeared in the January 1983 issue of 99'er Magazine, page 26 - 27:

An Interview with Jim Dramis - Game Designer and Programmer Extraordinaire

Background

Jim Dramis, a 32-year-old programmer with Texas Instruments, is not the kind of person who you'd picture as a whiz-bang arcade game designer. As a former high school math teacher and insurance agent, the mild-mannered Dramis was far removed from the fantasy world of space ships, lasers, racing cars, and hungry video creatures. An Ohioan by birth, he completed his B.S. in mathematics at Kent State University and went on to a brief stint as a manufacturing supervisor at TI. From there, Dramis worked for a couple of years as a special agent for an insurance company. After another two-year Interlude, 1979 found him back at TI, this time working as a programmer analyst on minicomputers being used for the calculator and watch repair system. From this support environment, Dramis transferred to TI's Consumer Products Group, where he got involved in some Extended BASIC educational software development. But it wasn't until a year-and-a-half ago, when he started work on his first game, Car Wars, that Dramis began to explore his real creative potential - as evidenced by follow-up work with Munch Man, and the new TI smash hit, Parsec.

Questions and Answers

GMK: What influence does your mathematics background have on your present work as a game designer and programmer?

JD: I think that the logic and thought process that one develops in going through the rigors of mathematics certainly does help in game design and the programming of computers. They seem to go hand in hand.

GMK: What about your experience as a teacher?

JD: My teaching experience has helped me instruct other programmers here at TI. In designing the games, the educational background helps to a certain degree, because I'm constantly thinking, "How is the audience going to perceive what I'm doing?" You try not to make the game too complex, but rather interesting and a good experience.

GMK: How do you feel about games as a form of entertainment and enrichment?

JD: Well, I think games add more to your enrichment and learning than just hand-eye coordination and skills. We're just now starting to observe the effect of game playing on the entire learning and educational process. Motivation and involvement have a lot to do with it.

GMK: How do you feel about yourself playing games all day for a living. . . and what about the children who play your games?

JD: Actually it might sound kind of funny, but to me, writing the game is more fun than sitting down and playing it for hours. There's a lot more that goes into designing a game then meets the eye. As for children, there was one girl I was talking to who told me she played Munch Man hours each day and scored 294,000 points. It's a good feeling to know that someone out there likes the product that you've created.

GMK: Did you play a lot of games as a child?

JD: I played cards a lot. Board games too. This interest and intrigue with numbers and logic from an early age might have contributed to my interest in games. I think that - especially in the environment that I'm working in-is in­teresting because you're trying to push the machine at its ultimate limits. You're trying to muster everything graphically, speed-wise, logic-wise - out of the machine that you possibly can. The limit there sometimes is just the limit of the programmer's imagination and skills. It's pretty challenging.

GMK: Is the process of designing a game a game in itself?

JD: Yes, there's a certain ten­sion, a certain risk-reward, and there's a goal. Son1c of these key elements you find in the ac­tual game that you produce - you have a certain tension about doing a game because in your mind there are four or five ob­stacles that you know have to be overcome, and you're not sure you can; it's kind of exciting each day - you never know, how far you're going to get. There's a certain risk because you could spend six months on a project, and it could very easily be a total disaster. Sometimes there's a fine line between a great game and a total wipe-out. There's al­so a goal - finishing the proj­ect - that means making sure it is a marketable, bug-free prod­uct. So you're right - there is a game in creating games.

GMK: How much of Car Wars and Munch Man did you actually do?

JD: Car Wars and Munch Man were basically my own - games that I was responsible for and did the programming on. Car Wars, my first game, was one GROM; that was all programmed in GPL. Prior to actually starting work on the game, I attended GPL classes here and took a couple of weeks just to familiarize myself with the GPL manual and the architecture of the Home Computer. Basically I learned the GPL language by doing the programming for Car Wars. Similarly, with Munch Man, I learned 9900 code [Assenbly Language].

GMK: Can you give us an account of the evolution of Car Wars from idea to finished program?

JD: In a lot of these games, we don't just go off in a corner and dream them up. We get good suggestions, help, and ideas from a lot of different people - even systems programmers on how to improve or write a subroutine. I had the basic game design idea, and the first thing I wanted to make sure was that GPL had enough speed to handle the motion, or whether I would have to use automotion. In this program, I did not use automotion of sprites. Those cars are double-sized, magnified sprites. I moved them one, two and four-pixel increments myself.

One of the main problems in the game was the logic. For instance, the track has all different characters that tell me whether the car can turn left, right, or change lanes. Once I got that programmed and working well, the rest of the game was really just polishing up - making the track look better, adding scoring and color, extra computer cars, etc. The whole effort took two and a half to three months of programming.

GMK: Now, let's get into Munch Man. Why did you decide to do a game like that?

JD: I wanted to take advantage of our machine's color graphics and sprites. A maze-type game seemed to offer interesting possibilities. The logic in Munch Man is similar to Car Wars, where I was moving the sprites pixel by pixel; I needed the logic to recognize special characters in the maze that determined whether I could go left, right, up or down. This was the same obstacle I had in Car Wars, so I took the main Car Wars routine and converted it from GPI to 9900 code. That took about a month. Then I tried to design some type of maze that was interesting and would take advantage of our graphics and color.

GMK: Did you run into any major problems where outside help was needed?

JD: There weren't any major problems. I only needed help on a few subroutines. No one can be expected to know everything about the machine, so when someone runs into a problem, he'll take a lot of suggestions from fellow programmers because often they have gone through the same thing in another project. In fact, they may already have a subroutine that you can take and just modify. I used at least three or four subroutines that were in TI Invaders.

GMK: During the final polishing and testing of Munch Man, a lot of your fellow programmers must have offered their criticism - how did you take this?

JD: Well, there was a first slightly unfavorable reaction because of the blood, sweat and tears already put into the game - I tended to take it personally. But there are a lot of us that have gotten used to criticism. In fact, many of us now enjoy the interaction. You can take others' ideas or not - it's ultimately up to you. It doesn't hurt to have someone be very critical. Most of the time it will help you. There was a lot of what we call "tweaking" the final process of the package - the five or six parameters of Munch Man that had to be human factored. It certainly did help to have people critical of the fairness, speed, difficulty, and risk-reward factors in the game, so that I could successfully fine tune it.

GMK: Were there any major changes from what you thought was the finished version to the actual game release?

JD: Some of the programmers felt that the learning curve as relating to the beginning difficulty of the game was not quite fair. Following their suggestions, I made the game less difficult at first. It kind of gives the player a bit of a break - a toehold for learning and improving skill in the game.

GMK: How well do you do when actually playing your own game?

JD: Well, like I said earlier, I get more enjoyment from programming than actually playing the games. Because of this, I really haven't tried to get high scores. In Car Wars my top score is about 33,000; Munch Man is about 122,000; and Parsec, about 77,000. So I haven't even broken 100,000 on Parsec yet! They're good scores, but not even close to the top scores. One of the problems is that we have a debugger here, and I can easily cheat my way through the games. And you get so used to boosting yourself up to the higher levels...you've already been there, and it's so easy to do that you don't really want to take the time to get there legitimately.

GMK: Can you give us a little background on how Parsec evolved?

JD: We started Parsec in the middle of February and completed it in the middle of July, so that was five months. But that was with two of us working on it. Paul Urbanus, my partner, was a summer student here; he worked on Parsec for two months. The game therefore really took a total of seven man-months to complete. Paul certainly did help tremendously in getting it done; he wrote several of the major subroutines such as the speech interrupt-driven part of it, and helped speed up the scroll subroutine. Paul also modified the line-drawing subroutines that he had already been through [the LINES demonstration program that comes with Mini Memory-Ed.] for use with Parsec.

GMK: What was the major technical problem you had to overcome?

JD: Well that would have to be the scrolling routine. There was heavy access of VDP RAM. And any time you do that, you run the real risk of slowing the whole thing down tremendously. Paul used the trick of loading some of the program code into the fast CPU RAM on the 16-bit bus. This gave us about a 20% boost in speed of the scroll routine.

GMK: We understand that Parsec is the first TI game to be released that used the high-resolution graphics mode of the video processor chip in the TI-99/4A. Can you tell us something about how sprites work in this mode?

JD: The problem with using the high-resolution graphics mode is not only being unfamiliar with it, but also understanding the constraints. First, it uses up so much of the VDP RAM that there's only 2,000 bytes of RAM free for the programmer to use. Also, at the time, we felt we could not use sprite automotion in this mode. The problem we had was that the scroll used up so much processor time that in order for me to move sprites on the screen, I had to use automotion. If I were to move the sprites pixel by pixel as I did in Munch Man and Car Wars, it would be way too slow. I had to go to automotion or else the project would have been killed.

At this point, Paul remembered that the 99/4A's newer architecture would allow us to do our own interrupt processing; this meant that we could do our own sprite automotion it we relocated the sprite attribute table from where it normally was to the unused area of high-VDP RAM that I mentioned earlier.