Parade of Rain

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:

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.

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.

: )

As I'm zeroing in on finishing Tilt To Live some of the bigger assets are coming through from Adam and the game size has grown a lot faster than it has in past few months. One of the unstated goals of mine was to keep the game under 10 MB. Why? You are not allowed to download apps, podcasts, or videos that are larger than 10 MB over 3G. You are required to connect to wi-fi in order to do it on your iPhone. Alternatively, you can use a PC/Mac and just sync the said data to your phone/iTouch, but who bothers to do that?

Having a 10MB limit on an "unlimited" data plan sucks, but I'm not here to discuss that. This limit possibly poses a constraint on iPhone developers who want their games to be widely available. I just started digging into this, but haven't really found anything conclusive on downloading habits of iPhone users beyond a few small-sample surveys and articles.

In either case, the question I wanted to answer was:

Do you stand to lose a significant amount of potential sales/downloads for apps over 10 MB?

I decided to do some unscientific data gathering and some manual data mining with good 'ole excel :].

The Process

I fired up iTunes and after fumbling about in the iTunes app store I was able to get to the Games top 100 free and paid section. This was actually my first time digging around in the itunes desktop app store, as I download and buy 100% of my apps and podcasts directly from my phone. Connecting my iPhone to my computer is a rare event indeed...

Not having released a game yet on the app store I didn't have any data on hand that'd prove useful for this. I took a rather low-tech approach and just consulted the all mighty top 100 lists of the app store. I took the top 100 games in the paid list and the free list and compiled them separately to try to find two things:

• How many 10MB+ games exist in the top 100?
• How are those 10MB+ games distributed in the top 100?
  

So the caveats to using the top 100:

• From my understanding, I'm only seeing the US top 100?
• It's not representative of the HUGE library of other apps that are still somewhat successful but not the over-night hit sensation that a lot of the upper rung apps are
• I don't have a good idea of the size distribution of games that aren't in the top 100, so I may be missing the big picture. So any experiments seeking to find a distribution has a very limited view "window" of what is actually going on.
• This data includes iTouch devices, but since they lack 3G this could possibly skew the data.

The Results

First, I'll explain what I thought the results would be. Before doing any of the number crunching I hypothesized I would find that the most successful apps are under 10 MB and any app that happens to be over 10 MB would be weighted towards the lower rungs of the list.

Let's first take a look at the free games in the app store. Below is a table showing the number of apps above 10 MB split into top N lists.

We find in total that there are only 18 out of the top 100 free games that go over the 10 MB limit. Not exactly conclusive, but it shows that majority of top 100 free games are available over the air (OTA).  As you decrease the size of the list the number of 10MB+ games starts to dwindle naturally, but when you look at the percentages the amount of those 18 stays relatively the same until you hit the coveted top 10. The only 10MB+ free game in the top ten is Real Racing GTI, a promotional game for Volkswagen that weighs in at a rather hefty 59.3 MB!

Now how does the distribution of these "heavy" games look in the top 100 free list?

Hmmm...The distribution of 10MB+ games is pretty even all the way up to the top, with a slight dip in the mid section.

Let's look at paid games.

One thing I didn't really account for in my original hypothesis is a difference between paid and free games. 53 paid games are over 10MB! While by a slight margin, the majority of paid games seem to ignore the 10MB rule and go for broke! Egad! This above table completely refutes my original hypothesis that most successful apps are under 10MB (Wow those last few sentences sounded super nerdy...). This is assuming you equate that success = number of apps sold * price of app = more $$$, where as in the free model this kind of breaks down. Anyway, moving on to the distribution of paid game juggernauts...

Interesting. While the paid app list has a majority of 10MB+ games the bulk of them live in the top 20-40 section, again, only by a slight margin. The stand out number here is the top 20 section. It appears games that are under 10MB here still win out the majority, so maybe there still is some relevance to my original hypothesis but to a much lesser extent than I imagined.

Probably not as useful, but in case you're curious here's a simple area graph plotting top 100 free and paid game sizes, there are some monster sized games in the top 100 so that is encouraging! Click it for full resolution.

The Truth Revealed?

Looking at the free games market the results decidedly point to a more "logical" trend, in my opinion, on how games are being designed. Yet, when you look at the paid games market you find that:

