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!

Fun with Procedural Lock and Key Puzzles

Hi!

Something I've been experimenting with recently for Jungle.com is throwing in some procedurally generated lock and key puzzles. Since I've played around with these before, mostly in the context of my research, and Jungle.com already has both locks and keys for other purposes, I figured they might add a nice bit of spice to the generated levels.

The basic idea with generating locked doors is pretty simple and fits nicely on top of the existing level generator. For context, this is what the generator did prior to adding locks:

1. Generate the complete arrangement of objects for the level (I might post about this process separately) 
2. Randomly choose rooms for the start and end of the level (sufficiently far apart to keep things interesting).
3. Pick a semi-arbitrary path between the start and end of the level. This will be the "guaranteed path" for completing the level, although other paths are highly likely to exist. 
4. Forcibly carve openings between rooms on the "guaranteed path". 

Now to add locked door puzzles, I just add a few extra steps to this process:

1. Choose how many locks to add to the level based on a "lock density" parameter that I can control for each level. 
2. For each lock to generate, choose a random node on the guaranteed path (that hasn't yet been chosen) to generate the lock. Place a bunch of immovable walls and locked doors in between the chosen node and the next node on the path to add the locks. 
3. For each lock generated, spawn a new key somewhere on the guaranteed path before the locked node. 
4. I don't do this yet, but it might also be fun to generate locked doors between rooms that don't lie on the guaranteed path, just to see what happens. 

And we're done! With locked doors active, you might end up with rooms that look kind of like this:

The walls and locked doors are placeholder art right now

Now, since almost everything can be destroyed in Jungle.com, keys included, you might wonder what I do to prevent the player from blowing everything up and getting kinda stuck. The answer is, well, "not much."

Even the code says "too bad"

The design philosophy for Jungle.com so far has been "Offer enough solutions so the player would have to work pretty hard to get completely stuck". It's seemed to work pretty well so far, so hopefully it works okay here as well. I'll be relying on ample play-testing to make sure there aren't any serious snafus.

Anyways, after implementing all this junk I tried playing a few levels set to 100% lock density (so every room on the guaranteed path is separated by a locked door). It seemed pretty interesting. I definitely had to plan my motion through the levels a little bit more, but I could also see it getting kind of annoying if I make locks too frequent. Also, what's this...

Darn you acid spider enemy! How dare you destroy my carefully generated lock and key puzzles! Haha, the fun thing is that getting past that spider unharmed might actually be more of a hassle than just finding a key and unlocking one of the other doors.

Of course I'm leaving that in.

Okay Bye!