Crashblock Postmortem

Introduction

Every year, for the several years, the Pascal Game Development forum held a game development competition and each year Real Life played nasty tricks on me - meaning that I had no time to dedicate to join in the fun. 

One year was different. I made time available and after playing some of the resulting games from the previous years' entrants, I was determined to put as much effort into the game as possible to at the very least, achieve the same standard as the example which had been set before me.

The competition's theme when I built Crashblock was Multiplexity; in other words, the melding of seemingly incompatible genres to make a single coherent game which should feel as thought those genre's should have always been together and challenge the idea that they were incompatible in the first place. A tough one. What would make things tougher was the quality of some of the ideas being thrown around, I really would have my work cut out for me if I was to make an impression.

The Idea

Coming up with an idea, a good idea should have been the hardest part.. I've read quite a few books on gameplay, balance and planning and I might have spent a while considering my target audience, then formulating an idea and planning it in great detail, perhaps some sketches, a prototype and maybe a focus group, if I'd followed some of the advice I'd been given. Instead, I plucked one out of thin air and wrote it down in as much detail as I could, still not sure how I would meld the two genres together. Well, when I say plucked out of the air, I really mean... I'd been playing Another World, Flashback and Blackthorne a short time before the competition started and I really liked how those games moved. They used rotoscoped animation to create really lifelike animation. The amount of detail in the animation added a lot to the games, there's just something about how people move which is very hard to capture using traditional animation techniques. Especially at my level.

I wanted to do something similar. I knew how much work was involved making rotoscoped animation, so I considered using live action instead. It would turn out that I would need a combination of both live action and rotoscoping. For the puzzle aspect, I thought Tetris would be an easy game to implement. The rules for Tetris are incredibly simple and I'd written a game programming tutorial based on the popular game in the past so I knew what I was doing. In fact, the code from the VB tutorial would provide valuable time savings later on.

Refining the Idea

The starting whistle blew for the competition and along with the other teams, I set to work. The PGD competition had a rigid deadline structure with goals to be accomplished in a timely manner. Missed goals meant missed points, so it was important to score highly in as many of the goals as possible.

The first goal was writing the design document. This was the first time after announcing to the world that I was writing a game based on Tetris and Flashback that I really started to think about how this game would fit together. The question kept buzzing through my head about How someone could play a flashback styled 2D game within the bounds of a Tetris game?.. this was the toughest nut to crack initially and it had to be cracked correctly otherwise the game would not play properly, at the worst case it would feel like two incompatible genres bolted together with some string and sticky backed plastic.

In the end, after a lot of thought, I settled on the idea that the player would control the an avatar who would in turn call a crane holding the current block, which was attached by a weak chain which would eventually snap and the block would fall. This last feature meant that the difficulty could be increased fairly easily by reducing the amount of time the player would have to get the next block into position. The player would scramble and climb over the fallen Tetris blocks and would need reactions and planning to survive. It soon became apparent that the player's avatar would need a substantial amount of moves to be able to get from one side of the Tetris arena to the other but to keep it accessible to everyone, the controls had to be kept simple, using as few keys as possible.

Adding to the Idea

Just running around and positioning blocks was going to be boring and wouldn't add much to the platform game experience. Platform games are about collecting things and avoiding hazards, not just jumping onto blocks for the sake of it. So there had to be things which needed to be picked up or avoided. At this point, the idea still wasn't mature. For instance, I still had no idea how the player would complete a level.. would they complete X number of lines? Or did the player have to reach a certain height to escape from the arena via a door or some other device? I decided that the first idea was too much like the original Tetris and didn't include enough platform elements and the second idea was too much like a platform game and had little to do with the Tetris game, especially since the idea behind Tetris is to keep the number of rows at the bottom as small as possible. In the end, I came up with the idea of collecting stars. These stars would be released from blocks as the rows were completed. This seemed to work well and added just the right amount of balance between planning the next position and scrambling to get the stars.

The other aspect which needed to be thought about was that of the player's avatar and her frailty. The most important part of the platform game for me was that the player should ot become overly frustrated or powerless, they should never feel that an action on their part should get them stuck or killed. The player would always be able to choose whether to venture into an area which may trap them and they would have tools to help them to escape in most circumstances, that was the plan anyway. As it turned out, keeping the player from getting themselves stuck was harder than initially planned. Imagining the possible scenarios where the player could trap themselves and working out animations to help them to get out of it while keeping the controls simple was quite a tough process. So in the end, I covered the basics and added a couple of special moves which the player could find for themselves. They would also be able climb up the walls and to collect bombs, which were previously a hazard, and use them to carve holes in the fallen blocks to get them out of trouble. Failing that, they could forfeit a life and be placed at the top of the arena once more.