• Developers don't give a crap and make what suits them (Hurray freedom!)
• Consumers don't seem to give a crap either on how big it is when they are paying for a game. Maybe they even irrationally prefer bigger (in physical size, not content) games for their dollar?

While the results point to opposite trends on app store game sizes, it doesn't really uncover if developers are consciously shooting for sub 10MB games or simply letting the chips fall where they may in either case. Could free games just not warrant enough budget to make enough assets that grow bigger than 10MB? Are free games specifically targeting "viral" game status by shooting for sub-10MB downloads to allow it to spread more easily? I also find that a good bit of the free games are also "Lite" versions (62 of the top 100 in fact). So it shows that people like to try before they buy at least. With Apple's announcement that they'll allow free apps with in-app purchases, hopefully things will clean up a bit. But that's a different issue for another day.

If you're interested in getting my scrawny little excel spreadsheet with the free/paid top 100 lists to run any fancy shmancy analytics you're welcome to it.

I finally got rid of the stupid...

"ld: warning in <foo>.so, file is not of required architecture."

...warning when using iSimulate. If you're not using iSimulate or a similar technology you're losing valuable time even if you don't use the accelerometer or GPS functions. Then again, I might not be the best spokesperson on time since I spent the weekend re-inventing the wheel.

I have this need to make sure my projects compile w/o warnings. I let it sit for a while because I'm not an XCode expert so I knew I wanted to conditionally link it in but I couldn't find the UI for it. The process in which they suggest you integrate iSimulate into your XCode project truly is easy, but I felt icky when it came up with warnings when you compile against the actual device.  There are better ways of doing that. Namely, conditional build settings. Of course, it requires a few more steps and a bit more knowledge of the XCode environment so I suspect that wouldn't help their marketing. Regardless, having the iSimulate linker flags and library search paths only be added when you're compiling for a simulator is relatively easy to setup.

Every now and then I come across a game that is rather inspiring. Strangely, a lot of them come from the flash community. I really like it when someone can take a game mechanic that is so utterly constrained and create something so enjoyable out of it. The epitome of these design challenges might be the 'One-Button' games. I just recently came across Canabalt, and it had me playing for a while despite the need for sleep.

The sense of urgency and the whole atmosphere implies a bigger and more ominous 'universe' than what the gameplay focuses on, and is a treat. I've died several times trying to figure out the fleeting images in the background only to slam into a wall, haha!  I'll be checking it out on my iPhone later this week. Hats off to them for getting it onto the App Store and good luck!

