For your custom home arcade machine needs, visit here
and use Coupon Code: DREAM220
||Chasing the Dream: The Tribulations of a Bedroom Game Programmer
Chasing the Dream: The Tribulations of a Bedroom Game Programmer
Author and Multimedia: Nickolas Marentes
Editing: Bill Loguidice and Matt Barton
Online Layout: Bill Loguidice and David Torre
Special Thanks: Matthew Reed of the TRS-80 Emulator Web Site
Comments: Visit the author's Website or send an e-mail to email@example.com
Emulation Notes: Game ROM/image files have been provided within the article for four TRS-80 Model I programs. According to the author, presently, the best emulator to run these files is called TRS32, which is for Windows. The emulator is shareware and payment provides extra features such as hard drive and high resolution graphics support. These features are not needed to run these games. The emulator is almost 100% faithful to a real TRS-80, save for a small issue with timing where the title pages for these games seem to stay up for too short a time. Otherwise, the games run perfectly. Click the following system name for the required TRS-80 Model I and Model III system ROMs. While additional ROM/image files are not provided here, please note that none of the Color Computer emulators presently run Neutroid 2 correctly because they don't support the semigraphic video mode that that game uses. The games for the Color Computer 3 do not run correctly on any emulator except MESS. For these and other downloads, as well as to purchase some of the actual software, please visit the specific page on the author's Website.
My name is Nickolas Marentes, and I live in Brisbane, Australia.
In 1979 I was introduced to computers. This event would become a major turning point in my life and set the stage for an ambition to become a videogame programmer. This is my story.
I have been an avid computer hobbyist for over 25 years. Over those years I have worked on many personal projects with the goal of creating successful computer products. This article will concentrate on my primary interest of videogame programming.
I have designed this article to be read sequentially from the first project to the last so you can see the progression of events, ideas and decisions that I made as time went on.
As I detail each project, you will read about my dreams and desires for each project, the challenges I experienced during their development and the inspiration and motivation behind them. I will show you how I achieved everything on a shoestring budget using very limited development tools. I will cover the post product development stage which involved documentation, packaging and marketing, all of which I had to do myself.
Those were days in which it was easier for one person to create a small software company operated from a bedroom office to create and market a few videogame programs. Today, the games are far more complex and software houses employ many people and cost up to millions of dollars to produce.
I enjoyed doing each of these projects, and I am grateful to those who supported my efforts by purchasing my products. This article is my way of thanking them for that support.
I started with computers back in 1979 when I would drop in to the local Radio Shack/Tandy store after school to play with the TRS-80 Model I that was on display. In those days, computers were new and the store manager had no idea how to use one so having a kid sitting at the computer writing programs was a good way to demonstrate the product.
"See, even a kid can use one!"
It was a mutually accepted scenario; he didn't have to worry about the customer finding out that he barely knew how to turn the thing on so there was always a chance of making a sale. I had the opportunity to type in my BASIC program listings that I would write up during classes at school and as a bonus, I got to show people how smart I was. An ego and an education in one package, what more could I want?
The first TRS-80 was known as a Level 1 BASIC system with a whopping 4K of RAM. That's right "K". I got so good at writing very tight multi-statement lines, that a page of code had no defined line breaks or indentations, the screen was just one solid block of text. After about six months, I had reached the limits of that machine. I had squeezed every ounce of RAM and speed that I could draw from it, and I felt that I couldn't be topped.
Then one fateful day, I went from fame to lame in the blink of an eye.
There was this other kid who came into the store every now and then to tinker with the machine. Like me, he didn't own his own computer, but, unlike me, he didn't spend his free time programming "Star Wars - Shoot the Tie Fighters" type games in BASIC. You know the kind I mean, the ones that used ASCII characters to represent Tie and X-wing Fighters.
Tie Fighter = IOI
X-Wing Fighter = >O<
Vader's Fighter = (O)
He comes in one day, loads up a cassette tape of T-BUG — a monitor and debugging program for entering hexadecimal machine language code — and executes it. The piece of code he had created was only a few bytes long and all it was meant to do was to clear the screen to all white. In BASIC, I had devised ways of creating strings of solid block characters and printing entire lines to fill the screen. I was particularly proud of the fact I could "white out" a screen in under two seconds. But when this kid hit the ENTER key to execute his short piece of machine language code, it did an instant "white out" with no noticeable screen drawing!
I had met my match and from that day forward, I knew that I was destined to learn Assembly language programming. I knew that this was the secret to creating arcade quality videogames. I began to have visions of creating a software empire and creating some of the greatest games seen by mortal man! I was going to be rich, but more importantly I was going to be famous! A legend! A god!
After a few hours, the gas in my head wore off and I realized that before I could even start my trip "to the other side," I had to get myself a computer.
TRS-80 Model I
So, how was I going to convince my parents to part with $850 and buy me that shiny new battleship grey Level 2 TRS-80 with 16K of RAM, cassette data storage and sexy monochrome monitor?
I did what every kid did in such a situation...
...I told my parents that it would help with my education...it worked!
I immediately got to work. This TRS-80 had a more advanced version of BASIC than the one I was familiar with in the Tandy store. My machine also had 4 times more memory! Yep! I was gonna be the guy to light the world on fire with the most powerful TRS-80 on the block, all 16K of it! Okay, 16K ram may seem a bit on the small side today, but I definitely did have the most powerful TRS-80 on the block, possibly even the entire neighbourhood! You see, there weren't very many people with their own TRS-80, let alone their own personal computer. Back in those days, there was a lot more choice. There were TRS-80's, Apple II's, Commodore Vic-20 and 64's, Atari 400 and 800's, and Sinclair ZX-80's to name but a few.
They were the good old days of the home computer industry. It wasn't just a matter of what game was the best, it was also a matter of which version of a game was best. For example, there was a version of Zaxxon created for almost every system available at the time. Some versions stood out as being better than others due to the skill of the programmer as well as better hardware capabilities of the host computer. A skilled programmer of one version could push the boundaries of systems with more limited capabilities to create a better version of the same game than that running on a more powerful system.
It was also fun to challenge other users about their choice of computer.
"Is that a graphic pixel on your TRS-80 or did you stick a disk label on your screen!?"
"I can load a program faster from tape than you can load it into your Commodore 64 via disk!"
"Hey look! If I blink my eyes at the right speed, I don't see the screen blanking on your ZX-80 anymore!"
So after mastering the new Level 2 Basic and learning a bit about Assembly language by studying a magazine listing of a pong-like game written in Assembly language, I decided to show everyone what my TRS-80 and I were capable of.
I started a small software label under the name Supersoft Software which was later changed and officially registered as Fun Division. It was a small "cottage company" which I primarily ran by myself along with some help for a short time with a friend who contributed a TRS-80 game he called Moon Scout which was a clone of arcade Moon Patrol.
During the period from 1982 to 1984, I wrote seven commercial quality games on my TRS-80 Model I, all developed using a cassette player for data storage, no disk drive! If you have never used a cassette player for data storage, then you haven't experienced the sheer adrenaline rush that can only be had when waiting over 10 minutes to save your latest source code updates only to see it all crash into a heap because of a minor error that you missed. Arrrgh!
By 1984, the TRS-80 was showing its age so I decided to move up to something newer with high resolution and color graphics. Since I was already familiar with the Radio Shack/Tandy line, I did not want to waste time learning a whole new system so I chose to go with the Tandy Color Computer (CoCo) complete with 64K RAM and dual floppy disk drives. Although it wasn't as graphically impressive as many of the other competing systems on the market at the time, it had two important attributes. Firstly, it had what is considered to be the most powerful 8-bit CPU, the Motorola 6809. It was powerful because of its extensive instruction set and advanced interrupt handling. Secondly, the Tandy Color Computer had a large distribution channel via the many Radio Shack/Tandy stores, a fact that I hoped to exploit for my future Tandy Color Computer games. In 1986, Tandy released the Color Computer 3 with improved graphics, more memory and faster speed.
In 1992, Tandy decided to discontinue the Color Computer, so I decided to move on to the Commodore Amiga. Due to lifestyle changes, I never did create any software for the Amiga, but in 1997, the bug caught me again and I returned to the Tandy Color Computer. Via Internet Newsgroups, I found that a dedicated group of faithful users still existed. These were people who believed that the full power of this small computer had yet to be fully realised. It was also a way of bringing back the past and meeting with old friends to once again talk about their favourite 8-bitter.
Tandy Color Computer 3
I got to work and created several new games and achieved some important projects before finally calling it quits at the end of 2002.
What follows is a game by game account of my dream to become a successful videogame programmer.
Stellar Odyssey Packaging
Stellar Odyssey Title Screen
Stellar Odyssey (1982, TRS-80 Model I)I made up a name for my new software company called Supersoft Software (I later changed the name to Fun Division because I found that another company in England was already using that name) and wrote my first game, an adventure game called Stellar Odyssey. It was written in BASIC with a few machine language subroutines to speed up the graphics. For those who remember, it was modelled on games like Temple of Apshai and Rescue at Rigel from a software company called Automated Simulations, later renamed to Epyx. The best way to describe the game is that it was a combination of Rescue at Rigel crossed with a Scott Adams adventure...but with better graphics, sound and an easy to use command entry routine.
Here is the story pretext I created...
"Cruising through the tranquillity of space, you are awoken prematurely from suspended animation by the ship's on-board computer. Trouble lurks for the ship has stopped, power is low and the rest of the crew's tubes haven't opened yet. You must explore the craft, being cautious of any dangers that may exist so as to bring your mission back in control."
Pretty exciting don't you think? It sounds like the story intro to just about 90% of the space adventures at the time!
I had developed a simple command interpreter with a limited vocabulary of basic verbs. These verbs were accessed by the single press of the first letter. The following noun if needed, would be typed in full. For example, pressing 'G' would bring up the verb 'GET'. Then a noun such as 'PISTOL' would be typed in full.
The graphics were neat, too. When the command SPRINT is issued, your character actually walked, fully animated in monochrome low resolution graphics to the next 'square'. Likewise, when you fired, your character actually pointed his pistol and fired a bullet across the room. Very impressive — at least to me.
After completing the programming, I had to prepare it for sale. I had to draw up my own package artwork and duplicate my own tapes, write my own instruction sheets (printed on a small Tandy plotter printer), and sell it to anyone I could via user groups and small advertisements in local TRS-80 magazines. It sold for $10AU per package, and I still have my sales receipt books with my first software sale dated December 8, 1982.
These early sales only amounted to about 20 copies sold. I didn't sell enough to make me rich, but I was a kid and everything I earned was good pocket money. Besides, I was addicted! I wanted to sink my teeth into a 100% Assembly language game!
Cosmic Bomber (1982, TRS-80 Model I)I began planning my next game. I knew it had to have fantastic fast graphics and sound, so I had to write it completely in Assembly language. I also wanted it to be an original game idea so I took a cue from the marketing world...I stole some ideas from two other games and called it something else!
I combined the last stage in arcade Phoenix, the Mother Ship scene where you had to shoot your way through the bottom to destroy the alien within before the ship closed in on you plus a few characteristics of arcade Space Invaders. I called it Cosmic Bomber, and I was legally clear!
Again I came up with a cheesy story pretext...
"The screen flashes at you "Bomber craft in range" and you prepare yourself for battle. The Aliens are back to destroy you but this time, it's you against the Mother Ship. You must penetrate through the bottom of the craft to kill the alien gunner within. But be careful, for the alien is loading his bomb racks and once they're full, they begin dropping and exploding on the ground, at the same time, the bomber is coming down to land and invade Earth. Beware the bomber craft's escort ship hovering above firing high speed missiles at you. Earth is depending on you comrade so give them all you've got!!"
Wow! Don't you just feel pumped after reading that?!
Cosmic Bomber Packaging
Just as with Stellar Odyssey, I drew up my own package artwork and photocopied it onto colored paper, recorded my own cassettes straight from my TRS-80 and wrapped it all up in the same zip loc bags used to wrap kids' school lunches in. I was looking like a pro!
I sold to computer club members and sent a few flyers to customers of my Stellar Odyssey. Again, the money wasn't anything to shout about but was okay pocket money for a school kid with visions of greater things to come. Alas, this is the part of the story where I unveil blunder number one. I have no idea how I let this happen but somehow, I lost the game, source code and all. After completing the game, I went straight into my next game idea that I had been brewing during the development of Cosmic Bomber. I was so focused on the new idea that I must have overwritten the files for Cosmic Bomber. Cosmic Bomber sold less than Stellar Odyssey so maybe I treated it like an unwanted child and it ran away?
Neutroid (1983, TRS-80 Model I)
After sweating through the silent corridors of an alien vessel in Stellar Odyssey and saving the planet in Cosmic Bomber, I was now ready to turn up the heat! I wanted an adrenaline rush and I wanted it to be louder than any other TRS-80 game! No more aliens and spaceships. Neutroid was to create a surreal environment at the atomic scale.
Neutroid Title Screen
The inspiration for Neutroid was from an interview of Tim Skelly in the October 1982 issue of Videogames. Tim was the designer and programmer of arcade Reactor, a game played at the atomic level. With Neutroid, I loved the abstract idea of playing with atomic particles especially when the player didn't actually control the particle itself. Instead, the player controlled the environment around it in order to guide the Neutroid particle to a desired destination and outcome.
As usual here is the story pretext...
"In Neutroid, you are at the controls of a small atomic particle accelerator or synchrotron. In it, Protroid and Antitroid particles appear. Bonus energy regions, high energy walls and deflector rods exist. The aim? Control the movement of an atomic particle called a Neutroid within the synchrotron and neutralize all the orbiting Protroids before your Neutroid becomes energy saturated. Your Neutroid starts off slow and in a low energy state but as it gains energy, its speed increases till it finally reaches the high energy state where controlling it requires a high degree of rapid strategic thinking and lightning fast reflexes."
I can't remember what I had taken to dream up a story like that but I hope the stuff has been banned!
Neutroid Instructions Screen
The game itself starts slow and as time passes, it collects energy and begins to accelerate. The pace picks up to the point where fast reflexes and the ability to plan ahead using your peripheral vision is needed to keep everything in check. To add to the tension and atmosphere of the game, as much TRS-80 style sound effects as I could create were pumped through the 1 bit sound system. The TRS-80 didn't have a dedicated sound chip and the only way to output sound was by toggling the cassette output port on and off (Editor-BL: Sounds were produced by modifying the sound output for loading and saving programs to cassette tapes. To listen, you used an amplified speaker plugged into the cassette output port.).
Neutroid Game Screen
With Neutroid, I felt I was starting to develop games which began to approach the then king of TRS-80 Model I game programming, Bill Hogue of Big Five Software. Bill's games were regarded as state-of-the-art and were very polished. I had set myself a goal of creating games like Big Five so I had decided on a few "standard specifications".
1) All games must cycle through an animated title and instruction screen.
2) The use of sound tables to create more complex sound effects. NO BEEPS!
3) Double buffering of video to reduce flicker, screen stutter and redraw effects.
4) All keys must respond instantly.
5) Professionally designed and animated graphic objects and characters.
6) Great gameplay!
But how can good objects be created on a low resolution display such as the TRS-80 Model I with its 128x48 resolution?
No matter how low resolution the graphics system, it can still be made to look great if it is well designed and animated correctly. With good animation, the low resolution is de-emphasised. I remember drooling over the higher resolution graphics of other systems such as the Apple II, but few Apple II games excited me because the overhead of higher resolution graphics made the animation of lower priority. Many games avoided too much character animation in order to simplify the coding and keep a reasonable frame rate of play. Games from Big Five Software and another duo, Wayne Westmoreland and Terry Gilman proved my theory every time.
Neutroid's best feature also proved to be its worst. The concept of atomic particles in a user controlled environment proved too abstract for most and was proven with lacklustre sales. I felt it was a far better game than many other "successful" ones but I guess I had fallen into the trap of being too innovative. People will cry for new and innovative ideas but when it comes to parting with hard earned cash, they prefer to spend it on something familiar and guaranteed.
Well, Neutroid didn't make me a millionaire either, again only selling about 20 copies. I needed to find a more familiar game scenario yet still satisfy my desire for something new and challenging. I had to change my motivation of "me, me, me" and start satisfying "them"...and me!
The Gladiator (1983, TRS-80 Model I)
The Gladiator is a futuristic version of the Roman fighting arenas. Your goal is to survive each round of fighting in an arena enclosed in an energy barrier. Outside this barrier are cannons that track your movements and fire at you. You need to destroy them by puncturing a hole in the energy barrier with your Tobo Sphere and then send it into one of the four cannons. Inside the arena are combat droids. As you progress through each round, you will be placed against a higher level combat droid. These droids mutate down to a previous level with each direct hit of your Tobo Sphere until they are finally destroyed.
The Gladiator Title Screen
The inspiration for The Gladiator was the Walt Disney movie Tron starring Jeff Bridges and Bruce Boxleitner. The movie was a bit of a flop for those expecting another "cutesy" Disney movie, but the die hard computer nerds of the day fell over backwards for it, and today it has become a cult classic. The sound in this game is awesome! After playing it again after so many years, I was blown over by the sound, especially considering the limited capabilities of the TRS-80. I honestly believe that it left many of the games on the other systems of the time for dead. The action was also frantic, carrying the tradition I started with Neutroid.
And now we interrupt your reading pleasure with another story pretext design to stimulate the bowels...
"The scene is a 21st century coliseum and the Gladiator is beamed into the centre of the arena. But the sword and shield has now been replaced by the Body Field and Tobo Sphere and where the Gladiator once fought with dangerous animals and other skilled combatants, he is now involved with the deadly ZENUS-5 series of muto-combat droids and tracker cannons. He prepares to cast his Tobo knowing that he is outnumbered and that his opposition is determined to have him down. Only speed, skill and quick wit will carry him through the events."
Mark my words, one day Ridley Scott will do a futuristic remake of his movie Gladiator based on this story line!
The Gladiator Instructions Screen
This game follows on with the philosophy of Neutroid but takes out the abstractness and replaces it with a human character versus mutating battle droids. It contains the same concepts as Neutroid, lots of complex sound, fast and frantic action, and a need for quick decision making.
The Gladiator Game Screen
As all the games prior to this, all programming was done using a cassette based TRS-80 Model I. I had to load the Editor/Assembler via tape (3 minutes), load the Assembly source code into it (up to 5 minutes), key in my latest additions and corrections (which were hand written first), then save the new source code (up to 5 minutes), and finally save a compiled binary (2 minutes) after which I could load the binary into memory (2 minutes) and any graphics and sound table data (2 minutes) to see it run....or fall in a heap if there were bugs. Very time consuming, but at the time, I hadn't experienced better, so it really didn't bother me. The time waiting for data to load from the 500 baud cassette was used to write more code or work out a fix for a bug.
The Gladiator High Score Screen
I did have one drama during this development period. I only had a 16K TRS-80 at the time, and I had run out of memory to hold the Assembly source code, so I split the source into two separate blocks. One contained the common subroutines while the other contained the main game code. Somewhere along the way, one of the blocks on the cassette became corrupt and unreadable. Luckily, I always kept two rotating copies of the code so I fell back a version and just had to retype the missing parts of the code.
The Gladiator Packaging
The Gladiator was a great game even though it was hard to master. It required a mastery of the arrow keys on the keyboard used to move your character around the arena. Sales were an improvement over Neutroid with sales of around 30 packages and I felt I was starting to have some success. The package art that I drew bears a resemblance to the electronic warriors in Tron which as I mentioned, was the inspiration for this game.
I was proud of The Gladiator. It was a good game with some neat animation and fantastic sound effects. People were starting to see the quality in my games. If I could have had a US distributor for this game, I believe it would have been a big seller. Alas, living in Brisbane, Australia and no such thing as the Internet then, all marketing was confined to clubs and mail outs of my newly created software catalogue to all my past customers. I guess I was on the wrong side of the planet.
Stellar Odyssey Part 2 Title Screen
Stellar Odyssey Part 2 (1983, TRS-80 Model I)A sequel to the original Stellar Odyssey was something that I always had planned to do. With my new experience in Assembly language after creating Neutroid and The Gladiator, I felt that I could do a few improvements to the original Stellar Odyssey as well as further the main story line. It was not necessary to have completed the original Stellar Odyssey to play this sequel.
In Stellar Odyssey Part 2, you began from the Earth rescue craft that found you in the previous adventure. But you soon discover that things aren't right and you begin your quest that leads you to the alien's base where you must confront the evil alien superiors...all three of them, Yargon, Kilto and Cajole.
Keep yer gut in, here comes a story pretext....
"After escaping from the aliens' battle cruiser, you are instantly beamed to the safety of the Earth rescue craft. But an eerie silence surrounds the craft as it floats inert in space and the flight crew are nowhere to be found. Prepare yourself for the final conflict as you confront the evil alien superiors, discover strange devices and explore the alien landbase."
This storyline would make a great B-grade science fiction movie. It may even be corny enough to be a box office hit!
Stellar Odyssey Part 2 Game Screen
I tweaked the command interpreter of the original a bit and made the entry window a bit more stylish with a flashing cursor and some sound effects as you typed. As in the first Stellar Odyssey, the verb command was displayed by pressing the first letter and the player typed the full noun.
Stellar Odyssey Part 2 Packaging
In the original Stellar Odyssey, any objects around your character were just described in the text window like a normal text adventure, but in Stellar Odyssey Part 2, they are graphically shown. The animation was also slightly faster and the sound was improved. As with its predecessor, Stellar Odyssey Part 2 was written as a hybrid, BASIC with Assembly language subroutines. It was a relatively quick program to put together, not needing to load editor/assemblers all the time as with the full Assembly language games. Overall, this game was more polished than the original.
Sales were moderate for this one, since many people who had bought the original Stellar Odyssey came back to buy this sequel. I also found some people buying both simultaneously. I was beginning to get cocky with my artwork as I began adding better detail. They were starting to evolve from something that looked like it was done in pre-school to something approaching the quality of...primary school. At least it was getting better.
Donut Dilemma (1984, TRS-80 Model I)
Donut Dilemma was my best TRS-80 Model I game. It is a platform style arcade game like the popular Donkey Kong in the arcades that featured nine different and progressively challenging levels.
Donut Dilemma Title Screen
The inspiration for Donut Dilemma was my family's donut kiosk that we owned at the time. We had this donut making machine where you filled one end with dough mix and fresh hot donuts would come out the other. The dough was automatically dropped into the hot cooking oil, complete with hole in the middle, via a synchronised plunger. A conveyer belt system would then slowly push the donut across the oil as it cooked one side of the donut. Then, halfway across, it would flip the donut over so as to cook the other side. Once cooked, another conveyer belt would lift the donut up and out of the hot oil and into a rotating dish for the donuts to cool. They were picked up, sugared and packed into a paper bag for human consumption.
Occasionally, something would go wrong, usually in the part that flips the donuts over, and the donuts would get all messed up. Seeing this one day, a revelation hit me. Why not do a game based on a donut factory where everything has gone wrong? And who should be the starring character of this "donut dilemma"? Why of course my father, Antoni!!
Yep! It's that part of the article again...
"Angry Angelo has raided Antonio's Donut Factory sending the entire complex amuck! Donuts have come alive and are jumping around in wild frenzies. Machines have gone out of control throwing cooking fat, dough and icing sugar everywhere. You must help poor Antonio climb ladders, jump platforms and ride elevators to reach the top floor and shut down the factory's power generator which will restore law and order. But hurry for time is running out!"
This story just smells of success don't you think?
As in all my games, all graphics were designed on TRS-80 grid paper. No animation utilities back then! All the levels were designed on this grid paper and then I wrote the code to recreate them. The basic graphic blocks would be drawn up and stored into memory using a short BASIC program that I wrote and the code would then transfer the graphics to the main screen. All graphics were double buffered. I would set aside an area of memory as a copy of the video display memory. Here I would draw up all the graphics for the next frame and when done, copy this page to the main display for viewing. This cycle would repeat itself for each frame. This provided a clean update of each frame without seeing any graphics being drawn up. One problem was the unsightly screen interference of the TRS-80. The TRS-80 could not display video while data was being written to the video memory, so when this happened, an ugly black "tear mark" would appear on the display. Unfortunately, the TRS-80 had no way to synchronise the video beam so that screen updates didn't occur while it was drawing the display, so all games suffered from this. This problem wasn't rectified until the TRS-80 Model IV.
Donut Dilemma Game Screen - Level 1
Donut Dilemma Game Screen - Level 9
Sound effects were all generated by my usual method of creating sound tables as I had done for Neutroid and The Gladiator. The way this was done was to write short BASIC programs that created the sound effect data that I wanted. The sound routine would simply read a byte from these tables and send it straight to the sound port (cassette port). In order to prevent the game from freezing while it played a sound effect, I made the routine only play a short number of bytes at a time and then return to the rest of the code. On its next pass, it would play the next block of bytes and return to the code. This would repeat until the entire sound table was played. In the meantime, another sound table could be triggered and the table pointer would shift to a new table. This didn't allow for two sounds to occur simultaneously, but it did ensure that when a new sound was to occur it happened on cue. There were no interrupts on the TRS-80 available to setup an interrupt driven sound routine, so this was the best I could do. By adjusting the number of bytes played on each pass through the sound tables, I could adjust it so that complex sound could occur without creating any animation stutter.
Donut Dilemma Screen - After All Nine Levels
Donut Dilemma was one of the few (maybe only?) games on the TRS-80 that played music in the background during play. The music wasn't great, but it was a feature I hadn't seen on any other TRS-80 game. Of course, we all know how annoying background music can be while playing a game so an option to disable the music but keep the standard sound effects was included.
If I could have marketed the game properly in the US via a big distributor like Adventure International or even Big Five Software, I believe it could have wiped the table in sales. But alas, I was just a small fry operating on a limited budget (nothing) far away from where the real action was, so again all my sales were restricted to club meetings and catalogue mailings to past customers. I felt that this game had so much potential that I put a small paid advertisement into a major computer magazine. This got me a few more sales and to date, Donut Dilemma was my best selling TRS-80 Model I game.
Escape Zone (1984, TRS-80 Model I)
Escape Zone Title Screen
Escape Zone was my first "shoot-em-up" style game. It was a style I had been avoiding up to this point, not because I didn't like this type of game, but because there were so many of these already written for the TRS-80. It seemed like the easiest genre to write for, and I had figured that another would not stand out among the crowd.
Escape Zone Instructions Screen
But what kept nagging me was the feeling that I could do something a bit different. I wanted a game with great firepower, big explosions and lots of sound, so I began Escape Zone.
With Escape Zone, I took elements from classic arcade games such as the firepower of Defender, the multiple stages of Scramble, the vertical scrolling of Street Racer (Atari 2600) and the swooping aliens of Galaxian.
Story pretext coming up! You've been warned...
"You have been held captive by the evil Dakors since they first captured your craft during a daring space raid. But the Dakors made a mistake of treating you just as any other human captive and so you manage to escape from confinement and have reached your escape craft. The Dakors are alerted to your escape and now there is no time to lose! Prepare to thrust your way out of the Dakors' command destroyer and into open space via a tight winding tunnel filled with deadly "Blipop" and "Bizzo" mines. Once in space, destroy the super-fast "Flipps", manoeuvre through the dangerous meteor shower and dodge your way past the "Reverso" crafts and "Putt-putt" missile ships into the safety of free space!"
"Blipop" and "Bizzo" mines? "Putt-putt" missile ships? This story line is so sad, it makes my skin crawl!
Escape Zone uses firing similar to arcade Defender. By that I mean that there is more than one laser blast at a time and instead of the fire being a bullet or "dot", it is a long laser line with a tail that decays as it moves away from your craft. Likewise, the game supports multiple explosions when enemy craft is hit, providing quite a nice fireworks display.
Escape Zone Game Screen - Zone 1
Another feature of the game is the demo or attract mode. If the game is left untouched at the game title screen, it will automatically move on to the instructions page and then start a demo game. During the demo game, I created the effect of multiple layers by having a static title graphic superimposed over the moving game graphics below--Sort of like a large "sprite" sitting there not being affected by the action behind it. It's no big deal, but I liked the effect.
Escape Zone Game Screen - Zone 3
Escape Zone was a reasonable seller, but I could see that the TRS-80 market was starting to decline. Looking in the American TRS-80 publications such as 80 Micro, the number of games being advertised was approaching zero, and I saw this as a sign that the games market for the TRS-80 was about to drop. By this time in 1984, high resolution color graphics were the norm, and it was only a matter of time before even the TRS-80 would be laid to rest.
Escape Zone Packaging
Therefore, Escape Zone was to be my last TRS-80 Model I game. I felt happy having created seven good quality TRS-80 games over the years. I was happy having done a nice variety of games from adventure to arcade, from top view to platform to vertical shoot-em-up. I had developed some great graphics and sound routines for the TRS-80, but it always bothered me that my target market was so small. I knew I had to set my sights higher and aim for a larger market.
I began looking towards the future and started on my quest for a new machine...
>> List articles in this category
<< Back to articles front page
This article has been rated: 8.0 - 2 votes
04 Nov : 13:35
From an e-mail from the author, Nickolas Marentes:
"Mathew Reed, the fellow who has created the TRS32 emulator has sent me an e-mail telling me that the problem with the incorrect timing at the title pages of my Model 1 games is not a fault of the emulator but has discovered that the TRS-80 ROM images available off the net have been patched to remove a ROM call that contains a delay routine that my games called. He said that he is putting out a fix in his next revision of TRS32 that will compensate for this."
05 Nov : 16:55
Registered: 16 Jan : 13:00
Awesome article! It had me on the "edge of my seat", as it were. I'm really looking forward to part 2.
05 Nov : 20:01
Registered: 05 Nov : 19:18
I had a similar epiphany when I did a simple bubblesort of the text screen memory on the CoCo in ASM. Seeing the letters smoothly reorder themselves, almost to quickly to follow, finishing in a second. I can remember thinking, "Wow, even a bubblesort in ASM is fast."
The 6809 was a really nice CPU, an 8 bit processor with _two_ 16 bit index registers, _two_ 16 bit stack pointers, and a hardware multiply. The CoCo (1) didn't have the greatest graphics modes, but they were easy to use. Both of these facts made it very difficult for me to get into ASM on the Apple ][, which used a 6502 (a true 8 bit CPU) and didn't have easy to use graphics.
06 Nov : 13:45
A very nice article! I never produced any commercial games but I does remind me of my own experiences with computers growing up as a kid. We had TRS80´s in our computer-classroom and boy did I fill up that 4K quickly. Our science lab had a c64, my parent´s got me one and I used to be the kid writing games/demos on the c64, msx and zx spectrum that were on display at our local V&D store.
And man, I just love those TRS-graphics!
06 Nov : 20:33
Reading this reminds me of the simplistic Q-BASIC games I would make in middle school! Unfortunately, I don't have the source code to those games with me, but one of them was a text adventure version of Dragon's Lair where you would have to type "UP", "DOWN", etc. at each prompt; only one choice was correct!
08 Nov : 16:06
Registered: 08 Nov : 15:44
Fascinating reading, especially for someone whose early teenage years all-but-revolved around the TRS-80 (sad isn't it!) Fun Division was certainly right up there with Big Five, Computer Shack & Funsoft in terms of reputation for quality games. Donut Dilemma was indeed one of the best games on the trash, and I had no idea until a year or so ago that it was written by a fellow Aussie! Well done Nick!
At the time I also fancied writing some commercial software for the trash, but never really believed that it could be done by a 'bedroom coder'. To learn back then that my favourite games were indeed written by 'kids' I think may have spurred me onto greater things. My crowning glory was to be a pixel-perfect port of Apple's 'Lode Runner' on the Model 4 with a Microlabs hires board - but alas the TRS-80 scene died altogether before I could finish it.
In between my father owning a Model I and myself owning a Model 4 (bought for my uni course) I also owned a CoCo - so can't wait for the next instalment...
08 Nov : 19:44
Registered: 05 Nov : 05:31
Teach me computer programming!!!!!!!!!!!
|You must be logged in to post comments on this site - please either log in or if you are not registered click here to signup