Iterating fairly well
My biggest victory came from iterating, even if I could have approached it more intelligently.
After working out some ideas on paper, I had a basic design for a shooter.
I wanted the controls to be simple. I came up with some different ways for how enemies would evolve, as well as ways the player’s tank might evolve.
I wanted different kinds of enemies that came in different sizes, used different movement patterns, and attacked the player in different ways. I even had an idea for a boss character.
I also thought of Evolutionary Upgrades, aka Power-ups, for the player. Some impacted the tank’s weaponry, such as a spread gun or homing missiles, while others affected the tank’s size or armor.
Once I had an idea of the kind of game I wanted, I set to work. My initial list of tasks:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
First, I got a scrolling background. In hindsight, maybe this part could have been left until later. My next goal was to get a controllable tank on the screen, complete with the ability to fire bullets. Having something controllable that early meant that throughout the development of the rest of the game, I could get a feel for the controls. As the game came together, the tank’s controls were updated a few times. I originally had the tank’s movement a bit slow to accelerate, as switching a tank’s directions is probably really hard, but I found it was more annoying than fun. It felt too sluggish. I made it more responsive in the end, and it was better for it.
Next, I added boulders, followed up with collision detection between the tank and boulders. Now tanks have to avoid obstacles, making the side-scrolling environment a bit more maze-like. In terms of the theme, however, perhaps these obstacles were not the best thing to add earlier, although I did have plans for enemies to interact with boulders by pushing them toward the player if they collided with them.
Finally, I added killable enemies. The enemy was pretty basic. It moved in a straight line toward the player, didn’t attack, and moved through boulders.
I realized that I was not going to get all of the enemy types and upgrades in, so I focused on making sure what I had was as finished as I could make it. I added enemy waves, which added more enemies and made them harder to kill as the player progressed. I added a score so you could see how well you’re doing, and I even had time to make some points visibly pop up when you kill an enemy. That last bit was a small aesthetic change, but I think it polished the game up quite nicely. Great bang for buck.
Now, there are some things I spent time on that I could probably have left until later. The scrolling background wasn’t really necessary, was it? And the enemies were supposed to be the main focus of the design, so why did I work on boulders first? I definitely could have prioritized much better.
Still, what’s key here is what I didn’t spend time on. I didn’t spend time making tank upgrades, which is good because I didn’t have a need to upgrade the tank. I didn’t spend time making lots of enemy types, which is good because I didn’t have the time to intelligently figure out how they should be introduced. I didn’t spend time to figure out boulder/entity interaction, which is good because who knows if it would have added anything?
By getting something playable and iterating, I was in a position to reduce scope to finish the game by deadline. Along the way, I almost always had something playable that I could submit by the deadline.
