So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?

1. Consider Scope

I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).

To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.

Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.

2. Learn About Games

This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.

If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.

One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!

If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?

3. Choose a Prototyping Technology

So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.

If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.

4. The 2-Minute Guide to Game Architecture

Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.

The Game Loop

At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.

At its most basic, your game loop is going to do two things every frame: update and then render.

The Update

This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.

The Render

Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.

Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.

Events

But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.

At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.

You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.

The Other Stuff

Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.

The hardest thing about creating your first game is finishing it.

It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!

Owen

There were a couple of key things I wanted to address with Dapple’s first update:

1) Reduce app footprint to under 10MB

When an app is over 10MB, users with a cell phone connection aren’t able to download the app directly. Apps that are over 10MB require a Wi-Fi connection to download. I think this is potentially costing me quite a few downloads, mostly of the Lite version. I want the Lite version to be something that people can download on a whim. If they have to wait until they have Wi-Fi access, they might never download it.

Dapple and Dapple Lite were both about 13.1MB, so I needed to reduce them by nearly a 1/3. When I looked at the sizes of my various directories, it became clear that the music and SFX files were the ones causing the problem. Dapple has about 13-14 minutes of music that plays in the game. That amounts to significant file sizes. There are also 14 SFX files.

I’m going to get a little bit technical here, so if you don’t care for this stuff, just skip ahead a bit. The iPhone does have a hardware audio decoder. You can use it to hardware accelerate your MP3, AAC, etc decoding. However, it can only operate on one file at a time. This means if you’re ever going to play more than one sound at once, you have to use two forms of audio decoding. For Dapple, I use AAC compression for the background music, but all the SFX files need to be in a non-encoded format: Linear PCM. This means that the SFX files are huge, because they’re basically 16-bit uncompressed audio data.

For v1.0 of Dapple, all the music was encoded as AAC, 128kbps, constant bit rate, so that it sounded really good. I decided I would try to reduce the bit rate as much as possible without sacrificing the audio quality too much. By switching to a variable bit rate, I was able to compress the files much more without too much of a quality reduction. By doing this, I was able to reduce the music file sizes from 8.7MB to 6MB! Almost there already!

That was the easy part, now I needed to deal with my SFX. The iPhone documentation infers that if you’re not using a hardware decoded format you should be using Linear PCM or IMA 4:1. IMA4 (which I’ll refer to is as from now on) is a compression format for audio that results in a nearly 4:1 compression (it’s actually closer to 3.75:1). I converted all of my SFX files to IMA4 and was surprised to discover that none of them played. This is because there’s no native support for IMA4 on the iPhone. You can use it, but you have to write your own decompression code. I ended up scouring the net looking for information on the IMA4 data format, how the compression works, and how to decompress it. I found several partial resources, none of which were complete enough to just let me implement it. It took me two solid days of some pretty hardcore coding (it was really fun, actually), but I finally got IMA4 working in Dapple. The nice thing about IMA4 is that the file gets decompressed when it’s loaded into memory, and is then played as Linear PCM. This means there’s no performance hit, except on file load. (I’ll link to some of the IMA4 resources I found at the bottom of the post)

IMA4 was a huge win. My SFX files totaled about 2.2MB on disk before compression. After compression, they’re just over 600KB, with almost no loss in sound quality.

So, after rebuilding and zipping, both Dapple and Dapple Lite sit at about 9.5MB! Hooray! What’s next?

2) Fix an audio bug

This is the only bug that’s come up more than once since the game launched. If a user is playing their own iPod music while playing Dapple, then locks their device, their iPod music stops playing. This was a problem in how I was managing audio sessions in the game. This has now been fixed.

3) Add a Feedback Button

I want to make it easier for people to provide me with feedback on the game. I changed the Main Menu around so that the “Credits” button now says “Extras”. This opens a new menu which has “Feedback” and “Credits” in it. The feedback button, when clicked, launches the Mail program and lets the user send me an email. Hopefully people will use it to request features, complain about things they don’t like, etc.

4) Add a computer-controlled opponent for 2 Player Mode

