Making Failure Fun and Why it Matters

Here's a lesson I had to learn the hard way about making failure in games entertaining.

It came to me while I was watching players play both Conway's Inferno and Roller Derby Riot Queens, a game that I made in a week over the summer which was kind of a failure itself.

The main idea is that players will be more tolerant of failure when it's entertaining. Kind of obvious when stated like that, but it wasn't something I thought about much before witnessing it. To illustrate, here is a common pattern I observed whenever I watched a new player play Conway's Inferno. Below is the first level from the game.

When confronted with this level and minimal instructions, players would almost always do one of two things. Some players would place a fire on the cells in the center like so:

which of course is the "solution"and results in the player winning the first level and gaining an understanding of the game's mechanics. 

The other major thing the players would do is set one of the trees on fire like this: 

Which would lead to a big forest fire: 

And ultimately the game's minimal failure screen: 

But even despite failing, the players who chose the second option would often just laugh and reset the game. My takeaway is that even though they failed, at least they got to burn a forest down, and burning stuff down is at least marginally entertaining. 

In contrast, in RDRQ, when the player fails: 

The player disappears and a failure screen pops up. Now that's not particularly entertaining, but at least it's better than RDRQ's other failure screen... 

Which is the "the level has become unsolvable, but the game doesn't tell you that or limit your moves or anything, so shucks!" screen. Dang, this is basically an embarrassing example of the worst kind of failure a game can present you with. Not only is it not entertaining, it's not obvious at all!

After releasing this thing, I watched players play the same level for ages without realizing there was no hope in the universe of solving it and that they should just hit reset. Needless to say, they weren't too enthused to keep playing after encountering this style of failure.

Now you might ask why I let a game with such an obvious glaring flaw into the light of day. Well the answer is that I didn't really do much play-testing for RDRQ. As I mentioned before, it was made in a week, but what I didn't mention before is that it was made in a work week. So yep, after working on this thing everyday in my spare time after work, I was totally sick of it and wanted to shove it out the door immediately. Also unfortunately, of the play-testers I did have, most had watched me develop the game, so they kinda intuitively knew when they had fubar'd the level. Oh well, at least it was an entertaining failure for me (kinda).

Anyways, one takeaway from these two experiences is that it's usually a good idea to make failure both entertaining and obvious when designing a game, particularly if your game involves a lot of failure. This is something games like Spelunky, Super Meat Boy, and even Angry Birds do a great job with. 

My other takeaway is that I basically always always always always need to test my games. Yup.

Thanks for reading!

Fun and Challenges with Procedurally Generated Music

Here's a fun story.

When we were developing the initial prototype for Conway's Inferno during the 2011 Global Game Jam, we actually implemented a system for procedurally generating music for each level. It's still there, so you can check it out if you're interested.

The procedural generation was pretty darn simple and looked something like this:

1. Scan each column of the game grid at a fixed rate. 
2. For each column scanned, count the number of certain objects. For instance, the number of people is recorded in num_people, the number of trees in num_trees, etc. 
3. Once a count is recorded for each object, choose a sound to play from a list of sounds for each object. (i.e. people_sound <- people_sound_list[num_people Mod len])
4. For each type of object found in the column (i.e. count > 0), play the chosen sound. 

The goal was that the player's interactions with the level would actively change the music played by the level. Since we had a different set of sounds for, say, living cells and graves, the tone of the music would change significantly as the player killed all the cells. Meanwhile, environmental objects such as trees and rocks would provide percussion.

So you might notice if you play the new version of the game on iOS that it doesn't have any of the original procedurally generated music. What happened? Well, there were a few issues with the procedural system. First up, the general response from the public:

Not a compliment

Now if you've never heard of Crazy Bus, view the video below at your own peril. Personally, I kinda suspect Crazy Bus is just piping its own game code into the audio output stream or something. So in a way it's also procedurally generated "music", but obviously not the kind you'd ever want to be compared to.

Now, I think Conway's music is definitely better than Crazy Bus's, but we also could have improved it a lot if it weren't for the 48 hour constraint of the Global Game Jam. 

Unfortunately, another issue with the procedurally generated music came from the fact that levels that play well don't always intersect with levels that sound good. For instance, here's a shot of level 2 from the original prototype. 

Broken level 2

It may not be obvious, but this level is actually broken design-wise. The original goal of the level was to teach the player that trees could be set on fire to cause explosions that would reach cells one square away.

In the original version, there was just a simple line of cells to the tree in the center (instead of a T-shape) so the only way to win the level was by setting the center tree on fire. After we modified the level to sound better, the player could win by setting any of the inner cells on fire, which was no different than level one. Whoops! This is a good example of how easy it is to break the design of fragile puzzles if you're also trying to design for good audio.

For a fixed version that actually produced the same music as the broken version, check out the revised level 2 (now level 3) from the iOS version below.

Fixed level 2 (now level 3)

Ultimately, the problems of getting our system to sound good while at the same time playing nice with designing fragile puzzles were too much for our limited development time, so we ultimately scrapped the system in favor of a simple looping track.

While our exact implementation of procedurally generated music wasn't quite up to snuff, it was a pretty fun problem to play around with. For an example of a game that I think does procedurally generated and/or interactive music pretty darn well, check out Everyday Shooter on PSN.

Rich Vreeland's January also does some cool stuff with interactive music generation.

Thanks for reading!

Hello

Hi! My name is Alec Thomson, I'm trying to become a game designer and this is my new blog.

I've made a bunch of games in the past, sometimes as a student and sometimes as a researcher at the former Singapore-MIT GAMBIT Game Lab (now known as the MIT Game Lab), which can all be found at my website.

Most recently, I've released a free puzzle game for iOS called Conway's Inferno. Conway's Inferno is a game about goofing around with a cellular automata to cause the extinction of a species. It's totally available here, so feel free to download it and (hopefully) have some fun.

One of the later levels of Conway's Inferno

Meanwhile, the game I'm currently working on is a procedurally generated stealthy puzzle game called Jungle.com. Jungle.com is a game about robbing a major online retailer by ordering tools from that same retailer to help you out. It's still in development, so check out this gameplay video for an idea of how it plays.

At my day job, I'm a Masters student at MIT in the Computer Science department. My research is on developing designer targeted tools for creating procedurally generated puzzles. Right now, I'm creating tools the look kind of like this.

The Puzzledice puzzle editor

Anyways, this is actually the third time I've tried to start up a regular blog (don't look for the others), so hopefully I can keep it going this time. I'm going to try to keep posts short but frequent and mostly about my projects or other things I think are cool.

Okay bye!