It’s been a long time since I’ve posted a Retrochallenge update, and I do have a reasonable explanation for this lack of posts. My silly little GW-BASIC program to move the copyright symbol around the Rainbow’s screen seemed like a good start to a game of some sort. I next added the ability to shoot, basically drawing dashes and pipes when the player hit the space bar.
Adding the shooting reminded me of one of the Rainbow’s little oddities. When you hold a key down on the Rainbow, it registers the press once. Then, if the key is still down after 500ms or so, the Rainbow registers this and handles multiple keystrokes. This generally makes sense, but it makes writing a game brutal. There are ways around the behavior; however, it can be disabled (easily) in GW-BASIC.
Imagine you want to move left fast on the screen. If you hold the key down, you’ll move left one space, then pause for half a second, and finally continue moving. If someone is chasing you or shooting at you on the screen, the situation is not ideal. Additionally, I did choose to use the ON KEY(x) GOSUB y construct in GW-BASIC. This configuration launches GW-BASIC into subroutine any time the specified key is pressed. My old-time game I wrote as a youngster suffered some serious issues from this construct, mostly because you have to go disabling the key handling before performing collision detection, screen updates, NPC updates, etc. Otherwise, you can end up skipping right out of collision detection and walk through walls. On my “tech demo” here, it meant that, if I held down an arrow, I could move all the way across the screen without the shot I had fired ever moving a single character position.
Barring those issues, I decided to proceed with adding an enemy to shoot at. I added a small plus (+) sign that would chase you around the screen in a random fashion. Some simple collision detection would detect if you a) shot the enemy or b) were killed by the enemy. This addition actually worked great!
The whole “one enemy” on the screen thing made for an exceptionally boring game. I thought that maybe a Berzerk clone would be fun and possible to play. The next step was to add multiple enemies into the game. I started with a reasonable 8 enemies even though I toyed with the idea of 100 or so to make it a zombie-style game. However, even 8 enemies put an unbelievable strain on the system. Many of the keystrokes were simply lost as the enemies were slowly and visibly updated on the screen during the unresponsive update period. It was completely unusable.
I did perform some optimizations to get around unnecessary collision and border checks, which produced a maybe 30% improvement in performance. However, the Rainbow’s implementation of GW-BASIC is just too damn slow to run a Berzerk clone.
I’m now faced with a quandary. I can proceed with some further GW-BASIC programming, or I could try to see if a Berzerk-style game would work better written in C. I’m not sure yet, but I’ll consider my options.