This is a request I’ve had from a lot of different players, so I decided to try to put it into the first update. As of last night, I can actually play a game against a computer opponent. It’s pretty cool. However, the computer opponent is really stupid right now.

The way Dapple already works is that when a player starts their turn, the game searches the board and picks a random spot that will make a match. This is stored for when the hint arrow needs to be displayed. I figured I could make use of that code and just make a computer opponent execute a move there on its turn, instead of displaying a hint arrow.

This lead me to an interesting discovery: it works, the computer can play, but the computer opponent sucks at the game. In 10 games I played against the computer last night, I won every single game. What I found interesting about this is that this proves that making random moves in Dapple isn’t nearly as effective as thinking your plays through. I’ve had a small number of negative reviews (either on the web, or on the App Store), and the complaint is usually that they feel like playing randomly yields the same results as thinking their moves through. With a random computer opponent pitted against a player who thinks their moves through, the human player will almost always win. To me, this is proof that the game can be learned, that you can get better at it, and that strategy will win over randomness. Up until now, that’s what I believed, but I couldn’t prove it…

So today my goal is to try to encode some of the choices I make when looking for the best play to build a heuristic that the AI opponent can use. Then I’ll need to tune how much it uses that heuristic for various difficulty levels. Should be fun!

With any luck, I should be able to submit Dapple and Dapple Lite v1.1 by Monday.

Owen

IMA4 Resources:

• www.wooji-juice.com – A good starting point, as this article walks through the high-level steps required to get IMA4 decompression working. However, this article leaves out a lot of steps that are necessary to get things working. It is also not very clear on the differences between mono and stereo audio streams and how that affects the packets.
• wiki.multimedia.cx – Contains useful optimizations that allow you to avoid doing byte->float conversions to do floating-point math.
• wiki.multimedia.cx – Has some useful information on byte/nibble structure of the packets
• www.koders.com – Actual C code for doing the decoding. This is for quicktime IMA4, so some of the logistics of how you extract chunks of data won’t work, but the actual math for decoding each nibble into a 16-bit frame should be the same for you.

As I get closer to submission I’m working more and more. Last week I did several nights of working late and I worked a half day on Saturday, and a few hours on Sunday. I’m already paying for it. I haven’t been sleeping well again. The problem is that when I work late, I can’t stop thinking about work, even when I’m supposed to be sleeping. I end up lying awake at night going over things in my head instead of falling asleep. So I’m not really sure what to do. On the one hand, I need to be putting in this extra time right now, but on the other hand, I do like to get some sleep.

The good news is that by working a bit on the weekend I was able to wrap up the Timed Mode for the game. I managed to put in a bunch of new animations including: a countdown animation when you start a timed game, some beeping sounds when your time’s running out (that get more frantic as you get closer to “time’s up”), and a new Game Over animation that differentiates between losing because there were no more moves and because you ran out of time.

I’m quite pleased with how the Timed Mode turned out and I’m also pleased with how long it took to implement it. It took about 3.5 full days of coding to get it all in and working, with all the new animations, UI, etc.

Yesterday I started planning out the 2-Player mode that I want to add this week. The biggest problem I’m running into is the screen layout. The screen is pretty tight in single-player modes for displaying critical information, but now I need to display info for 2 players. So yesterday I spent a few hours mucking around in image editing software playing with the layout. I think I’ve got something that should work. Now I’ve just got to build it and see.

I’ve given myself until the end of the week (i.e. Sunday) to implement this new mode. That’s about as long as I can afford to take and not risk delaying the project significantly. It feels like I should be able to do it. Here’s hoping I’m right.

Owen

• Dropped the final music and sound fx into the game – the sfx have been balanced against the music levels now.
• Created a new interface for playing sound fx so that I can play them from anywhere in the game.
• Added sound fx to all the front-end menus and widgets.
• Implemented a tips system for first-time players that brings up information as events trigger in the game.
• Added an option to the Options menu that allows users to reset the tips.
• Went through all of the textures in the game and ensured that their widths and heights were all an even number of pixels – I had noticed some blurriness in a bunch of textures, which turned out to be because of the way the UV mapping is done on textures with odd widths/heights.
• Updated the multiplier animation to use the nice font and tuned the animation to be more smooth.
• Removed a bunch of dead code that wasn’t being used anymore.
• Fixed a bug in the board initialization code when launching the game at harder difficulties.

