10 Games.

I've read that you should make 10 games before you reach success in game development.
This isn't a strict value I'm guessing or any kind of hard and fast rule. However, I do feel that it's in a game developer's best interests to make as many games as possible. Partly to hone one's coding skills but mostly to understand what makes a game interesting and fun. It's also an important journey of self discovery, to understand one's talents and limitations.

I wrote many games on the spectrum, however none of them were what I would call "Finished" apart from the game I've listed here. Unfortunately, nothing remains of any of them, it was over 20 years ago. The rest of the games were for the PC platform and more recently for mobile devices..

So here's my list.

Treasure Caves

 ZX Spectrum. A platform game where you collect treasure in a scrolling maze like level to activate an exit which would appear after you'd collected enough treasure, all while avoiding traps and using teleports to move you to the next platform above. Perilous spike pits would plague your every fall.
The game included an editor where I would challenge a friend with a cunning level and he'd return the favour with an even more cunning level. This game was memorable to me because of the large levels, the large sprites. I had to write a Run Length Encoding compression system in Z80 (before I knew what RLE was) to fit the levels into memory. The game was fast and allowed for very devious traps. Even though the gameplay was simple, it was a lot of fun.

• Language: Z80 Assembler, Basic
• Status: Completed, Lost

SUOF: Subtle Use of Force

A vertically scrolling shooter where you must defeat an invading alien force using a previously mothballed fighter. You could collect weapons dropped from dead enemies, it had a variety of different aliens, each with their own abilities and tricks. There were also Bosses to defeat who also had their own patterns and abilities.

• Language: Borland C
• OS: PC MSDos. 
• Status: Completed - Unreleased

CHAOS: Battle of the Wizards - Remake.

A remake of the classic gameby Julian Gollop. Chaos pits 2 or more wizards against each-other in a last man standing battle to the death.
It was abandoned due to really difficult to track down issues in the code which would take a massive amount of work to fix. However the gameplay was faithful to the original with every spell and monster re-created.

• Language: VB6
• OS: Windows
• Status: Incomplete - Abandoned

GUNS: A DelphiX example. 

A turn based projectile warfare tank game where you control a squad of flying tanks who must fire at the opponents flying tanks on opposing mountain sides across a valley. AI behaviour aimed the turrets of the enemy tanks and raised shields. Limited fuel reserves and accurate aiming of the AI opponent meant that battles were usually quick and devastating -often needing quick reflexes and tactical uses of the shield. The terrain was fully destructible and this was the first game I'd written with a floating camera which worked independently of the player's control. It moved to focus on the selected tank and would also follow projectiles through the air to see where they landed - allowing the player to adjust their aim. All in real time. The game was published as a demonstration of how to make games using the DelphiX component set.

• Language: Object Pascal
• Framework: DelphiX
• OS: Windows
• Status: Completed - Released for free

Anomalous

 A rip in space has occurred following an unexpected situation during a science experiment trying to find a new source of energy to save our world from environmental disaster. The device causing the rip has fallen through the rift, it's up to  you to retrieve it before the earth and the alien world perishes. An entire story arc was planned involving alien civilizations and a civil war which would complicate your efforts.
It was a 2D platformer with skeletal animation - built from the ground up using a home grown engine called the CBCFoundation. An entire toolchain was developed to work alongside the engine including a level editor, skeletal animation editor and animator.
Unfortunately, a hard disk failure meant that I'd lost the source files for the majority of the art assets. It was an event which the project never recovered from.

• Language: Object Pascal.
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned due to hardware failure.

Lander

A variant on the old Lunar Lander game with a twist. You're in charge of a rocket which has to pickup and ferry spacemen from one part of the moon to another. Instead of using retro thrusters to control your descent, you have your main rocket which you must rotate around to move and slow down. Landing on the pad was tricky, you had to land at just the right speed and at the correct angle or Kaboom, however you could take some damage by hitting the mountains - making a horrible metal scraping sound as the rocket takes a pounding. I just couldn't get this game working as well as I wanted. The framerate suffered due to software rendering and the engine did not allow for the level of fidelity in the terrain I wanted.
I would later rebuild this in Unity as an example, however it wasn't as good or as much fun as I'd hoped and was ditched.

• Language: Object Pascal.
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned

Anomalous

A 3D version of Anomalous written using the Torque engine. This game was going to be the version of Anomalous it was meant to be. The earlier version being abandoned following a horrific hard drive failure. I created a lot of art assets however it seemed that no matter how many assets I created, I always needed more and the better I got at creating 3D assets, the worse my earlier work looked in comparison and my animation was horrible. Compared to professional offerings, I couldn't seem to compete. I needed to rethink this game. However I had a story fleshed out - just like the original attempt. It was just too big for a single person to build.

