October Retrochallenge 1: Deep Scan

As with many of my programming projects I got my inspiration for Deep Scan via some retro video watching on Youtube. I was browsing game videos from the NEC PC6001. I like keeping track of stuff about the NEC PC because it uses the same neon green wonder of a video chip, the Motorola MC6847, as the MC-10 (and Coco, Dragon, VZ200, etc.). Retro Gamer Z posts a lot of play-through videos for the NEC PC. I've subscribed to his channel, so I see when he posts new things. He posted a video for a game called "Deep Scan."

It was in hires and has lots of wonderful sound (the NEC has a fancy sound chip). Most certainly it was written in machine language. However, I thought the concept would work quite well in Basic. I also felt that I could probably bring all my best tricks to bear on making the animation fast. The resulting game, also called Deep Scan in honour of its inspiration, is pretty fast, although I am under no illusions that it is M/L fast. I'm just happy to make it as fast as possible within the restrictions of Micro Color Basic.

The main action of the program takes place in a tight FOR/NEXT loop starting at line 20--the number I commonly use for the main loop in most of my programs. The most commonly called subroutines usually start at line 1. Line 0 usually dimensions all the variables and then jumps to the startup routines, such as displaying the instructions, which are all located at the end of the program. I use only single letter variables and as few of them as possible, which includes recycling variables for multiple functions if possible. I declare the most commonly used variables in the DIM statement first, since I have been told they are looked up by the basic interpreter from a list in order of declaration or first use (i.e. further down the list takes longer to look up). I use pre-calculated arrays to store the correlated set-reset x/y locations for all the possible screen locations that a sub might be at. That way I can use an array to store each sub's location and the x/y locations for its continuously firing torpedoes, but when I need to re-fire from its current location, I don't have to calculate the new x/y location for its specific screen position. The program just consults the pre-calculated x/y array locations for the current position.

When it comes to checking for the characters hit by the depth charge I use a 255 element array for all possible characters with numbers stored in them usable by ON/GOTO or ON/GOSUB commands. The commands can then act as a single check for multiple possible actions depending on an character occupying the location to which the depth charge will move next. The next location is searched simply by PEEKING the screen memory location of that position and then consulting the array using the number returned. So, the blue water character of 175 is left as zero, whereas the characters for the subs have 1s put in their array locations, and torpedo character has a 2. This way, an ON/GOSUB line#1,line#2 routine can be used to either simply allow the depth charge to continue falling (the 0 value defaults to jumping past the ON/GOSUB options) or the sub hit or torpedo hit routines (line#1,line#2).

I use the same array to store numbers for the various actions of key inputs. Since the program only uses A for left and S for right and the Space key for depth charge, I just need to store a 1, 2 or 3 in each of the array locations corresponding to the ASCII values of each of these keys. Then, one ON/GOSUBline#1,line#2,line#3 will handle what to do when any of these keys is pressed. One ON/GOSUB therefore can do the work of three IF statements, which speeds the program's execution and provides Basic with something like the functionality of a SWITCH statement used in higher level languages.

Other speed measures include having torpedoes only check for hits once they move above the dark blue water.  Otherwise they just keep moving up. In other words they don't interact with other subs, other torpedoes, or the player's depth charge. They just keep moving up to the level of the Cyan sky. Once there, a check is made if they hit clear sky (Cyan) or the ship (Black). Sky=have the sub fire another shot. Black=ship hit. I think in the original NEC game shots can be blocked by other subs, torpedoes or the depth charge. By simplifying the complexity of the interactions between virtual objects, limiting the objects to single SET/RESET pixels or characters (the torpedoes), or single line PRINT@ strings (the subs and ship), some reasonably speedy animation in Basic can be achieved. In other words compromises must be made between speed and complexity, but I think virtual worlds can be created in Basic that are complex enough for reasonably good game play.

That being said, I know my games will have a limited possible interest for people attuned to modern computer gaming. Perhaps they might appeal to a very small number who remember the simple Basic type- games of the early 1980s with great affection. Perhaps they might only appeal to me. Yet, when it comes to a hobby it doesn't matter how many other people share one's interest. It was certainly fun in and of itself, to spend a number of hours crafting a "type-in" style game.  And it certainly took a few hours, and multiple false starts at thinking I had finished.  First I had to refine the startup screen a little to make it a little more interesting than the rudimentary one I started with:

This version also had a few fixes. I had to play enough games to notice that sometimes the bonuses could be randomly plotted in locations to the extreme right that the sub couldn't reach it with its depth charge. I also tweaked the number of lives awarded from a random number of 1 or 2, to just being 2. The game was tough enough that giving 2 lives if you survived 3 screens (when the bonuses appear) seemed reasonable, and more fair than a random number. Such fine-tuning can only come from playing the game a lot. I also eliminated a fourth size of ship, which I found too hard to play. You want to avoid unfairness and arbitrary death as much as possible, which can be tough to achieve in Basic games (or impossible, at least according to my Xbox jaded son).

My last major fix was that I noticed that I had a completely unnecessary array. I had a whole array for all the possible screen locations for the subs. Then I had an array which held a number that I incremented or decremented to point to that array. Stupid. I don't remember the rationale, but I just needed to store the actual screen locations for each sub and increment or decrement that, not a pointer to an array with  screen locations. It just goes to show that you never know whether you have fully streamlined a program. Continuous play and reexamination of the code can turn up efficiency improvements even after you think you've done everything possible. Most people will probably find it difficult to discern any substantial difference in speed between the various versions, But such subtle and obscure perfections are what hobbyists live for....

If you try the game try please let me know what you think (unless you are my son Charlie--XBox has ruined you boy, at least for the purposes of Basic Beta testing:). And any suggestions for game improvements or new features would certainly be welcome.  My next Retrochallenge post will be about two other programs I worked on earlier in October, Fur Trader and a graphics demo from the Sinclair ZX81.