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!