• Language: C++
• Engine: Torque Engine
• OS: Windows
• Status: Incomplete - Abandoned

Tetris

An example of how to build a tetris game, built in a weekend and offered on-line as an example. It was fully functional and surprisingly addictive, which I suppose goes to show how close I was to the original. It is an exercise that every game developer should do.

• Language: VB6
• OS: Windows
• Status: Complete - Released for free.

GUNS

A 3D version of GUNS written using the Torque engine. A fully 3D version of the original game complete with a story about aliens using the Earth as a kind of courtroom to settle petty disputes with squad based tank combat. The human race being powerless to stop them, but the aliens appear oblivious to their plight although seem to have no designs on taking over the world. Abandoned due to complexities with the Torque engine in making it do what was needed for this game and because 3D games need a lot of good art assets in order to look even nearly nice. It became obvious that alone I wouldn't be able to make this game no matter how much work I put into it.

• Language: C++ and TorqueScript
• Engine: Torque Engine.
• OS: Windows
• Status: Incomplete - Abandoned

GUNS:Reloaded.

A back to basics reboot of GUNS with the intent to turn it into a completed game for sale. As the original however with the inclusion of multiple environments, better AI, refuel dropships, different turrets, friendly AI behaviour, A roster of pilots and a plot involving rival factions who do battle on the earth as their chosen combat zone.It even had a tutorial. It was abandoned due to the realisation that the CBCFoundation's inability to use hardware rendering had made it effectively obsolete. I'd also come to the conclusion that it wasn't that much fun to play.

• Language: Object Pascal
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned

Crashblock

Control a person inside a game of Tetris. The person clambers and vaults over the blocks in the arena to get into positions and calls the blocks into position and rotates them. The blocks are held by a chain of increasing fragility - it will eventually snap sending the block crashing down. The player can also request the drop however in either case, it's best to be out of the way when they fall or you'll get squashed. Multiple levels, 4 environments, power-ups. Character graphics were captured from real-time video and roto-scoped. Winner of the Pascal Game Development group's 2007 competition. Published in 2008. This was the last game I wrote using the CBCFoundation and Pascal for that matter. The CBCFoundation's inability to handle hardware rendering without a massive upgrade almost killed it, but it was the advent of C# and pascal's descent into obscurity which finished it off.

• Language: Object Pascal
• Framework: CBCFoundation, SDL
• OS: Windows
• Status: Complete - Released for sale.

SUOF: Subtle Use of Force - Mobile

A conversion of the DOS based vertically scrolling shooter. I started it as an exercise in getting a mobile game developed, to understand the technical requirements as well as the development process. I hooked in the tilt controls to act as steering and on screen buttons for firing. Unfortunately, it was slow and clunky requiring far more work than I had time for at the time. It also ran differently on different phones. It served as a insightful prototyle.

• Language: Java
• OS: PC MSDos. 
• Status: Incomplete - Abandoned

Reversion Bureau

A science experiment has gone horribly wrong and you are called in to make it all better. Effectively a spiritual reboot of Anomalous. A platform puzzle game using live action footage captured against a greenscreen. Multiple characters and a story. This game is still in development but features physics as well as logical puzzles. A key feature of the game is that the main character does not resort to violence - instead solves problems using intelligence, the environment and science.

• Language: LUA
• Framework: MOAI
• OS: Windows, OSx, OUYA
• Status: In Progress

SchemeWars

Control a person inside a game of Galaga. The live action greenscreen captured person fires energy bolts from their hands at increasingly difficult waves of enemies. Complete with Boss creatures, all aliens have their own set of abilities and tricks. Completed and presented at an Insurance trade show.

• Language: LUA
• Framework: MOAI
• OS: Windows, OSx, OUYA
• Status: Complete - Released for Trade show.

ROO!

An endless runner where you have to rescue little Timmy from the well. Designed to be completely cross platform and created during a GameJam in January 2015. The game is notable for it's responsive controls, Spine animation and speed.The game was polished up over a period of 3 months and released on Android, OUYA and iOS.

• Language: C#
• Framework: Monogame
• OS: Android, iOS, OUYA, Windows
• Status: Complete - Released for sale.

Untitled Block Puzzle

We have a project on the go at the moment, which we'll announce shortly. The result of the second Songbird Creations Game Jam.

• Language: C#
• Framework: Monogame
• OS: Android, iOS
• Status: In Progress - Prototype

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.