Summer time is here, and while a lot of people are enjoying themselves doing some form of outdoor activity, I’m ramping up progress on Cosmic Aliens. We’re now in July, and my plan, is to have a playable demo of the Color Computer version of the game to be shown off first, at VCF Midwest, in September, and then, hopefully again at Tandy Assembly in November. So I’ve got about 2 months to make this thing playable.
Over the past weekend, a lot of break through moments happened. First, in an attempt to make the game look less sluggish, I’ve made some design decisions on how objects will be placed and moved on the screen. Every object is 16*16 pixels, and based on the CoCo maximum resolution of 256*192 that breaks down to a 16*12 grid of objects. So, when I move an object, it will always move up/down/left/right by 16 pixels, to the next “square” in the “grid”. Imagine I’ve broken the computer screen up like a checker board. An object can occupy any square on the checker board, and move to any other square. It will move from one square to the next as a full “jump” to that square, it will not slide, or glide to that square. At the expense of looking “smooth” I’ve achieved the illusion of speed.
The next thing I did, which was an important step in video games, is to implement collision detection. This is the ability to know when one object comes in contact with another. Doing this in BASIC, and the color computer, everything needs to be done in software, and by keeping track of variety of variables. A lot of other 8-bit systems of the time had objects known as “sprites” which had many advantages. A true hardware-based sprite has the benefit of exiting on a foreground plane that does not erase the background, and you have the ability to know when a sprite “touched” another sprite or object.
The whole concept of sprites needs to be done in software on the CoCo. The wizards of assembly language games do this so well, you might not even notice the sprites aren’t “real” but in BASIC, to pull off this effect takes a demanding toll on speed and performance in your game.
I’m doing a lot of “Behind the scenes” work erasing old objects and updating them on the screen, and to avoid any “flicker” by doing this, I’m having to use a page flipping technique. The fact I have to erase, and then reproduce each object on a different screen, and then copy that entire screen to the “foreground” take a hit on speed.
Collision detection can be done a variety of ways, one way it to check for the presence of a particular color. In a traditional game with a black background, any color on screen that isn’t black can be detected pretty easily, however, now that you’ve detected the color, how do you know “what” you’ve detected. I’ve used color detection in the past for some of the simple game I made as a kid, but that wouldn’t work well here.
I’m using X/Y coordinates of the various objects stored in memory and then comparing those coordinates against other objects to see if they are in the same spot. I’ve arranged things to where every object will always have an X/Y axis that is a multiple of 16 (the square on a checker board) so, it’s fairly easy to know when two objects are in the same square.
Now that I have collision detection enabled, I can determine if my ship has been hit, which reduces one of my “lives”, and I can tell if I’ve hit a falling bomb, or an alien. I will award points based on what I hit, and update the score, on-screen, using the fonts routine I re-wrote for this game.
Earlier versions of the game showed the graphics being loaded onto the screen. Now that the game is progressing, I wanted a “fancier” title screen. I’ve used the SG-Edit utility by Simon Jonnasen to create the graphics for an intro screen, and you get to stare at that for a minute while the graphics are loaded onto screen, and then copied into memory.
Since the program is entering into the area of “playable” I decided to record the first ever “official” YouTube video of the current state of the game which you can see here: