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!

Three Years??

I did some fact-checking and it turns out I’m a little off on the numbers – Bleed has been in production for over two years, but not quite three. My bad. Still, a pretty long time, right?? I figured I’d show a bit of how the game started and how it’s changed over the years!


Bleed was originally created with two goals in mind; to be an incredibly quick and fluid sidescroller, and to be as dark and violent as possible. Huh? Well, before Bleed, my games had a very goofy style. People enjoyed them, but a common complaint was that they were a little… you know.



So in an effort to reach a wider audience – especially on the XBLIG market – I was gonna make an uber-violent, uber-bloody ass-kicker of a game. It was going to star a ruthless, animalistic warrior on the brink of death, clawing his way back to life through a surreal hallucination of a dream word. He’d probably look something like this.

Look how serious and brooding he is! He’s so damaged, he’s wrapped in BANDAGES!! Thanks to my good friend Illya for the dude on the right.


I put together a two-level prototype to test everything out – collision detection, enemies, bosses, dynamic camera, etc. Here’s some footage of a run-through I whipped up!


Laughably puny rockets vs. SUPERPOWERED ROCKETS!!

You can see some… interesting gameplay mechanics at work. The air-dash move is there in a basic form, and the game rewards you for narrowly dodging attacks by super-powering your weapons for a brief time. Inspired by Bayonetta, most likely (that game rocks.)



Red vs Blue.

The boss even survived, at least in spirit! I really like the idea of battles that become progressively more outlandish, and it’s an enemy that forces you to use all the gameplay basics to fight effectively.




Even the menu was going to be dark, brooding and dreamy!

Now… it looks like this.


So what the hell happened? Two things.

The game was going to be heavily focused on story – but at the end of the day I had to realize that 99% of players just don’t care. Besides, I’m not exactly Shakespeare. I have no doubt that it would have ended up as a pretentious, self-important mess.

Much more importantly, doom-and-gloom, ultra-serious-for-no-good-reason just isn’t me. I’m a lighthearted, fun-loving guy and I think it would have come off inauthentic. I believe what I have now is much more entertaining, and a more pure expression of myself to boot!


Some other notes:
-People who played the prototype were freaked out by the hero character and thought he was supposed to be an enemy.
-There used to be separate buttons for jumping and air-dashing. It was confusing and most people ended up awkwardly air-dashing everywhere when a jump would have sufficed.
-Do those tilesets look familiar? If you think so, you’re probably wrong. You should just forget about it.

The games are Plucky’s 3D Adventure and Grapple Boy, if anyone is curious.

Animating Wryn

Animating characters in a sidescroller is usually pretty easy, especially when you use something called a sprite sheet. A sprite sheet is a large image that contains all the animations for a character. Example time!


Shazam! Here’s a walking animation for a cool robot dude — all the frames are stored inside one large image. You play them one at a time, it looks like he’s walking! Simple!


But let’s say we want him to be able to shoot while walking — we’ll need to make a seperate animation for that. And what if we want him to be able to shoot up, down, and forward while walking? Each one of those has to have its own animation. A little more work, but still pretty simple.


And what if he can jump? And dodge? And shoot while jumping or dodging — in all directions? I’m sure you can see where I’m going with this. Sprite sheets are great, and often they’re all you need. But they can get out of hand if you aren’t careful.



So now I’m making Bleed, and the main character can run, jump and dodge — and she can shoot 360 degrees around her while doing it. Is it time to make a sprite sheet with a million animations? Nope. Now it’s time to do something a little different.


Here’s the sprite sheet for Wryn. I divided her into three parts — head, body and legs. Now all I have to do is layer them on top of each other and I can mix and match for any situation.



Notice that some body animations have arms, and others don’t. While moving and jumping around normally, Wryn uses the bodies with arms. When shooting she switches to a body with no arms, adds two separate arm layers rotated in the shot direction, and overrides the head to look in the direction she’s shooting. When she shoots and air-dodges, every body part is overridden to match how she’d be twisted in the air to shoot in the proper direction.


Dividing Wryn up this way also allows me to animate in some other touches using nothing but code. I can angle her body and legs to make her lean into her movements, and I can subtly raise and lower her head and body while she runs, making the animation look more powerful.


And here’s a video of it all coming together!

Making A Better Tileset

Like most old-school platformers (and many modern ones) Bleed is a tile-based game. For those who don’t know, that means the game world exists as a big grid. Each space in the grid gets its graphics by using a section from a larger image called a ’tile set’. A picture will express it better than any words I can muster:

See? Sections of the tileset are re-used and arranged to create whole levels!

So with that out of the way, let’s be honest. That tileset? Not so hot. It’s all muted and monochromatic and where the hell is that supposed to be, anyways? Well, it was supposed to take place in a mansion during a stormy night, but the Dream Build Play 2011 deadline was looming so it was brainlessly rushed out. Oops.


I started over, this time putting a lot of thought and research into the location I was designing — doing sketches, picking colour schemes, that kind of thing. “Mansion during a stormy night” sounds pretty simple, I guess, but there’s a lot of different types of mansions out there — as evinced by a Google image search — and having a strong visual goal is very important. I decided that climbing up the roof of the mansion would add some drama to the level, and I started by designing a tileset for the exterior.

So. Here’s my method, more or less. Once I have a clear idea of where I’m going, I rough out the important parts of the tileset. It’s done in greyscale so I can focus on making well-defined tiles that blend into each other well without worrying too much about little details. The player is stuck in there for a size reference.





Next I colour in the important tiles, which is usually where silly mistakes come in — much more useful than it sounds! Here I had decided on a dark purpley-blue as the main colour for the tileset to evoke the darkness of a stormy night. Good idea, sucky implementation, but I feel making mistakes is an important part of the process! They let you know what’s not working and help you improve, so every time it’s a step in the right direction.




Changing my colours a bit and putting them to better use. I experimented with patterns of roof tiles until I found one I liked.






Refining the colour scheme and colouring in the rest of the tiles to match the roof.







I had made a test level in Tiled (an excellent and free 2D tile editor) to check that all the tiles were repeating well and looking good together while I was doing this. You can see the test level here.


With all the important tiles done and looking good, I was free to use the remaining space in the tileset to add flavour to the level with trees, windows and other small details.






From there it’s a matter of revising and revising, changing colours and removing tiles that weren’t very useful to make room for ones that are.






Unfortunately I didn’t take any in-progress shots as I remade the interior tileset but I put the same level of research and thought into its design and followed the same basic method, both of which I believe helped immeasurably and I think you’ll agree.


Finally, a few tileset pointers I picked up along the way:

Hiding the grid: By their nature levels made with tilesets can look a bit artificial — just square images aligned in a grid. Good tilesets seem to hide their grid-based nature when possible, as I have tried to do here. The grass, for example, takes up two tiles vertically instead of just one. It uses more space but it breaks up the grid and looks more organic.

Maximizing tile use: It’s another big plus if your tiles can be used for more than one purpose. Most people are aware that the grass in Super Mario Bros. uses the same image as the clouds, only painted green. I’m not that clever but the tops of my trees double as bushes when placed on the ground.

Intelligent use of contrast: The further away something is from you the less contrast it will generally have. Keep this in mind when creating tilesets, making foreground elements brighter and richer in contrast than elements intended for the background. It’ll help give depth to your levels and better express where the player can and cannot stand. Two big pluses!

That’s it for now! Thanks for reading!

A Brief Introduction to Bleed (and the Difference a Year Makes!)

Hi! Welcome to the development blog for Bleed!

What is Bleed, you ask? Well, Bleed is a lot of things. It’s my vision of the evolution of action-platform games — a genre I hold dear but feel growing stagnant. It’s my stab at creating the kind of game I’ve always wanted to play, one where movement and attack are fluid and truly unconstrained, where nothing holds the player back but their own skill and split-second decision-making. It’s also just a whole lot of ridiculous fun that I hope anyone will be able to enjoy. Thanks for asking!

Bleed stars Wryn, a spunky young girl who wants to be the best video game character of all time. The only way to the top is taking out the roster of everyone’s favourite heroes, and with a little bit of help and a whole lot of bullets she’s bound to succeed!

Bleed’s been in production in some form or another for two to three years now, and the light at the end of the tunnel is finally beginning to peek ever-so-faintly into view. It was entered in Dream Build Play 2011 and while it didn’t go anywhere you’d call successful, it’s back in a huge way this year and better than ever. This blog will focus on the making of the game, lessons learned over the years and the process of examining and improving what was entered in 2011! Lots of content will follow but PAX East ain’t gonna attend itself, so for now here are three screenshots. Though they aren’t much, they go a long way towards illustrating the difference a year can make.

Before / After 1Before / After 2Before / After 3