The Hazards

When coming up with a list of hazards, it was obvious that I had a limited playing field in which to place them. The simple controls system reduced the options for avoiding some hazards, so ideas like Spikes coming out of blocks and walls and Monsters were dropped. I did have an idea where monsters would be trapped within cages in blocks which would be released once the row was completed. But after extensive play testing it became obvious that some monsters would be either too powerful or useless, meaning that the player would become trapped with nowhere to go and no way of dealing with the monster waiting on the block below them or the monster would become an annoyance and wouldn't add anything positive to the game. So I removed the idea. Monsters may make a comeback in later editions of Crashblock, but as a delaying object, grabbing hold of the avatar's legs as they run over the monster cage, but on the removal of the line, the monster would be destroyed. This is not yet in the game and careful testing will be done to ensure that the gameplay balance is maintained.

The bomb hazard needed to be dangerous and exciting at the same time. While they are easy to avoid, I wanted to give the player an incentive for attempting to collect a bomb which had already primed. So I opted to give a score bonus if the bomb was collected with just seconds to spare as opposed to the small score increase if a mundane bomb is collected.

The bombs would also have the ability to set off chain reactions. Where a bomb explodes and removes a bomb block from play, that bomb is released and will prime and eventually explode. This situation can carve massive holes in a carefully constructed block pile.

The Bonuses

The player needed things to collect. Stars complete a level but the real scoring is done with the fruit and coins, especially when the items were thrown out of a bonus block with a x2 or x3 bonus on them. Originally, I had planned on making the x2 and x3 bonuses much more critical to the game-play, where if the player managed to line up 4 of the same bonus in a row, they would receive a massive bonus. But I decided against this as the player really only sees the ghosted image of the current block and would rarely use the camera move function to see the alignment of the blocks. So the x2 and x3 bonus blocks simply multiply the score of the items they throw out.

Originally, I planned to not include a high score table. But after watching other people play the game, I noticed that they weren't collecting the scoring items. When I asked why, they replied, There's no point if the score is not saved. A valid point. So in the post competition version, I included a high score table. You can learn a lot about the game you're writing just by watching people play it.

I also noticed that people were not completing multiple lines, this was a major part of the Tetris experience. Clearing 4 lines at once would net the player a large bonus. So I decided to implement this feature in the form of Diamonds. When the player clears 2,3 or 4 lines at the same time, a diamond will fall. This diamond will have a different score attached to it for the number of rows cleared. The diamond will also require collecting for the score to be applied. This would add an additional level of planning and decision making on the part of the player.. should they go for the diamond or the last star to complete the level?.

As the levels get more difficult, the player was going to need to be able to rest for a while or get some extra time to climb up a large block pile to get to the other side of the arena. So I introduced Time-Outs. These devices stop time for the chain, ensuring that it will not snap while the Time-out is in effect. The Time-Outs would be retained between levels (unlike the collection of bombs which are cleared at the start of each level) this was to give the player the choice of wasting a timeout early on or save it until they really need it. Time-outs would be available for collection after a number of points had been collected, as would extra lives.

When is it Game Over?

In Tetris, it is when the blocks pile to the top of the screen. In a platform game, it is when you run out of lives. I wanted to preserve the feeling of intense panic as the blocks reached the top of the arena and I didn't want the player to have the option to reset the blocks by allowing them to reach the top, only to lose a life. That's not what Tetris was all about. So I settled on a dual system. If the blocks reach the top of the arena, It's game over. It the player runs out of lives, It's game over. The player can forfeit a life to get out of traps, but not to put right bad planning, the player would have to use their intelligence to do that. I believe this added just the right amount of panic to the game. It starts out very relaxed, there's no real danger. But later on, when the chain only lasts a few seconds and bombs are fizzing away, and the blocks are nearing the top, there is a lot of panic.

The Music

In previous games I've either written the music myself, or charged my brother with the task. For this game, Time was of the essence and I did not have time to write the music myself. I also did not have time to direct my brother and go through the lengthy music development process. Luckily, I found an artist whilst surfing AcidPlanet, William Christiansen from Symphonic Chronicles. I felt that his music would suit the game perfectly, so I approached him to get permission to use his work in the game. Amazingly, William was delighted to help and gave permission for me to use his work, providing me with a rich soundtrack to build upon. If he had said No, I fear the game would have a completely different atmosphere to it and would not have been as successful as it was.

Creating the Graphics

