The Making of The Useful Dead

Hey! So, I thought it would be fun to document the creation of a small game from start to finish. I’ve gotten into some nitty-gritty stuff in previous posts, but this will be more of a broad-phase, general look at the entire process. There’ll be a time-lapse video at the end of the post showing much of the process, so if you don’t want the explanation and build-up I’d skip there now. Otherwise, here we go!

To start I need something to base a game on — usually a gameplay mechanic. For this game, I thought it would be fun to play a puzzle game where when you died, your corpse stayed behind to be used on your next life to hold down switches, be used as stepping stones, and otherwise solve puzzles. I also thought it would be funny if the things you were controlling were cuddly, stupid animals.

So with that in mind the next step is to do a lot of thinking. In what way could corpses be used to solve puzzles? How would you move them around? Can the corpses push each other? How many ways can you die to create a corpse? Could some methods of dying render a corpse unmovable, or dangerous, or completely destroyed? Et cetera, et cetera — I like to get as clear an image as possible of how the game will behave before I start doing any “real” work.
Once I had established the rules of the game, I brainstormed as many puzzles as I could to see if there was enough meat there to make a decent-sized game, choosing about thirty puzzles as an absolute minimum.

Puzzle brainstorming! I crossed ideas off as I incorporated them into puzzles.

I ended up with forty-to-fifty levels which was plenty, so I got to work roughing it out! Over the years I’ve developed a basic engine that I can now use to quickly try out game ideas, letting me see if they’re fun and making sure I can code them properly. Using that basic engine, I started creating and testing the core of the game — first the player, then the corpses, then the various obstacles I’d planned like spikes, water, buttons, moving platforms, etc. It doesn’t look pretty at this stage but it’s not supposed to — it’s all about making the game work and making it fun.

This is where I find out what’s working and what’s not. For example, there was originally going to be electrified ground, which would kill the player and create an electrified corpse. You would chain electrified corpses together to conduct an electric current. I could barely get it working, it wasn’t that fun, and very few puzzles made use of it, so in the end I decided to scrap it completely.

Happy accidents also occur at many stages of development! When I was testing out spikes, it just so happened that when you jumped into them from below, the corpse would hang in the air for a second before falling — almost as if it was stuck on the spikes and then sliding off. I didn’t design it that way or even consider the idea — the way I coded it just happened to produce that result, which I really enjoyed and kept, and even used in a few puzzles.

So at this point you could say the building blocks of the game were coplete, and it was time to use them to create the game itself. Again in super-rough form, I went through my puzzle ideas and turned them into actual levels (using the free program, Tiled!)

Between cut content (like the electric floors) and ideas that turned out to not work, the number of levels in the game was reduced. This was balanced out by ideas that popped into my head over the course of the game’s development, so the final game still has roughly 50 levels.

This is one of the last puzzles I thought up, way after most of the others were complete. You can tell from the “NEW DUNCE PUZZLE” scrawl, heh.

Then I got friends and family members to give the game a shot, giving me a rough idea of how difficult each level was and how they should be ordered in the game. I don’t have any real idea how to do this properly, but in general I try to make sure the difficulty and complexity ramps up, with occasional dips for people to chill out and feel good.

When I was done creating and testing all the levels, I got to make a tileset and spruce them up, to make them look something like an actual game. I’ve discussed tilesets a bit before, so here’s a quick visual breakdown of a level’s construction.

Three layers of tiles — the collision layer is not displayed to the player.

Then I got to design the silly animals that the player controls. I wanted it to feel like you were constantly presented with new and different animals, so I separated their features into a sprite sheet (which I’ve also discussed previously!) In short, it allows the various bodies and features to be mixed-and-matched to create many different animals!

The amazing Justin Chan (@justinchans) agreed to lend his artistic talents to the game, which is why the animals look so good. You can see my ‘before’ and his ‘after’ here.

Justin Chan rocks. Let me say it one more time. You can follow him at @justinchans !

His wicked animals also inspired me to up the visual quality of the rest of the game, doing a second pass on the tileset and adding in more visual variety.

The revised tileset has a much more bold, clean and cartoony look, to both match Justin’s animal art and to help differentiate the foreground and background tiles.

I also added in a real background and a lot of particle effects for polish (have I discussed those in-depth before? I’m not positive. I’m sure many others have.   :D)

I find particles lend games a ton of polish and make them much more fun to interact with.

With the game itself basically done, there’s still plenty little things to do, namely saving and loading, the HUD and the menus. I’m a big fan of having menus that serve a purpose and tell the game’s story, and while this game has almost no story, I still did what I could. Basically I made the background a treasure map to try and express that these animals are on a quest for treasure. Simple!

Also, if you look at the map, they could have just crossed one bridge to get to the treasure, instead of the deadly and circuitous route shown. Silly critters.

Designing the HUD also raised some interesting questions. I wanted you to start with 100 animals at the beginning of the game and slowly lose them as you went, but I wanted some of the animals to be expendable so that you could experiment a bit and fudge some puzzles where you might get stuck. Each level was designed with a specific number of necessary deaths in mind. So at any one time, the player might want to know: how many animals do I have left? How many of those animals are expendable? How many am I supposed to kill to beat this level? I like keeping things as simple as possible, so after some brainstorming with my immensely good sport and brainstorming friend Brian, I decided on something like this, which I believe is a good balance between simple and informative. You can always tell the target deaths and how many times you’ve died for each level. When you beat a level, the other stats come up.

