Jim Dramis

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

Jim Dramis was a computer software programmer for Texas Instruments (TI) programming some of the most memorable video games for the computer including Car Wars, Munch Man, and Parsec. Along with Garth Dollahite and Paul Urbanus, Jim created the company Sofmachine, Inc in March of 1983. The company produced three games, Spot-Shot, Barrage, and Jumpy. However, due to Texas Instruments exiting the home computer market and a lack of capital funding, Sofmachine was unable to publish and market these titles.

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 and 38-39:

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 if we relocated the sprite attribute table from where it normally was to the unused area of high-VDP RAM that I mentioned earlier.

GMK: Where did the idea for the tumbling asteroids come from?

JD: Paul Urbanus actually developed the different patterns in LOGO to get the tumbling effect. It was very easy to see the animation, and change the shapes accordingly. Then, it was a simple thing for me to just load the data for the different shaped into my program, change the coincidence a little bit, and away it went. . .

GMK: It appears that the speech doesn't slow down the play of the game at all. . .it comes through as being a simultaneous process. How did you achieve this breakthrough?

JD: Well, because we were already using our own interrupt processing for the sprite automotion, it made sense to also try interrupt-driven speech. This worked out extremely well; there was apparently no slow-down at all - even though there was 200 bytes of logic in the speech interrupt routines that had to be processed 60 times in a second.

GMK: How did speech fit into the overall game design?

JD: The idea behind the speech was to have a female onboard computer warning you of things that are coming - like when fuel is low and a fueling tunnel is up ahead, or that there's an attack on its way. So speech can be important in that it gives you some signals of what's coming up so you don't have to read the written messages at the bottom of the screen. You can still play the game without the speech; it was important, however, to make sure that speech wasn't totally integral to playing the game, because if someone doesn't have a Speech Synthesizer they would be out of luck.

GMK: What were the reasons for simulating a female voice?

JD: We wanted something different from the basic Speech Syntheiszer's voice, and also we were intrigued by the TV shows and movies that used a female voice as a spaceship's onboard computer. It seems to have a sort of mystical effect. Also, somebody told us that you couldn't digitize female speech because of things like high-frequency patterns. So, we just had to go off and do it. . .

GMK: What are some of the obstacles in producing games for the Home Computer at this point in time?

JD: The limitation is that you are working with an under-$200 computer with certain hardware architecture limitations that are built in. The only way to possibly overcome some of them is with software tricks. It's hard to create the tension and excitement of some of the commercial coin-op $3,900 arcade games - hard to compete with their special screens designed for each specific game, and hard to compete with their fancy remote controls.

GMK: Do you feel that with Parsec you've just scratched the surface in what this machine can do, or have you already pushed the machine to its limits?

JD: Well no - I think with Parsec it was just the beginning. With other games, I was becoming familiar with what I could do; but with Parsec, I'm now getting a feel for what the machine can do. It's a kinds o launching and testing of some of the good points of the machine, and taking advantage of some of the speed of 9900 code. There are many other things that are really still out there that we would like to explore and exercise.

GMK: So what you're saying is that the best is yet to come. . .We can expect whole new generations of sophisticated games coming from TI.

JD: Definitely. Because of the speed of the 16-bit 9900 processor, many exciting things are possible. To give you an example of its high speed, in Munch Man we had to put a substantial delay in between each pixel movement of the monsters and you Man - not counting the almost 4K-bytes of ROM code that must also execute in that period. If that delay was taken out, those monsters and your Munch Man would move around the screen so fast that they would look like they were twenty instead of four or five! This will give you some idea of just how incredibly fast the 9900 processor is.

GMK: What strategy and tips can you give players of your games?

JD: Definitely memorize patterns in Car Wars to get through on higher levels. In Munch Man, you have to pay close attention to the energy levels. On the higher screens, 15 and above, you have to make sure the chain gets completely laid down in one area before moving on. In Parsec, the big factor is gettings used to flying the craft instead of just laying on the fire button. Get used to moving the craft up and down, and changing the vertical lift speed at the appropriate time. Becoming a good shot, where you can hit a craft within one of two bursts, is a big factor in getting through the attack waves and making it over to the higher levels. If you can do this, you're well on your way to becoming immortalized in the 99'er Hall of Fame.

Game Credits for Jim Dramis

• Car Wars
• Jungle Hunt with Paul Urbanus and Garth Dollahite
• Munch Man
• Parsec with Paul Urbanus
• Pole Position with Paul Urbanus and Garth Dollahite
• Spot-Shot
• Vanguard with Paul Urbanus and Garth Dollahite

References

External links

• The Giant List of Classic Game Programmers
• MobyGames: James E. Dramis
• Wikipedia:Parsec (Video Game)