Crashblock's graphics were created using a combination of 2D drawings and Live action animation. The menus, the levels and all incidental graphics were created using the Xara Xtreme tool, a product I've used and raved about for many years. The job was made much easier with it's ability to use Photoshop plug-ins which meant that I could make some really nice effects. The live action was recorded in our local park using a digital video camera, tripod and tape measure. Getting my Wife to perform various actions for the camera and videoing the results. These actions involved climbing onto rubbish bins, jumping off, running, leaping, falling and even crawling along the ground. Recording the video attracted a lot of attention including that of a group of teenagers who seemed disappointed after asking us about the game that it wouldn't be on the X-Box. I reassured them that it would be downloadable for the PC, but they just rode off on their bikes. It was when transferring the graphics from video to stills that I encountered my first problem. The images contained a very real park in the background. So I would have to spend quite some time cutting around the images in Xara to make the individual frames. This job turned out to be the very definition of a pain. Still, without blue-screen technology immediately available, there wasn't much else I could do. Several days passed, animations were made.

What went wrong

There were numerous things which could have gone better. For one, moving house whilst writing the game didn't help. For another, being made redundant from my day job didn't help either, neither did the stress of finding alternative employment. Luckily, most of the work on Crashblock had been completed by then.

By far the hardest part and without a doubt, the most time consuming part of the development process, and the one part which made me contemplate throwing in the towel, dowsing my PC with gasoline and setting it on fire in a ditch in the garden was the state machine. Crashblock uses a state machine which chooses the most appropriate next state based on the current state, the player's input and the blocks around the avatar. What appeared from the beginning to be a relatively simple task dragged on for days and days, seemingly without an end in sight. Just when I thought I had everything working properly, the Avatar would disappear off the side of the screen, or get stuck. What made it worse was that the state machine used data to determine the next animation and was not a hard coded process. This made debugging much more difficult and meant that I became very close friends with conditional break points. After several days of hard graft, I had something which resembled the final state machine. Once the bugs were isolated and neutralised, other bugs could be tackled. It was a part of my life I would not forget in a hurry.

Originally for the live action component, my plan was to use a blue-screen system. My wife was at university at the time and there was a chance that I would have the opportunity to use the facilities to record the video. This would mean that I would have to erase the background using Gimp or Photoshop, but it would be far quicker than cutting out the backgrounds by hand. In the end, this opportunity never materialised and I ended up having to cut out the frames by hand.

If I ever do anything like this in the future, I will build a bluescreen rig myself as cutting out the frames by hand kills the flexibility let alone the tendons. I did want to re-shoot the running animation, but when faced with the prospect of cutting out the backgrounds, I decided against it and kept the old animations.

What went Right

Pretty much everything else went according to plan. I was using an engine I had written a few years before so I knew the framework well, I managed to get a working Tetris game for the 2nd competition deadline, complete with the graphics I would go on to use for the 1st 4 levels of the final game. The Xara Plugins helped a lot, taking away the tedium of creating detailed graphics from scratch and allowing me to get on with other tasks and keeping a consistent look and feel to the graphics, which can be more important than having some fantastic graphics and some poor graphics.. if all of the graphics are of the same quality, they stick out less and don't detract as much from everything else. On the other hand, if all of the graphics are fantastic or rubbish, they will add or detract from the game on their own. But that was obvious.

I had a lot less feature creep in Crashblock than on other projects. This was probably to do with the deadlines and the fact that we each had to create a living design document, it was a good tool to rein in the creative side. It is very tempting to add feature after feature without fully thinking things through. With Crashblock, I knew that it would fail if I made it too complicated. I also knew that I didn't have a lot of time to spend on the game, only a few hours each night at the most. Sometimes days would pass without having any time to spare on the game. This was very frustrating. I spent a long time Play Testing crashblock. I took the advice contained within one of my books to get as many people playing as possible. My idea of fun is not the same as someone else's and it's important to make the game fun for as many people as possible. In this task, I think I succeeded.

Conclusion

Crashblock was a very interesting project for me. It was a simple game but as with all things, it's simplicity was deceptive. By adding a new element to a well known genre, it changed it completely and a new set of rules had to be understood in order to determine if the game was functioning correctly. The live action part was great fun to create and broke up the development process nicely, switching between pure coding and video directing. Sometimes it is nice to get away from the code and think about something else for a while. This helps to solve complicated problems. Aspects which should have taken longer were completed quite quickly and part which should have been simple took a very long time.

In the end, I created a game I enjoy playing, my Wife enjoys playing and my family and friends enjoy. I'm hoping that other people will enjoy it too.

In Closing: Zen-like wisdom

If a problem is hard and you're banging your head against the wall, take a step back, have a cup of tea and do something different. You'll perhaps see that the way forward is simply a matter of walking around the wall.