I recently sat down and decided to look over the code I’d written for Invaders from Mars. Sure enough there were a great many lessons learnt and a good many things that, given the time to revisit, I would do quite differently.
Last week I took a break from work and found myself without the internet and any external distractions so I set to the task of revising my code.
Initially nothing much changed. I designed a simple naming convention for variables and began overhauling the base sprite “class” that I had written way back for Invaders. Before long I realised the potential for improving my code in terms of the amount of information I stored within each sprite object. Previously I had defined global arrays to handle image data. This time I lumped all image data for sprites within the object itself. It just made more sense.
Something that I’d hated with Invaders was the way that I interjected game specific code in to what ought to have been a generic set of routines. It got ugly but because I had come so far I was loath to go pulling the engine apart for the sake of changing my coding style. This time I could do just what I wanted since I was starting with a blank canvas.
So I defined the core game code to operate independently of the code required for the actual game (or gameplay as most kids call it).
What emerged was a clear distinction between gamemodes. By adjusting nGameMode I could control which aspect of the game I was dealing with and then call out to an external component to handle such things as alien behaviour, environmental motion etc. The beauty of this is that when I come to design another game in the future the core handling of collision, “READY”, “GAME OVER”, scores etc is already in place and I merely work on the external components. And so it dawns on me that a templated approach to my work is the right way to go. This is not a library since I don’t use code that way. It is merely a pre-defined template that I can pick up off the shelf and start coding with for a new project.
I defined 3 presets for my templates based on the only 3 types of game I will ever create: ASTEROIDS, INVADERS and RTYPE. In each state the code knows how to handle the positioning of the player object and the firing of player missiles. Asteroids is the free-roaming , multi directional firing whilst R-Type and Space Invaders were fixed with single direction firing. (R-Type basically shot from left to right if you discount the add ons to the craft).
After a couple of days I was happy that the template handled everything. I could literally take it off the shelf and begin coding a new game safe in the knowledge that all my title screen, scoring, collision, player handling and movement, game over states etc were taken care of. So I knocked up a quick test and called it Super Copter. Originally I had wanted to design a Defender style game but I didn’t want to get tied down with the 2-way motion and radar handling. I wanted something a lot simpler that I could build upon. I’d always loved Jeff Minter’s games of old so I had no hesitation in hijacking his Attack of the Mutant Camels style for the game.
You can view the game at this link: http://www.rebelideas.co.uk/proto/supercopter/
In actual fact there is no game. But you get a feel for it. There are also a number of things to iron out, namely collision. But you should get a feel for what I’m aiming for in my games. Arrows move the copter and Z fires the missiles.
The scrolling doesn’t come as part of the template rather it is a simple definition of 2 sprites that simply wrap. By default I designed the sprite to be about 4 times the width of the playing screen to avoid the Scooby Doo effect !
There’s a ton more I need to write about with this code and I am still avoiding the “Canvas” route. I want to get as much out of this “old school” approach before I move on. Besides canvas isn’t widely supported just now. But that will change and when it does I will move on.