I am often struck by the similarity between the activities of game playing and game creation. In both cases, there is generally a long sequence of problems to be solved with an eventual goal in mind. These problems can have complex dependencies, and finding a good solution can make the difference between reaching the goal and starting over. As I have previously noted, I actually gain more enjoyment from creating games than I do from playing them. According to some friends of mine in the games industry, this is not uncommon. Many of them suck at playing games, though they are experts at creating them
With this in mind, I have made some further progress on my Juno First project. To get this far, I have solved a very long sequence of problems, many of which I didn't think would be possible. Nonetheless, there remain many more problems that will have to be addressed if the game is to be completed. As time progresses, these problems are getting harder to solve as available resources on the Atari are diminished. The main changes to the game this time are:
- The aliens now move around the screen. They all use the same basic movement pattern at the moment, but I think this looks very cool!
- The game has now been expanded to an 8K ROM which has thankfully relieved many of the memory pressures. I eventually adopted the scheme that supercat posted last time (thanks!). I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2).
- The explosion sprites have been altered and there is now a flame effect when the spaceship moves forward and backwards. Also, the spaceship will explode and then reappear if you collide with an alien. I am very grateful to Nathan for all of his help with this.
There are still a few remaining issues in the code. In particular, the spaceship will explode if an alien hits the flame. This is because I am using harware collision between the aliens and spaceship. I think I will need to move to a software region-checking approach, but this is going to take a lot of cycles. If anyone has an efficient techniqe for checking if a moving sprite enters a fixed region then I would be very grateful. The next step is to go through the code carefully to spot possible optimisations as there are now very few cycles remaining anywhere.