Last week was a busy week as I spent most of it implementing and tweaking the really basic tutorial system I had in mind for Tilt To Live. From my gameplay experiences I feel tutorials have gotten pretty good at being integrated into the game themselves and not being ridiculously wordy/boring. I'm not sure if it's that I tend to grok how most genre game mechanics work from many years of playing, or understand the basic 'standards' across games in the same genre, or that the tutorials are really getting better. I tend to be optimistic about it though and hope we are progressing . When I was designing the tutorial system for Tilt To Live (which isn't anything special, but I did sit down and give it a bit of thought) I started thinking from a more general game design perspective on what to consider in such a system:

How complex is thy game?

I generally pay attention for first few minutes of tutorials to learn the essential controls then I barrel forward into the game hoping for the best. Some tutorials overstay their welcome. It really comes down to distilling the core gameplay experience and then getting the user to run through those motions quickly and keeping it engaging. Of course it's really hard to get around that if you're game is as complex as say...Commandos 2.

Commandos 2 may be the most ferociously complicated game released yet for Xbox. - 1UP

Sometimes there just isn't getting around that boring part of the tutorial if your game really IS complex and there are a lot of rules required to know before you can  make your first move. For sufficiently complex games, tutorials are a huge part of the game design problem. When I played commandos I pretty much lost interest after 15 minutes futzing around in the training missions. Another tale of a lost player due to a lengthy and uninteresting tutorial . And this was even with a friend of mine who was a huge fan of the game pretty much holding my hand through the first couple of missions. It just didn't click with me, but I like to think that the 'fun' of the game was lost on me.

Yet, lengthy tutorials are common in non-video game settings. Take contract bridge for instance. I learned to play it with several co-workers and if you gave me a manual and several self-paced tutorials I probably would have never figured it out (particularly the bidding system). Call me dumb, but I like to think I'm just lazy .

The difference in me learning how to play bridge vs taking the time to play commandos 2 was that the "tutorial" was integrated into the very game itself in a way. I wasn't playing "Tutorial: Bridge" like I was playing "Tutorial: Commandos 2". I was playing full non-handicapped bridge and learning at the same time. It was a constant learning process. It was a fun process of discovery, which for some odd reason didn't come across to me in Commandos 2. The rules of the game don't spoon-feed you tactics and how to 'win' at bridge. Also the 'engaging' part was from talking to the other players in the game to learn more. Not many tutorial systems beat social interaction. I'm certainly not the only one that enjoys learning how to play a game through other enthusiasts. Juuso, of GameProducer.net recently had similar thoughts:

I like how Zombie Panic has no tutorial, nor much hints at all. Instead, players ask each other “how you rotate the board”. In Zombie Master (for some reason I’m getting zombie game examples here) it’s cool how players ask each other “what to do next?” - sometimes the reply is “n000b!” but often time other people tell what to do. I think that’s tutorials in its greatest form: community interaction where everybody helps each other. People can enjoy the game in many different levels.

In essence, the more complex your game rules are you may be more justified to put in a longer tutorial. But you need to ask yourself, particularly if you're an indie focusing on smaller games, is your tutorial system teaching the player the game rules (Bridge) or is the tutorial holding their hand while they play a bunch of throw away levels (Commandos 2 and a lot of single player games)?

Who art THOU?

These days, no amount of tutorials will get a player who is casually interested in your game but doesn't grok the necessary control schemes to talk in that game's "language". By language, I mean FPS, RTS, or RPG relevant control schemes. Each genre of games kind of have set standards on how to play that particular game. I've pretty much concluded that my mother, at her current age and interest level, will never be able to pick up Halo 3 and learn to play it competently. Not because I don't believe she doesn't have the ability (lol), but simply because she doesn't care enough about it to invest the time and energy to become familiar with that system. Give her bejeweled 2 on the other hand and omg...we've lost contact...for hours. On the other hand, any hardcore gamer can take any FPS shooter, run through a brief tutorial on what is different about this shooter than others and proceed to play.

Casual games have picked up on that sensibility (for the most part), and keep tutorials pretty minimal but make very few assumptions about the player from what I recall. The good iPhone games tend to be doing a decent job at conveying play mechanics quickly and efficiently, because the audience is mobile. Some opt for a simply 'how to play' button but offer no in-game advice, while others do the opposite.

I chuckled to myself when I realized the brilliance of Doodle Jump's aesthetic, intentional or not. They were able to literally pencil in the tutorial in the background as you play and not break the "mis-en-scene" (hah, how's that for artsy?) of the game.

In Practice

So, when it came to implementing a tutorial system for Tilt To Live I had the answers to the above two questions along with some other notes:

1. How Complex is the game? Mechanically, it's dead simple. Actual difficulty of getting a reasonably high score? Currently, results may vary. The resulting tutorial system should be either a)extremely minimal b) non-existent.
2. Who are YOU? While the game has obvious influences from more hardcore 360 shooters, I wanted to tone down the difficulty, give a more approachable aesthetic, and try to reach a less hardcore audience. The resulting tutorial system shouldn't assume too much of the player's previous gaming knowledge. This influences the terminology you use in tutorials and other text.
3. Appealing to the Core Ideas of the game: One of the core ideas of Tilt To Live is to keep it as minimal and simple as possible. Right down to the title, which serves almost as a tutorial in itself.

Adam and I kind of went back and forth on whether a game as simple as Tilt To Live really needed any explanation. I mean the title pretty much says it all for goodness sake. I persisted and decided even a brief explanation of at least one of the game rules (collecting pick ups to attack enemies) should get an explanation. We eventually came up with this (a work in progress video):

So the player on the first launch of the game is informed of the general rules of the game but control is never taken away from them as they can freely play the game. This gives the first time casual player some time to get acclimated to the game's controls and then proceed as normal.

We're still up in the air about a "How To Play" option that would give more detail on the power ups and mechanics. I figured no one would give a damn about the option, especially after seeing a few other iPhone games. It all points back to the complexity of the game. It doesn't necessitate the explanation of all the power ups. Plus discovering what each one does is part of the fun . Additionally, I will cut anything from the main menu as long as it doesn't make  it more difficult to get to information you want in order to keep in line with point #3 above. So I'm leaning towards removing it all together, but I'm not completely done iterating on it so it may change....

