Creating dynamic audio for a jam game.

I love to read ludumdare postmortems but I feel like they cover a lot of the same ground so I thought I would focus on a single aspect of my most recent ludumdare entry People. I’m a big fan of dynamic audio in games since I feel like it’s one of the better uses of the medium and the ability to tailor what the player is hearing to whats happening in game can really heighten the experience. So without further ado here’s how I created the three major components of my games soundscape.

The music:

The music in my game is divided into three different layers. Rather than worry about looping issues I ended just playing three very long tracks in sync and when it was time to introduce a new instrument all I had to do was increase it’s volume. This came at the cost of a greatly increased file size but for a jam game I think it’s a reasonable compromise. The most complex part of the music was making sure that the melody didn’t start or end mid phrase. To do this my melody was created with roughly two bars of silence between phrases. Since the melody loop is playing in sync with the other files I keep track of when the silence occurs and only adjust the volume of the melody at that time.

Ambient background noises:

One of the things that I really wanted to do with the ambient noise was to let it provide the sense of space rather than the graphics. I wanted to convey the sound of a large transportation building like a grand central station with extremely high ceilings and lots of reverb. I ended up recording several conversations from various positions in my office. Those were then layered together with slightly different reverbs applied to them. I ended up making three sets of ambient noise that I transitioned between as the crowd thinned out, the first having a large number of voices and the last being a single conversation. Since it’s hard to distinguish any sort of actual dialog I ended up just cross fading between the different conversation sound effects and let the music mask any transitions. By the time the player reaches the end of the game the ambient noise has died down to a single conversation that really reinforces the feeling of emptiness. On more than one occasion while watching live streams I’ve seen players pause after matching everyone else up and then, upon listening, go to seek out the last person. It’s a subtle way to deliver the information that there is one final person to seek out.

Sound effects:

For all the sound effects I used modified version of my own voice. When couples in the game meet up there is a “Yay!” sound effect that consists of several layered recordings of me saying the word “yay”. This sound was then pitch shifted, put through a phaser, and a slight reverb was applied. The “hmms” and other noises that the people make when joining your group were just normal recordings of my voice with a touch of reverb. The footstep noises were created by hitting different pairs of shoes against each other until I found a good match. There were also several squeaks and ambient sound effects that we foleyed that did not make it into the final game.

Together all of these elements help to provide a sense of space and set the tone for the game far more than anything I did graphically. Thanks for reading and if you haven’t played it yet you can find my game here

LD26 – People

Woot. Another LD has passed which means another excuse to complete a game. This time around I had a really hard time embracing the theme. It may be because I had already made an attempt when it was the theme of LD-11 which I never completed. To compound matters I had made plans to work with my artist from LD-25 but he was unavailable this time around. I ended up talking to family and friends and decided to tackle the theme from a different angle. They pointed me in the direction of Ezra Pound’s poetry, specifically the following poem which became the inspiration for the game I made.

In a Station of the Metro
The apparition of these faces in the crowd;
Petals on a wet, black bough.
— Ezra Pound

I really liked the idea that a minimalist poem would try and convey an idea with the least amount of expression necessary and I tried to keep that in mind with my game design. To that end there are no tutorials, ui, or title screen. I tried to use a single art asset as much as possible although I had to make exceptions for a slight background texture so that the player felt grounded. I did go a bit overboard with the audio and the animation but I feel that each of those does contribute significantly to the experience.

So far the response to the game has been phenomenal. Thank you so much to everybody who’s played my game on their streams and who have left comments. If you haven’t tried the game yet you can play it at the link below and if you participated in LD-26 you can rate the game here:

Play People

People - LD26

And remember to work together… as a Jamteam!

After seeing a post asking for tips on participating in Ludumdare as a team I was inspired to write this. I’ve successfully participated in three global game jams with in person teams, the Boston Festival of Indie Games, and Ludumdare(with St0ven), so I have a bit of experience with jamming as part of a team. There are plenty of other posts that cover the basics of participating in a game jam on your own and many of those suggestions still apply. Here are a few examples:

I’ve tried to keep my tips specific to a team environment, so without further ado, here they are.

If possible, form your team ahead of time
This way you know who’s doing what and what style they’re most comfortable with and what they are capable of. There’s nothing worse than trying to find another artist or programmer at the last minute and finding out that the tools they are familiar with or the style they use is completely incompatible with the game you are making. This also helps prevent the problem of too many chefs in the kitchen. If you form your team ahead of time and realize that you have four programmers and no artist then you still have time to split into two or more teams.

Minimize overlapping responsibilities
If you have multiple programmers you should try and break things up so that you aren’t working on the same code. You want to spend your time creating, not merging and bugfixing. If you do want to have multiple programmers working on the main gameplay components then have someone define interfaces early on. This way it’s really easy to drop in new code or change existing behaviour. For artists this may mean having one person do all character art and another do environments or UI.

Reduce bottlenecks and get rid of interruptions
Ideally create a way for artists to add content to the game without having to go through a programmer. Create placeholder assets(empty sounds, blank sprites) that can be easily swapped out without programmer intervention. This allows you to focus on making the game work while they can focus on content and aesthetics. Spend a little more time on making it easy to load in lots of content(It will pay off in a team environment). This also saves you or somebody else from interruptions where someone is asking what they can work on or to add their new content to the game. Make sure that each person has multiple things that they can focus on so that if they can’t progress on one they can switch over to the other. There are always going to be scheduling issues, you may have artists working on stuff while your programmer is asleep or vice versa and you don’t want that to slow down progress. Finally, if you need an uninterrupted block of time to work on something then be clear about it. Make sure that any questions or requests are written down for later or sent via email. I go so far as to sign off of IM/IRC and not check my email if I’m cranking away on something.

