The Idea:
When ‘Escape’ was announced as the theme I was stuck for ideas. I had my heart set on the theme being ‘Evolution’ and it was hard to shake my ideas relating to that theme. To fit ‘Escape’ I decided I wanted to do a side scrolling game but I felt that it needed a twist to keep it interesting and differentiate it from being an “Advancing Wall of Doom” game.
I ended up settling on what is essentially a cross between BIT.TRIP RUNNER and HammerFight. The general idea being that in order to succeed the player needed to be able to focus on two mechanics at the same time: dodging randomly placed hazards and using a physics-based attack to fight off bad-dudes:
Visual representation!
The Art:
After coming up with the idea I then set about contriving a situation for the setting of the game and drawing the main screen. In retrospect drawing the main screen first thing was not a good idea, it was time consuming and considering the time restraints was a bit of a waste.
As I wanted multiple endings depending on how well the player did this was not the last time I ended up making this mistake. Drawing separate screens for winning and losing was far more time consuming than I had anticipated and the actual gameplay sprites suffered as a result.
The bouts of drawing were a welcome break from coding though and I did enjoy putting references to things in these images:
Not very subtle!
The Coding + Design:
Implementing the basic systems such as the running and jumping was relatively easy, I did get a bit carried away with the boomerang sword though. The sword did teach me a lot about how game physics can work though and previously I hadn’t experimented with anything similar in my other projects.
Code-wise I regret not using abstract classes and deriving level objects from them. I spent a considerable amount of time re-writing functions and properties for each object I could have used to polish the game. This also made the source quite hard to understand and make changes to.
With only about an hour left I was frantically trying to find out why quitting was sometimes throwing an exception. Turns out I had a game-breaking bug that involved the game not disposing of game content properly. Luckily I had set aside some time before submission to find these sorts of bugs.
One of the main things that I wish I’d gotten into the game was a proper sense of speed. The way the background scrolls and the obstacle speed is far too slow as many have pointed out. I considered changing it towards the end but it was a bit of a nightmare just trying to get all the mechanics balanced, trying to change the speed would have meant changing a lot of elements. It seemed like a better idea to have a game that is more fun to play than one that seemed speedier.
Things I learned:
- Don’t get too attached to your initial ideas.
- Know the scope of your game.
- Prioritise gameplay over art.
- Have base classes.
- Always reserve some time for balancing, play-testing and bug-fixing.
