For November, I found another missile defense game that I wrote a few years back. I honestly didn’t remember this one until I started to play it. Starting off a bit slow, I kept telling myself that it should speed up. And, it did! Guess, my memory isn’t that bad after all. Let’s dig into Laser Catch a bit more.
The build up.
The premise of Laser Catch is quite simple. Move your cursor using the arrow keys over each of the missiles depending on your city to stop them. If you stop them all, a new wave begins. If you don’t, it counts as a miss and you get another chance. Miss too many the missiles destroy the city.
The catch is the game starts off pretty slow, allowing you to move several times before the missiles do. With each successful wave, the missiles get a bit faster. In the end, they are moving pretty quick and it becomes harder to get all four before they crash into your city.
These kind of games can be quite fun. Ramping up difficulty allows you time to learn the mechanics and devices strategies. Where Laser Catch fails is that the game gets pretty repetitive. If the missiles get placed far enough apart, it’s impossible to catch them all at the later levels. It’s not bad, but could be better.
What’s with that name?
The oddest part of the game is the name. I mean, those can’t be lasers coming down as they are too slow. And what would you catch them with? In a way, your cursor could be the laser, “catching” the missiles. That’s a bit of a stretch though. I should have chosen a better name, but Missle Defense was already taken by my earlier game. I should have called it Laser Defense.
To be fair, this game plays more like the original Missile Command. You have a cursor this time and can chase four missiles over the screen. Although I don’t have the cool explosions, the look and feel of Laser Catch is encouraging.
Needing some refinement.
As written, the game is designed well. A pretty straight forward program, the code is simple and uncomplicated. I used standard coding practices, much like the other programs I’d written. Plain and workable, it could still use some work.
For one, the game is a bit jerky when the missiles move. This has more to do with how I understood the ZX81 to work, and less with the code itself. I used two loops, one to move the missiles and one to allow you to move. This dual loop is what causes the perceived jerk as the missiles move. A better solution would have been to use a single loop.
I did this in another program, using a
STEP statement with a fraction. The problem, though, is that the movement code would have been sluggish. This would remove the jerk but would slow everything down.
To fix that, I would need to optimize the printing routines. The problem is I have to test four different missiles. On top of that, I would need to make sure not overwrite the misseles and cause flashing. Both of which would have slowed the system down even more. In all, the routine as written would need some serious reworking.
Some obvious optimizations would be to move printing the city outside of the loop. It is only printed once, so moving out would remove a small amount of delay. I found a couple of other examples like this, such as printing your cursor.
Also, there are eight boolean checks each time the program moves the missles. That is harder to remove. The way the loop works, it speeds things up by not having to calculate the missile’s position. I'd have to try out a few different strategies to see if I could reduce the repetition. I’ve used a couple of different variations on this in the past, but none are perfect.
Putting some time into these optimizations could improve speed. But, an even better idea would be to use Mcoder to turn the BASIC code into faster assembly. It would need a few modifications, but the code is pretty close as is.
Improving the game.
Although the basics are good, the gameplay does need some work. For one, the missiles would be more interesting if they were moving diagonal. This would fix a couple of issues. For one, the game would be more interesting to play. It would help in the situation where two missiles are at opposite ends of the screen. As long as they were moving towards center, you might still be able to catch them.
The only problem would be any overlap in the missile trails. The program deals with this in the current game by making sure they don’t start in the same position. But if they crisscross, it could cause some minor problems with the way the current game checks for a hit.
Some simple enhancements.
An easy fix that would also look nice would to explode the missiles when you run over them. Right now, they disappear. It works, but a visual queue would be more interesting. Adding a little explosion and smoke would be cool too. But, it might slow down the game too much. Again, Mcoder could come to the rescue here. Or, I could write the darn thing in assembly.
Another easy enhancement would be to remove the misses and instead use a visual queue. One thought is to use cities on the skyline and remove them as you miss. As an alternative, I could destroy the cities if a missile hits it. In this way, you could allow missiles to miss if it wasn’t hitting a city.
I still like Laser Catch. It is fun and challenging as is. A name change and some graphic improvements would make it even more interesting. An effort for another day.