It still might be a bit complicated, but I think it’s well within the game’s right to embrace its quirky indie nature.

Finally I added music and sounds, which I snagged for free off the internet. For the voices of the animals, I put a sock over a mic (for a pop filter), went into a closet full of clothes (for damping) and made a bunch of weird noises, which I then trimmed and edited to the best of my ability in the free program Audacity. Yes, it’s super cheap. It’s how I’ve done all the voices for all the creatures in my games.   :D

And, well… that’s about it! I made a time-lapse of as much of the process as I could, hopefully you’ll find it interesting to see. I forgot to record a few things like the sound recording/editing and some menu creation, but the gist of it is definitely there. I hope you enjoy, thank you for reading / watching!

Bleed Release Date Announced!

Finally! Bleed will be out on Dec 12, 2012 for Xbox Live Indie Games and PC!

For PC, you’ll be able to find it on GamersGate ( ) and hopefully, right here (it’s still something I’m looking in to). Hurrah!

EDIT: I really should have put this in post originally, but the game will be five bucks, and there will be no DRM in Bleed!

Making a Boss!

The game is almost ready to be released! Woo! Right now I’m going through a playtesting phase, trying to work out the kinks and catch any really nasty bugs. In the meantime, here’s a post about how I created one of the more involved bosses in Bleed! (There’s a video showing the whole process at the end of the post. Skip there if you don’t like to read!)


The boss is Battalion, a shape-shifting hive-mind swarm of aliens. They attack by fusing together to create different objects, kinda like the Bat Company from Dawn of Sorrow, or Mega Man’s Rainbow Devil. So, first up, coding an ‘intelligent’ swarm!


I started by creating a kind of “controller” object to co-ordinate the swarm, shown here as a red square. Every object in the swarm tries to keep within a certain radius of the controller — if it moves outside that radius, it changes direction to head back in. I tested this behaviour with only one object in the ‘swarm’ at first (not really a swarm at all), and then added more in when I thought it was looking good. It resulted in a roiling, seething mass of objects! Cool!


I am the next DaVinci.

Next, to create the illusion of them joining together to transform. The radius of the swarm can be adjusted, so it’s really a matter of quickly shrinking it so that they all zoom towards the center. While they rush into the center, I take the object they’re going to turn into and scale it up while fading it in to existence. It’s sorta convincing! I tested it with a random sailboat I drew.

This is the beginning of the boss’ “AI”. Most of the bosses in Bleed have a pool of behaviours they can draw from, including a default “idle” behaviour, which is basically what I’ve just described. The controller flies around and the swarm follows, then fuses together and chooses a new “attack” behaviour. Whatever attack they choose will appear and begin. When that’s over, the boss returns to the idle behaviour.


Now I have to actually code these attacks. The first thing I do is brainstorm all the random attacks the boss could perform, and try to figure out which are the most interesting and unique to fight against. Here is a picture I took of some of that brainstorming (I work on a whiteboard a lot because it’s fun). Among the ideas I liked were a bomb, and a missile.


I started with the bomb attack, which was very simple. The bomb appears, bounces once, and explodes into a spray of baddies. I drew up a four-frame sprite sheet for this — four, to take advantage of an animation technique called “squash and stretch”. The bomb stretches as it falls through the air, and then squashes against the ground. It makes the object look more bouncy and interesting, and I do something sorta similar with the swarm fusing together. The radius actually expands before it shrinks, making it more dynamic and readable. Look for it in the video!



From there I coded and designed the other attacks, making sure they transitioned well from one to the other. I don’t want to give away all the attacks, so here is the sprite sheet for two; the bomb and the missile. You might notice the sprites are all greyscale. That’s so I can use code to tint them any colour I want, meaning Battalion will change colour as it changes shape!


I then added a bunch of fancy sounds and particle effects that help sell the transformation / attacks, and notify the player when the boss is being hurt successfully. I also tune the boss for different difficulties. For example, take the missile attack — Battalion moves faster and spawns more of the smaller baddies the harder the difficulty. (Maybe that doesn’t sound like much. On the hardest difficulty, the missile moves faster than the player does, so you have to keep faking it out while dodging through a mess of spawned baddies. It can get pretty intense!)

Finally, I playtested it a bunch and made adjustments based on that. For example, most people found the boss to be fairly easy even or higher difficulties, so I changed the smaller baddies that spawn during attacks to home in on the player, which they do more quickly on harder difficulties.


And, well… that’s it! Here’s a video showing the whole process! Thanks for reading!

Bleed Demo!

Yo internet!

If anyone wants to give Bleed a shot, here’s your chance. It’s a demo of the first level and a little bit of Challenge Mode, which lets you pick and fight up to three bosses at once. You can use mouse/keyboard or a wired Xbox 360 controller.

Just to be clear, this is still a work in progress — there could be bugs, and things like music aren’t final. It’s also the first level, so if anyone’s worried that it doesn’t provide enough of a challenge, well, sorry —  it’s meant to be more of an introduction / warm-up!

Here’s the link. Enjoy!
Download the Bleed demo!

If it doesn’t work, you may need to install:
NET Framework 4.0 Redistributable.
XNA Framework Redistributable 4.0 Refresh.

You can also try it for the Xbox 360 if you have an App Hub account!
Download the Bleed demo for the Xbox 360!