Here I was thinking that once Tilt to Live was out the door, that it’d calm down a bit and I’d get a breather to rest for a few days. Wrong. Running off the early buzz of Tilt to Live we took it as an opportunity to generate some extra excitement for our upcoming updates. It was a very weird shift going from a mostly ‘quiet’ development cycle of just spending days coding away to suddenly spending the majority of the next few weeks doing PR, marketing, chatting with players, etc. It’s been one hell of a balancing act since release despite knowing that releasing a game is only half the battle.

With that being said, my workload has pretty much exploded. And as a result, my updates here have been lagging. Things worth noting as of late (for me at least):

  • Tilt to Live was selected as one of Touch Arcade’s Games of the Month. We were honored to receive the ever elusive 5-star rating from them as well. Thanks TA!
  • Tilt to Live popped up on Joystiq earlier this week as well as on their podcast a few weeks ago. Awesome!

I’m afraid to say posts on here are going to be rather infrequent for the next couple of months. I’m anticipating that around July I’ll have all my stuff sorted out and finally be able to get back on a more regular schedule. I’m hoping to do some more tips and tutorials in the future as well. But until that time, just hang tight. 😀

Tilt to Live has been unleashed on the unsuspecting public! So far the general vibe has been extremely positive! Adam and I are both pretty excited about getting our first app store game out the door. What’s interesting is the workload went from “lull” to “overdrive” in a matter of days as we ramped up for release and still are trying to coordinate things for a bigger media push in the coming weeks.

You can download Tilt to Live in the app store here. One of the cool things about AGON Online integration is how it’s easy to check leaderboards outside the game. Their community page for Tilt to Live is rather snazzy. We’ll be looking into integrating some of those widgets into our own landing page on onemanleft.com. But that’ll have to wait for now.

We’ve got plenty of ideas in store for Tilt to Live for future updates. So tell your friends, your mom, your dog, your twitter followers! The higher the rating the better! Things are rather hectic at the moment as you can probably imagine, but hopefully I’ll have some breathing room and be able to look back on all of this and write up some (hopefully) useful posts.

So I’m using OpenAL to do the audio in Tilt to Live. Over the course of development audio became the bottleneck of my game, both in size and in performance. The following could help you if you’re experience audio performance issues and are somewhat new to OpenAL. Let me preface this with: Don’t blindly optimize. Measure, Measure, MEASURE! Know what your bottleneck is before trying to tune code!

  1. Don’t make more than 32 sources objects in OpenAL. Of course, this number may vary from device to device and what generation the device is. Making any more than the limit the device support makes openAL fail silently, and at this point you’re wasting cycles.
  2. Load your audio buffers and create your source objects ahead of time and re-use them. This is a big one. Don’t generate and delete source objects in the middle of your game update. Instead, it’s much faster to just grab a ‘free’ source that is not playing a sound any longer and attach it to another buffer. I was pre-loading my audio-buffers, but creating/deleting sources on the fly in Tilt to Live. Then I started ‘pooling” and I got a decent gain out of re-using source objects.
  3. Keep OpenAL calls to a minimum. Especially in tight update loops, don’t repeatedly call openAL functions that don’t change frame-to-frame. I found that a good portion of my time was spent doing something as simple as ‘alSourcei()’ on each source ID per frame was causing a significant slow down.
  4. Don’t query openAL state if you don’t have to. In my case, I wrapped openAL Sources in objects with properties to get volume,pitch, etc. Initially those properties simply called the openAL equivalent and returning it instantly. This was hurting my frames due to some some innocent looking “backgroundMusic.volume += someVal” happening each frame along with other audio sources doing the same thing. Save any state you can in instance variables, and as a last resort hit openAL when you need to.
  5. As for size, you should consider compressing your sound FX and music to a reasonable size. If you’re like me, you hate giving up quality; especially if you listen to the full quality one and then the compressed one. It can seem like night and day. But in reality, when your users won’t have a full quality audio file to compare it to, they will not notice the difference.

As a sidenote, you can look at my first dev tip for batch compressing audio files.

We’re extremely close to submitting our first title “Tilt to Live“. We plan on submitting it this upcoming Friday. After a long and grueling (but awesome fun!) development cycle we’ve learned a ton. I figured an interesting way to distill our new found knowledge it would be in very short “dev tips” for developing an iPhone game. Today I start out with audio:

Compressing Audio

By the end of development our game weighed in at 16 MB. We wanted to go below the 10MB limit so users could download our game over-the-air. Quickest solution? Compress the audio. Now, we were already using some compression but we have over 60 audio files! The main crux of the problem is we want to be able to quickly compress all our audio to a certain format, build it, look at final build size, and test for quality. For this I wrote a quick script:

[code]
#!/bin/bash
rm -rf caff
mkdir caff
for i in *.wav
do
afconvert -f caff -d ima4@22000 -c 1 $i caff/${i%%.*}.caf
done

[/code]

Now for a little explanation on my setup:

  • I have a single folder (let’s call it ‘finalAudio’) with all the original, uncompressed wave files used in our game.
  • The script sits inside this ‘finalAudio’ folder as well and I run ‘chmod +x build_audio’ where ‘build_audio’ is the name of my script so I can just click on it in Finder when I’m wanting to re-export my audio.

What the script does:

  1. It removes any folder/file named ‘caff’ in the current directory
  2. it makes a new directory inside ‘finalAudio’ called ‘caff’. This is where the compressed audio will go
  3. It looks through all wav files inside ‘finalAudio’ and runs the ‘afconvert’ utility on each file and puts the resulting compressed file in ‘caff’.

I’m not going to go into the details of all the options you have with afconvert and what audio formats the iPhone supports. There’s plenty of documentation online covering that already.

Just an interesting sidenote: we took our 13-16MB game and shrunk it to 6.5 MB using ima4@22000 with 1 channel.

I’ve received a few e-mails now regarding this tutorial that was hosted on Ziggyware’s site. So here’s a quick post to help others save some time and give an update on it’s status:

Ziggyware.com seems to be down indefinitely. As a temporary solution until I get back around to hosting this tutorial myself you can find the Google cached version of it here. If you wish to look at the sample code and illustrations in full you can download the XNA sample from my site here. Note, that the XNA sample was built on a very old version of XNA so my guess is it will not compile out of the box, but the general logic for the ribbon trails should be the same regardless of XNA version.

Ribbon Trails XNA

Enjoy!

I had seen a few things written about “Everyday the same dream“, a game created by but never took the time to try it out myself until recently. It’s a compelling art game where you try to subvert you’re daily routine. It took me a few minutes to figure out what to do after a few days of the mundane routine, but  that added to the whole experience of the game itself. It’s a very subtle, but clever design that speaks to a wider audience.

Be sure to give it a try. It only takes 5-10 minutes to play through.