It feels good to get lots of little things done. It’s all these little things that make a real difference to the feel of the game.

Owen

Now the audio for the game works like this:

• If the user is playing iPod music when the game launches, it plays the game’s sound fx, but uses the iPod music.
• If the user is not playing iPod music when the game launches, it plays the custom game music along with the game’s sound fx.
• If the user brings up the iPod music controls mid-game and starts playing their own music, the game will stop playing its music and let them play theirs instead.
• If the user brings up the iPod music controls mid-game and stops playing their own music, the game will start playing the custom game music again.

If you have an iPhone developer account and want to see the details (including code snippets) of what happened and how I fixed it, you can see the thread on the forums here: Audio Session Problems (devforums.apple.com – Note: You must have an iPhone developer login to access this page).

I’m very pleased with how well this works. I think it makes the game feel much more polished, as it puts control into the users’ hands and lets them play how they want to play.

Next up this afternoon: adding sfx to the front-end menus.

Owen

I got curious about how other games handle things like this: start the game with no music playing, then attempt to start music via the quick music pop-up (double-tap the home button to bring it up anywhere on your iPhone/iPod touch) once the game is running (this causes my game to hang right now). I started going through other games on my iPod touch and tried combinations of starting with and without music. I ended up with all sorts of problems: games freezing, music refusing to play, the iPod’s music player jumping around between albums even though it’s not set on random, games playing music the first time I boot them, but then refusing to play music and refusing to accept touch events the next time I boot them.

For example, I booted Rolando while my own music was playing. The game kept playing my music and allowed me to play fine. I quit the game and stopped my music. When I reentered Rolando, no music played (including game music) and touch events had a 5-10 second delay on them rendering the game unplayable. It seems unlikely that this is a problem with the game as I experienced similar behaviour with other games. This is what I like to call “Good Times”.

In short: I’m not sure my iPod touch is stable anymore. I’m wondering if some of the bugs I was seeing are problems with the iPod? Or perhaps my bugs caused problems with the iPod? I’m tempted to do a hardware restore and see if things become more stable. Rebooting the device doesn’t seem to be helping much.

In non-audio related news, Gamasutra has a feature article up today about iPhone game development in 2009:

• iLang Syne: A Guide To iPhone Game Development In 2009 (www.gamasutra.com) – The author looks back at 2008 and the emergence of iPhone gaming, then talks about where we’re at right now, and then talks about what 2009 might look like for iPhone game development.

Now if you’ll excuse me, I’ve got an iPod touch to wipe out.

Owen

I’ve spent the last few days trying to getting Audio Sessions working with the game. Audio Sessions are the iPhone’s way of handling audio priorities. Basically, your iPhone app has little control over audio priorities on the device; you set up an session inside your app and tell the iPhone how you want it to treat your audio: should your audio stop the user’s music from playing when it launches, or should it mix with whatever other audio is playing, for example.

I followed through some example code and I thought I had things working, but it’s not working at all. I’m trying to do something a little more complicated than is standard: I’m trying to let the user decide whether the game’s music plays, or whether they want to hear their own music. They’ll be able to flip a “switch” in the game to change modes. From reading the docs, it looked like this should be straightforward. However, I’ve run into several problems:

• I don’t get the audio interrupt calls I’ve registered for – this makes it hard to know when audio states have changed.
• Changing the session category isn’t working – if I switch from a category where my music takes priority to one where the user’s music is supposed to have priority, their music doesn’t play.
• Changing categories is causing serious crashes – I don’t know why this is happening, but if I change categories and play/stop/play user music in a certain order, I can lock up the iPod touch I’m using. It won’t even let me shut it down unless I hold the “off” button down for 60-120 seconds, eventually it kind of shuts down in stages and reboots, but then the audio system is all screwed up until I do a second manual shutdown of the iPod. Not good. The real kicker here is that the debugger disconnects from the device as soon as it locks up, so I haven’t been able to tell what’s going on. Awesome.