Tangible goals are key to any project. Without them I feel like I'm peddling up a steep hill just so I can peddle up some more. Scheduling and time logs showing time spent are great for statistical and historical purposes, but in the scheme of things can do little to save a project if you and your team lack that motivation needed to push the last mile. Countless indie games die from loss of interest. I've had several of my own projects fall by the wayside as other opportunities popped up that seemed more "fun". As they say, the grass is greener on the other side . But I would argue the overall motivation for those failed projects didn't dropped per-say. It was just that a particular type of motivation wasn't effective at getting that project done, and that the person failed to cultivate the right type of motivation to see it through...

Short Term Vs. Long Term Goals

When it comes to goal setting I tend to write my short-term, concrete goals down in some form. That list takes the form of a weekly schedule and to-do list. The longer term goals, such as "Finish game X" or even loftier ones such as "become a full-time independent developer" or even "Travel...somewhere...anywhere" kind of stay in my head constantly nagging away at me . I find that when I'm not working directly on my game for a period of time the long term goals rear their head and eventually guide me back on course. But interestingly enough, the second I sit down in front of the computer to work my long term goals go out the window and short term goals kick in. This has had some pretty compelling implications on my work habits.

Some weeks I tend to faff about a good bit on YouTube, TED, RSS, IM, and other things throughout the work session. This happens even when I'm fully aware of the devil that is the internet. Now what happened between the time I was driving home from errands all hyped up about getting my game done and sitting down in front of my computer to make that dream a reality? I feel like my long term goals aren't pushing me along anymore once I'm in a position to do actual work. What I'm finding is that I'm constantly looking at my to-do list and reminding myself how great it'll be to finally have a a a good GUI system implemented this week to make the game hopefully look a little more...professional? I'm looking forward that following weekend to have a new build to push out to beta testers. I'm not looking forward to finishing game X on any given week, but finishing feature Y or bug Z. The important distinction here is that those short term goals have tangible results that are more easy to visualize while working.

Yes, I'm saying I have no idea how Tilt To Live will end up, I can only guess at that. I have a clearer image of how feature Y should work though. Maybe I should chalk this up to inexperience? It just seems so weird to me that there's some sort of internal switch in my motivation based on the context of where I am at or doing at the moment that decides whether short term or long term goals will be the most effective. Realizing this will help push me more to create better weekly schedules so that my short-term goals are more tangible.

This seems obvious when you think about it, but I started thinking about how this applies to other things in life when I came across The Buried Life while listening to an Adam Corolla Podcast (doing laundry at the same time so not completely faffing about!). How many goals do people never see become a reality because they experienced my errand-to-computer dilemma? They got all hyped up about an idea, but when they were on that edge of opportunity they backed away not because they didn't want to do it, but because they simply didn't have any short term goals to push them over that edge? I'll leave at that for now as it's a bit heavier topic that I simply don't have the time or qualifications to fully analyze at the moment. Back to my indie task at hand...

Work in Progress Screenshot of "Tilt To Live"

As I'm approaching the final legs of production (and starting to get my shit together for promotion and marketing) tangible goals are harder to find and smaller. In the beginning, having a playable mock up was a huge step forward that could be completed in a single week. Nowadays it's about getting X animation doing Y exactly correct so it's timed with the audio to give the best feedback for the user. The amount of effort for both tasks is about the same, but the return on investment for me as a programmer is much smaller when doing these polishing tasks. But I know polish on a good game is what pushes it past "ok" to "good" and gets people talking about it.

In a large project, such as indie game, having long term goals are essential to getting you and/or your team to jump on the project. Without those short-term goals feeding your long term motivation, your motivation eventually starves and the project slowly dies.

This week's partial tangible goal list:

By Saturday that list will hopefully be empty, but it's not the empty list I'm excited to see, but the fact that I'll have a first pass of a tutorial system in the game by the end of the week . Looking at this list I can tell my "scheduling skills" were a bit lacking and I know most if not all of the priority #2 cases will be moved to the following week because this week's goal is to implement and polish a tutorial system. Hopefully, this won't translate to another hour long fall through the rabbit hole they call the internet .

Oh, and in case anyone is wondering what task management system I'm using, it is called FogBugz. It's been a treat to be able to use such a robust system, even if I'm a single developer.