Take the 2-minute tour ×

We are working on a number of games that have a variety of sound effects as well as spoken phrases and expressions. The current design stores the sound snippets as individual numbered files. A set of #defines maps a human-readable name to the file name. For example:

#define SOUND_COOL              @"0038"  // Cool!
#define SOUND_YOU_GOT_IT        @"0039"  // You got it!
#define SOUND_FANTASTIC_1       @"0040"  // Fantastic! version 1
#define SOUND_FANTASTIC_2       @"0041"  // Fantastic! version 2

One advantage of this approach is that the code becomes very readable. You can see what sound will play just by reading.

One of the problems with this is that we have many intonations or versions of some phrases. Whenever appropriate, a hand-coded switch statement randomly chooses from among the available versions.

It would be nice to generalize this and have the option to play a random version if more than one is available. One option here could be to abandon the #define approach and create a proper database table with fields that allow for selection of all sound files matching a given criteria. A class and methods would then encapsulate the desired functionality.

What are some of the other ideas for organizing/cataloging sound in applications that might have hundreds of sound files?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

How about an NSDictionary? You could store the dictionary in a plist and load it once on startup. The keys would be some kind of sound ID (@"Cool", @"You got it", etc.) and the value would either be a string or an array.

A string means there's a single sound, so play it; an array means there are multiple choices, so pick a random one.

You could wrap all this in a class, so if you made a call like:

[soundBox playSound:@"Cool"];

soundBox would have code like this:

id obj = [myDictionary objectForKey:key];
    // play the sound in file named obj
} else if ([obj isKindOfClass:[NSArray class]]) {
    // pick a random sound from the array obj
share|improve this answer
Interesting idea. I'll have to think about it a little. –  martin's Feb 29 '12 at 0:06
I'm looking into a variant of this: Using JSON to bring in the data rather than a plist. The code would be more reusable and it might open up other enhancements. –  martin's Feb 29 '12 at 0:55
JSON would be a top choice for me too; I only suggested a plist to be more iOS/Cocoa native :) Of course JSONKit will turn JSON into an NSDictionary anyway... –  gregheo Feb 29 '12 at 2:52
I ended-up with JSON for the data and SBJSON for loading it. Then, as you suggested, an NSDictionary made it easy. –  martin's Apr 12 '12 at 19:03
add comment

Some ideas:

  • Create a folder for each sound, multiple files in each folder, one for each intonation.
  • Put all of the intonations into the same file, one file for each sound, store a set of values for frame or timestamp to begin and end playing each intonation from the file
  • Merge all intonations and sounds into one file, the pointer in code could be just start and end point in the file
share|improve this answer
I ended-up with a JSON database with a tag field for each sound file. Similar content would get the same tag. For example "Hi" and "Hello" get the SOUND_TAG_GREETING tag. With that in place it is easy to search for available sounds based on the desired tag. –  martin's Apr 12 '12 at 19:05
add comment

Your Answer