So today has been a rather frustrating day so far.

I’m starting to wonder if it’s worth re-writing my whole audio engine to use the new audio system that was introduced in OS 2.2. The downside of that is that my game would require users to be upgraded to OS 2.2 and I can’t find any data on what percentage of users that is. For now I’ll go back and re-read the audio session documentation, I think.

Owen

I’m back at work today after being off for over a week. The break has been great. I had expected to work quite a bit over the holidays, but I didn’t end up doing any work. I think it was good for me to get away from the game for a while and hopefully I’ll be able to come back to it fresh. The next month is going to be extremely busy and tiring, so I’m glad I took the time to relax a bit before the big crunch.

Seeing as how we’ve entered into 2009 (that sounds like we’re living in the future, doesn’t it?) I thought now would be a good time to go over some of the lessons I’ve learned so far about indie development:

• If at all possible, separate your “work space” from your “life space”. I’ve been working from home for 6 months now and I love it. However, my wife and I live in a tiny (under 600 sq feet) apartment so my office is in the same room as the living room and dining area (the whole room is only 12 x 12 feet). While this didn’t bother me at first, the longer I work here the more I find it difficult to separate work from not-work. When I’m on the couch watching TV, my computer is almost right next to me and I often end up thinking about work when I should be relaxing. When we can afford to move into a bigger place, my main requirement will be that I have a separate room for my office.
• The idea is easy, the implementation is not. This is not a new lesson for me, this is something you learn very quickly when you start working in the industry. However, when you’re doing everything on your own, it becomes even more apparent. I spent nearly the first two months of the project just prototyping. I had what I knew to be a great idea for a game, but it took me two months of trying different implementations to find something that was really fun to play. I’ll admit it: that surprised me. I was convinced that the original idea I had would be fun, but it wasn’t. The game I have now uses the same core mechanic (mixing paint colours), but the game is totally different from what it started as.
• Game development is expensive. Don’t let anyone tell you that it’s not. Granted, start-up costs for a business like this are significantly lower than a business that requires retail space, inventory, employees, etc, but it still costs money. However, I did have hardware and software costs, contractors to pay, etc. I also realise that my budget is minuscule compared to a 10-30 million dollar blockbuster title. However, it’s my money that I’m putting up for this. Maybe I should have looked for investors at the start, I don’t know the answer to that. I like that I have complete control over the product I’m developing. For better or for worse, the game is mine. When the game is released I’ll provide some budget numbers (don’t expect a detailed breakdown, it’ll be very high level), but for now it’ll have to wait.
• Ideas generate ideas. Several months ago I posted an entry stating that every day I was going to try to write down an idea for a gameplay concept, a game mechanic, an environment. The idea was to build up a massive document of ideas that I could draw from. This worked really well for a few weeks. Forcing myself to come up with ideas grew new ideas. It was a great cycle to get into. However, as the game development gathered momentum, I stopped writing in the ideas document. Without forcing myself to come up with new ideas, fewer ideas were being formed. I had an idea this morning that I wrote in the book and noticed that my last entry was Oct 30th. I need to get back into the habit of doing this. It will be very important as I finish Dapple and get ready to move on to my next game.
• Don’t try to do it all yourself. This is really about knowing your limitations. I’m not trying to be egotistical, but I’m a pretty damn good programmer. I’ve been doing it a long time and I feel like I know what I’m doing. I’m confident in my abilities to solve problems of a programming nature and that I can learn the things that I need to learn. However, I’m not a professional artist. I’m not a musician. I’m not a sound designer. I think a lot of indie developers are tempted to do it all themselves. It’s that attitude of “I know how to use Photoshop; I took an online course,” or “I took an art class in high school that I was pretty good at” that gets people into trouble. When I started I was tempted to do the artwork for my game myself because, yes, I am fairly proficient with Photoshop, and yes, I did take a lot of art courses in high school and university. However, I realised that by doing so, I wasn’t playing to my strengths. I realised that my time would be better spent programming and paying someone whose job it is to create art, to create the artwork for my game. I think this was the correct decision. I’m extremely happy with the artwork, sound design and music I got from the people I worked with. While it cost me money instead of just time, I think I’ve got a much high quality game with a lot more polish out of it.
• Have fun! It seems like an odd one to have to state, but at the heart of things, I’m doing this because I love doing it. There are times where it feels overwhelming, like it’s not worth it, that it’s just too much work and too much risk. Those are the times where you need to step away from the development and remember why you started doing this in the first place: I’m doing this because I love making games and I want to make the best game I possibly can. What’s better than that?