Someone should be calling the shots
This doesn’t mean that you need to be a ruthless dictator or that other people can’t make creative contributions but at the end of the day somebody should have an idea in mind for what the final game is going to look like and they should help guide people in that direction. Whoever takes on this role should be capable of understanding what is feasible. As a programmer I find that I am not great at estimating artist workloads and I have to assume that the reverse is true too. Also keep in mind that it’s a 48-72 hour game jam, it’s not the time or place to demand perfection. I always try and encourage people to do their best work and I find that I’m constantly surpirsed and inspired by what they create. If you find yourself in this role make sure you get estimates from the people who are actually doing the work and always be conservative with your estimates. If somebody else is organizing the game then don’t be afraid to say no to them, in the end everyone will be happier with a finished game than an unfinished game that was a really cool idea.

Source Control
Use source control. If everyone is at the same physical location or on some sort of instant messenger then drop box or a network folder can work, but it’s not ideal. You want to spend your time working on your game not mucking around with version control so stick to what you know and keep it simple. Make sure that it’s something that you are familiar with. If you don’t know how to use git or svn then now is not the time to learn it, you’ll just end up frustrated when you try and do anything more complicated than simple commits. If you don’t know a source control system I would recommend using drop box with a backup folder in it for old revisions. If your artists don’t know your source control system but your programmers do then consider using some sort of hybrid where your code is in source control but your art assets are uploaded to dropbox. Recent builds should always be available to everyone on the team. Source control is what allows you to add potentially game breaking tweaks at the last minute without fear or to spend an hour refactoring things to add a new gameplay feature that may or may not work.

Pick an idea early and run with it
This isn’t nessecarily team related but it’s exacerbated in a team environment. It’s easy to waste time trying to come up with the perfect idea. Pick something early on and keep the scope small.

Plan for people to drop out or have other commitments
Focus on the most important parts of your game first so that when somebody can’t continue to participate you can still salvage a game out of what you’ve got. Animation and polish and menus are nice to have but leave it all for the final day. Unexpected things will come up, in fact I don’t think there’s been a single jam that I’ve participated in where everyone has been available for the entire time. If something comes up and you have to take a break or drop out then you should let everyone else on your team know that you can’t participate and if you’ll be back later.

Have fun making games,

My LD-23 entry: In The Beginning.

So I participated in the 10 year anniversary of ludumdare and this is what I came up with. It’s a game where you play as god creating the world.

How to play:
Build the world as you see fit. No other goal than to make the planet you want.

Hold right mouse to pan
Middle mouse is zoom.
Click a segment of the world to build.
Pick up item drops to get more stuff to build.
You can change your currently selected item using the left menu.


Dead Sea Postmortem

As I mentioned before I spent my weekend participating in the global game jam at NYU. Long story short I found a team and we made a game although one that isn’t quite as fun as I’d like. That game is Dead Sea, a puzzle game about trying to eliminate the fish populations of the world using only two tools, harpoons and predatory species. Overall it was a great experience and was unlike any of the ludumdare competitions that I’ve done before. So without further ado here is the postmortem.

What went well:

The first thing that I think went well was that I spent a bit more time than most people trying to find a team. With over a hundred people at the event there were a plethora of ideas to choose from including standard genres as well as ideas that I never thought would work in a million years. I bounced around between several groups where I heard lots of ideas for platformer, dinosaur and zombie games before finally meeting up with a bunch of other people who were undecided. We all pitched our ideas and broke into several groups instead of being roped into making a game that I wasn’t fully committed to.

The next thing that went well was paper prototyping our game. After deciding on the initial plan for game having two people playtesting and refining it constantly was extremely helpful and freed up a lot of time for me as the programmer to work on implementation without worrying if what I was doing would be fun. I think that the fact that all of our levels require a fair amount of thought once you understand the game mechanics and can be won or lost without taking trivial actions is a huge achievement even if we didn’t provide enough feedback to the player about their actions.

One core idea we kept throughout the entire development process was keeping the game simple. While additional gameplay ideas crept in over the course of the weekend the core of the game did not change since early in the day saturday. This gave us a fallback in case we had to cut anything or switch to working on graphics or sound then at least our core gameplay was intact.

What didn’t go well:

It’s always a challenge to complete a game in 48 hours and there are several things I would have done differently if given the chance. First of all while I like the simplicity of having a single programmer it would have been nice to have a split between two people one working purely on gameplay and the other on interface graphics and sound. If this were the case I would have been able to squeeze in several more gameplay elements as well as xml level formats so that we could have done more playtesting of the compiled game without having to make a new build each time. Also I think this would have allowed us to increase the feedback we provided to the player. Animated arrows for actions as well as action sounds would have gone a long way. Unfortunately these things had to be cut because there isn’t enough time to do it all.

The next thing that I wish had gone a bit differently was our team composition. What we had was good but it would have been nice to have had a dedicated artist as well as a sound guy and possibly another programmer. The art and sound assets we did get were great but I think that without the addition of another programmer it would have been difficult to squeeze anymore in. As it stands we already had to cut most of our sound assets.

The final thing I would have done differently is to not try and use a new library at the last minute. I’ve been meaning to move to openal from fmod for ages and I decided to try and fit it in with an hour and a half left to go. After failing to get it working properly I had to revert back to fmod. It would have been nice to not lose those forty five minutes so that I could have gotten more of our sounds in the game.

To wrap it up this has probably been the most fun 48 hour competition that I’ve participated in. Even though we didn’t win any of the categories I had a great time and met a ton of great people and overall I’m very proud of what we managed to accomplish together. I’d like to thank Margaret Moser, Ricardo Delgado, Nathaniel Chambers and Chirs Makris for their part in creating this game. And now before I forget you can download the game here(source code is included) or at our game jam page here.


More pictures: