Buried Blitz postmortem

Now that Buried Blitz has been released on Yoyo Games and Game Jolt, I figured now would be a good time to release a postmortem concerning the game’s development.

In the middle of July, I began work on Buried Blitz after cancelling another project due to time constraints. The process took roughly around three and a half months of work and was finally released on Halloween night. While it took less creation time than the previous two games, Moody and Meteor Malice, its creation was small feat. Through development, the basic concept changed from completely vertical dodge and climb game to actually having a sprawling level with many horizontal and vertical twists and turns to the final exit. The final project was the end result of constant testing and a desire to not condemn the project to developmental hell.

What Went Right:

1. Easy to use engine

The Game Maker engine is actually one of the easiest engines to use for independent game creation. The fact that I have already used this same engine to create games in the past made it even easier. The drag and drop interface for quick scripting and level creation allowed what would have been weeks or months of coding to be finished in hours or days. While the engine does not get the best reputation as a professional engine, the easy to use interface and variables make the creation of rapid prototypes quick and painless with less high level scripting than many creations made with Flash or Java.

2. Simple sprites and animations

Art is a touchy subject when you think of terms in with animation. While the Mona Lisa is a well done painting, fully animating it and having it move around would be difficult, time consuming, and may end up looking awkward. To combat this, I decided to use super-deformed characters with large simple heads and small bodies with little detail. This technique is not new as such methods were used in the creation of the Power Puff Girls. By going a more cartoon route, I was able to make the animations simple and easily read while avoiding the issues of the uncanny valley.

3. Simple concept

A few years ago, I tried playing a card game involving a single token placed in the middle, five different card types with little direction on when they should be played, a changing order of play and direction as the game progressed, and a bunch of other game features that would take up at least for pages to explain. Needless to say, I felt lost, confused, and quit out of frustration. If you take a look at Blackjack, the rules are to get close to twenty one without going over. My whole idea with game design is simplicity and consistency. If the player knows what to do with minimal instructions, the game will be easier to play and reach a wider audience. By focusing on making the game solely about dodging falling blocks and progressing to the next room, there was very little to make the player feel lost or overwhelmed.

What Went Wrong:

1. Sound issues

The final week focused on sound, which was not the best plan. The fact that I traded off sound editing software in the middle did not help out either. Up until five hours prior to upload, the different sampling and compression rates seemed to confuse the engine and caused the background music to become suddenly mute. Massive amounts of recompression had to be added to the stage sounds to work around this issue. The main reason for the software change had to do with the music size after looping the sounds and converting them into .wav files. It was also why the game is only 24 MB and not around 90 MB.

2. Development during the summer

Summer is classically the time when people go on vacations and events. This led to the consequences of a few unexpected risks in dealing with funerals and family vacations. Luckily this was only isolated to August, but the end result was that I lost over two weeks of development time. The major lesson there was that life does not fit in with self imposed deadlines.

3. Graphical cuts and issues

One of the earliest decisions I made was to forego the use of a health bar in favor of having damage and status being exhibited by how the player character looks. This ended up tripling the number of sprites. To reduce the development time half of the animation states were cut including slight angles when jumping and falling while moving left or right. Some of the largest graphic flaws did not exhibit themselves until the point of no return in the development cycle. While many of them were fixed, certain weak decisions such as the asymmetrical arm failing were swept under radar. The lessons learned from this were to explore the use of health bars, create sprite masks for defining movement at least, and work on less misleading animation loops.

Conclusion:

Despite the struggles, lost time, and compromises, I am happy with the game and its response online. I learned even more about theoretical game design than with previous projects and found various ways to apply such ideas in future projects. For my next project, Magma Girl, I hoping to create an even greater gaming experience. As I will be concentrating more of my time on job hunting and web design, the development will have a much slower pace. Visit again next Saturday as I post more details.