Happy 2009 everyone!

Owen

As I somewhat expected, I didn’t get any responses from the press release-type emails I sent out. I think I need a different campaign. I think I need to contact editors directly with personal emails, instead of generic ones. I’m going to hold off until I have a version of the game that I can send them as a preview though. I don’t want the press playing the game I’ve got just yet. It needs more polish before I let reviewers have a peak at it.

Yesterday I got two big things done: I implemented the save system for the game and I implemented the High Scores screen. The save game system was surprisingly easy to set up. I had already set up a user data save system for the game options, so it was mostly a matter of determining how to store the game state and when/where to read and write it. The cool result of it is that the game now saves your state if you leave the game and you can resume it the next time you boot it up. That was pretty cool the first time it worked.

The High Scores screen seems less exciting, but it was probably the most complicated screen in my front-end, so it feels good to have that done now. I had been putting it off, but now it’s done and it looks great. However, I did have to make one design decision which may annoy some people: I had to limit the user’s high score name to 8 characters. That’s all that will fit on the high score screen. It was either that or truncate the name in the score screen at run-time, but I figured it was better to let the user see that their name is being truncated while they’re still able to change it.

Oh, and some bad news about my audio memory leak from last week: it hasn’t gone away. Apparently it went away in the one test case I had used. When I put the full music tracks back into the game, the memory leak appeared again. As far as I can tell, the leak is occurring in an OS level call, so I’m not really sure what to do about it next. I’m going to put it on the back-burner for now while I continue with feature implementation. It’ll have to get fixed during bug fixing time.

Another big step forward for the game this week: my artist delivered the last of the artwork to me. Now it’s all up to me to get it into the game. Very exciting stuff!

Owen

I got back into the code today and I was trying to get multiple music tracks to queue up one after the other using the SoundEngine code. I was having some problems and so I went onto the developer forums and discovered that a lot of people have had problems with SoundEngine. Apparently it had a lot of memory leaks and other problems. Some of the leaks have fixes on the forums. However, what was most shocking was to discover that Apple has pulled all of the example SoundEngine code off the developer site. They’re basically telling people not to use it anymore.

With the latest public update to the SDK there are preferred ways to do audio. The problem is, they only work on devices running the 2.2 SDK. I want my game to run on anyone’s iPhone or iPod Touch, so I’m trying to support 2.0.

I managed to track down a bug in the SoundEngine code that was preventing more than one music track from playing and then decided it was time to boot up Instruments (Apple’s cool performance analyzer) to have a look for memory leaks. There were quite a few, all of them coming out of the fix I’d just put in place for the audio system. Ugh.

I spent the afternoon tracking stuff down and I’ve finally fixed all the leaks in the game (for now). I can also queue up multiple music tracks. Hooray!

I did want to post a couple of things I learned today about tracking down leaks with Instruments:

• You need to launch your iPhone app directly from Instruments (you can’t track leaks in an already running iPhone process).
• Once you find leaks, go to “View” -> “Extended Detail”. I can’t tell you how important this is! I spent an hour chatting with a friend online trying to find a way to get a full stack trace for the leaked memory allocation. It turns out it’s all in that little hidden window! When you open the Extended Detail window and click on a memory address that leaked, it will show you a full stack trace that lead to the leak.
• Double-clicking on a function in the Extended Detail stack trace will open the source code to the exact line in XCode!
• You can’t create custom DTrace instruments for use with an iPhone, they appear to only work with Mac OS X processes.

Now that I know a bit more about how to use it, I’m quite impressed with Instruments. It seems to be a very powerful tool.

Owen