When your profession empowers you to design literally just about anything, it’s easy to rationalize just about any game design decision. Hell, I somehow managed to rationalize that our new power up for Tilt to Live have a screeching hawk sound effect. Bad idea? You’ll have to wait and see.

When Adam and I are working on design details for how a particular system or game mechanic will work, we bring a lot of assumptions to the table of how we think people think. And those assumptions are sometimes rooted pretty deeply so it’s hard to get on the same page. What do we do then? We get into an all out brawl. Ok, not really. We usually turn to our ‘beta testing’ group to do some observation of how they play and react to our design decisions. Our group isn’t very expansive at the moment as most of them are local friends so we can bring them in and have them play our latest builds. Keep in mind I use the term ‘tester’ for anyone that seriously runs the game through it’s paces and those that play it really quickly to see how the game works. Now all this is the easy part. You have a conflict or issue figuring out some detail of a design you go to play testing to try to gather some data. Simply enough. If you aren’t doing at least this, then you’re crazy awesome at game design and you should stop reading. Now. Really.

Doing it honestly.

Like I said before, it’s easy to rationalize any creative decision. It sometimes becomes even easier to rationalize a creative decision in the light of data.  “See? He did notice that you can only have pick up at a time active!” or “See? He didn’t even notice the limitations of the pick ups because he just runs through them blindly!” You have to try to stay objective as possible. You have to try to get in the shoes of the player and see what they see. Ideally, they are talking to you the entire time as they play giving you verification that your hypothesis is either incorrect or correct. Having worked on a single project a long time, the decisions you make on it almost take on a personal weight. When you find that your idea doesn’t work, you can take it personally if you’re not careful. This can become dangerous not just for your own mental well being, but testers/friends can pick up on it and not tell you what you need to hear.

One tip I found helpful in reading my data and separating myself from my idea is: Don’t think of why your idea will work. Think of why your idea won’t work. It can be seen as a negative way of going about things, but only listing the positive doesn’t help you analyze your decisions. You become blinded by the ‘happy path’ of when your idea is executed inside a narrow scenario, ignoring a sometimes large problem in the shadows. Uncovering the weaknesses in your design is far more telling than a huge list of positives. Save the positives for the “back of the box” :).

Doing it early.

One of the things that still gets me today is trying to send out builds of our game as early as possible. I always keep saying “just one more day and I’ll have feature X completed or bug Y squashed”. I have to remind myself that our testers aren’t our ‘true’ audience. Yes we want to make them happy and have fun. But better to have your helping hands tell you your game idea is utter crap than to find out it is utter crap 3 weeks after release. This one can be rather painful because you’re fully aware of all the gaping flaws in the code, art, and mechanics and you don’t want to show your work in an incomplete state. Not to mention, it’s hard to explain to your testers why the player sprite is flickering about as if it’s having a seizure whenever they press ‘jump’. Well do it anyway. And get use to it.

We’ve been getting better at this through all the game mode additions we’ve been doing to TTL. With our latest mode, Frostbite, we’ve had play testers in very early in the iteration of the game mechanic phase. They’ve seen the game grow and each step of the way have provided extremely good feedback on helping us balance the game. The actual game mode wasn’t even fully functional when we started playtesting. So what did we get out of it? We focused on the feel of the movement, controls, enemy placement. All minor things that I would spend tedious time tweaking on my own. With each new iteration we tell themwhat was new in that build and have the testers focus on it instead of being overwhelmed by “play this whole game mode and tell me what you think.” One thing to keep in mind is beta testers are there for feedback. Try not to let it turn into a ‘designed-by-committee’ ordeal. Or maybe you want to…but I’m a control freak so that’ll never happen ;).

Doing it often.

This can be a double edged sword. From my limited experience, testers can sometimes be seen as a limited, nonrenewable resource. You may have a completely different group of testers by the end of the project than when you started. I had this idea of being gung-ho about testing early so I would send out weekly builds to everyone very early in the development process. The problem? Tester fatigue. When the deltas between versions is very minimal, testers may not be interested in a weekly build. As a result, I spaced out the test builds in early development to be a little more rare so that testers had time to recover and were excited to give a new build a try. As release  day got closer, this feedback loop shortened as we approached daily, sometimes hourly test buids.

In the end, no matter how you approach getting feedback for your game, it is almost always is beneficial to your game.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web siteRSS feed, or Twitter.

…it’s so calming. I remember registering this domain in similar weather conditions, hence the name :). I submitted an update to Tilt to Live earlier this week, after crunching for a few days to get it done. So much to say and so little time :[. Heading up to New York City this weekend with family, which’ll be enjoyable. Went there for the first time a couple weekends ago since middle school, and it was so captivating. I enjoyed just walking down the streets in southern Manhattan and taking in the sights. Small experiences like these seem to do wonders for me in terms of creative ideas. I really need to travel more…

In other news, I somehow got suckered into playing Starcraft 2 and now I’m completely owned by it. The strange thing is I can’t stop thinking about it, but yet I can’t bring myself to play it. I can only seem to play it with a buddy as 2v2. Guess I can’t handle the stress of 1v1 right now, as it’s not exactly the best way to unwind after a hard day. Blizzard has created a rather compelling strategy game that has so many nuances I always get excited thinking about them. Not to mention I’ve actually enjoyed watching pro Starcraft 2 match-ups on youtube. They are simply amazing to watch. Someone needs to go make a SC2-TV app for the iPad. Go. Now. DO IT.

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. 😀

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.

App Store Games

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.

Top N Free Games

[table id=2 /]

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?

Distribution of 10MB+ Free Games

[table id=3 /]

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.

Top N Paid Games

[table id=4 /]

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…

Distribution of 10MB+ Paid Games

[table id=5 /]

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.

App Store Game Sizes

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.

significantly

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.

isimulate

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.