The class is aimed at iPhone developers without previous OpenGL or 3D graphics experience. As part of the class, we’ll create both 2D and 3D OpenGL applications, and we’ll cover a broad range of topics, start with the basics of setting up OpenGL and rendering triangles on screen, to multitexturing and point sprites in the last day. This is definitely a hands-on class, so you’ll need to bring your laptop and be ready to do some coding.

Check out the Mobile Orchard page for discounts and registration details. Feel free to contact me if you have any questions.

Hope to see you there!

The idea was to get together Tuesday evening, starting at around 7PM, and to code all night and have an iPhone game (or at least a prototype) done by morning. About 25 showed up, working on about a dozen projects. Participants were welcome to group into teams or work solo. There were no restrictions as far as themes or technology. The only rules were that you had to finish something by morning (no leaving something that was 5% of a game) and you had to start the game from scratch (no finishing a game you had started a while ago).

The reason behind doing a game jam is to be able to quickly create game prototypes and decide if they’re worth pursuing further or not. Much better to spend a few hours one night and then throwing it away, than spending several months with multiple people involved. Also, the heavy time constraints often help participants by focusing them in the ultimate goal and forcing them to adopt creative solutions. Being all together in one large room added a lot of energy and made it possible to work really focused for many hours without a huge amount of caffeine (although the large amounts of coffee provided by Jay really helped!). In the end, we even ended up getting a late-night fiddle serenade by Phil Hassey. Try that at home by yourself! Owen Goss liked the idea so much, he decided to jam with use remotely through video conferencing!

One specific thing that I wanted to avoid with the game jam was the idea of giving any sort of prices at the end. I really wanted to keep the jam as an environment where people would be free to experiment and fail. If people were thinking of potential prices at the end, they would be a lot less willing to go out on a limb and try different things.

My goal going into the jam was to experiment with game mechanics that relied heavily on multi touch. I felt that very few games made good use of multi touch (aside from pinching) and that it had the potential to create something very different from the single-touch based game that we’re used to from mice for the last 20 years. The flip side of it is that a multi-touch game was much riskier and unknown. Could something that multiple simultaneous touches be fun, or would it be frustrating? Would your fingers get in the way and clutter the screen, or would it be a new experience? In the back of my mind, I was definitely drawing inspiration from the fantastic game Bug Bugs, by Igloo Games.

I did all the coding myself, but I teamed up with Evan McMahon from Veiled Games and he did all the awesome art in the prototype.

Owen Goss joining the iPhone Game Jam remotely

What Went Right

Started with an idea

I went into the jam with the idea of experimenting with multi-touch game mechanics. I also had in mind a setting that would be a good backdrop to those mechanics: You control a large, round spaceship in interstellar travel. As you travel between the stars, you need to collect different resources to power your ship and provide all necessary materials. Each type of resource goes in a different bay (which are located along the outer rim), so with two fingers you rotate the ship to move the collecting bay forward, and with the other hand you drag the different resources you encounter. Some resources aren’t useful, so you need to flick them away so they don’t hit the ship. Finally, other resources need to be combined before they can be processed, so you first need to bring them together, and then drag them to the ship.

You only have 10-12 hours to build a game, so if I didn’t have an idea going into the jam, I would have wasted precious time trying to figure out what to do while I could have been working on the game.

At the same time, I didn’t have the idea fully fleshed out and set in stone. I definitely let things change based on what I saw as I was implementing it. So it’s good to strike a flexible medium between having an idea and letting it evolve during the jam.

Used familiar tools

Just the day before, David Whatley raved about how great Cocos2d was for prototyping, and that same day, my friend Serban gave a presentation on using Cocos2d. I’m on record saying that I can’t stand to work with Cocos2d because it imposes a particular (totally backwards) architecture on you, and I can’t ever see myself shipping a game with it, but I can see the value in using it for prototyping.

The point of this jam (for me anyway) wasn’t to learn some new tech, but to experiment with gameplay. So I really considered it, but in the end, I decided to work with something I was familiar with, and used my (very small) codebase using straight OpenGL. I’m very glad that I did because I never felt that working at that level got in the way (other than one frustrating moment related to the first point in “what went wrong”),

Didn’t worry about performance

This is a hard one for me! The last two talks I’ve given are all about performance on the iPhone, but even thinking about performance here would have been a waste of time and resources. Sure, the game had to be fast enough to run on the actual device because playing a game on the phone is a very different experience than playing it on the simulator. Besides, a game like this requiring lots of multi-touch was impossible to play on the simulator.

But at the same time, I didn’t have to submit it to the App Store come morning, so I decided that as long as it ran on my 3GS, I didn’t care about anything else. That meant it could be very suboptimal and be a total memory hog. I didn’t care! I wasn’t even releasing resources!

The result, it played perfectly fine on my phone, and I spent zero time trying to optimize it or taking a longer route because of performance or memory reasons. On the other hand, just the tiny, single level I created is about 12MB, so it’s clearly very bloated.

Teaming up

As I mentioned earlier, I teamed up with Evan McMahon to create the art for the game. He wasn’t at the conference, so we organized everything through IM and Dropbox. The experience was great because not only did he create some awesome-looking art, but he really motivated me along the way. We played off each other’s energy and came up with new ideas because of the collaboration.

Going solo would have been OK because I was surrounded by a room full of like-minded developers hacking away at their games, so that would have helped keep up the energy levels, but it wouldn’t have had nearly as much of an effect as working directly with someone else. My only regret is that Evan wasn’t there with me.

What about the art itself? Was it a waste of time to add it to the game? After all, it didn’t help me make a better decision about the multi-touch game mechanics, did it? It wasn’t a waste of time at all for me. First of all, it took just as long adding some nice art than it took to add stand-in art because there wasn’t anything special about it. But most importantly, there is a feedback loop between the look of the game and the gameplay and feel of the game. So seeing the art in the game definitely changed how I felt about it and the decisions I made about it during the night.

What Went Wrong

Didn’t have a project ready

This just goes to show my lack of experience with super-rapid prototyping. I didn’t have a project ready to get started with the prototyping. I originally created a blank OpenGL project from XCode, and quickly realized I would be missing all the set up for sound, the view controller structure, and even some of the default touch-handling. So I grabbed one of my current projects in development, stripped it of everything game specific, and turned it into the project for the game jam. Not a big deal, except that it took me a good 20-30 minutes to go through this, and in the process I deleted a couple crucial lines that gave me lots of problems with OpenGL for the next 30 minutes. Doh!

Next time: Come prepared with a blank project, ready to go.

Running up against technical stuff

I went with OpenGL instead of Cocos2d on purpose to avoid having to deal with learning technical stuff sleep deprived in the middle of the jam. Unfortunately, it turns out my understanding of the multi touch event API wasn’t up to snuff to handle 5 simultaneous touches, starting, moving, and ending, each of them affecting a different object (or different parts of the same object). During the jam I wasn’t writing unit tests either, so that made for a pretty confusing time until I stepped back for a second, hit the documentation and Apple’s touch sample program, and tried to gain a better understanding of what was going on. Hint: Apparently looking at the touches in the UIEvent* parameter passed to touchesBegan is not a good idea, and you need to look at the ones passed in NSSet*.

Not enough time!

I certainly didn’t get as far in the prototype as I had hoped I would. There’s only one type of resource (ice chunks) and the control mechanics need to be improved quite a bit.

Is it possible that if I had used Cocos2d I would have gotten more done of the prototype? Yes, it’s possible, although I won’t know until I try it. Is it possible that half way through the prototype I would have encountered something that Cocos2d couldn’t do and I was left stranded? Yes, that’s also possible. And that’s a big reason why I don’t like framework-y type of APIs, and instead I would rather have a toolkit type of API so I can call into it and do the work myself whenever I want instead.

In any case, this is the flip side of “using familiar tools”. I will definitely experiment with Cocos2d in the future and consider it for another game jam if I’m familiar enough with it and I feel it speeds up development.

Everybody still going strong late at night (but not quite so perky anymore)

Conclusions

I think Space in Stereo has potential, but right now it’s too early to tell if it’s any good. The basic mechanic is there, but it’s not fun by any stretch of the imagination. I already learned a bunch about it though, including that some things weren’t nearly as much fun as I was hoping would be. For example, rotating the space station with two fingers… well, sucks. The better control scheme is to move the space station by dragging around the middle, and rotating it by dragging a finger around the edge in a circular motion. That was also what everybody was instinctively doing when they were trying out the game.

The game is just at the point that spending another 4-5 hours on it would answer a lot of questions about how fun it can be. I’m definitely planning on spending that time and then making a decision. If I decide not to go ahead with it, it’s not a big deal. Great games come out of making a lot of different prototypes and throwing away all the so-so ones along the way.

As far as the Game Jam itself, it can only be described in one word: Awesome. It was everything I was hoping for and more. I can’t stress enough how much it helped to have everybody else around you and being so focused for that period of time. I had heard much about game jams, but I had never actually participated in one. After this one I’m sold. I can’t wait until the next one!

Session description:

The iPhone has a very powerful engine under that shiny hood when it comes to floating-point computations. This is something that surprises a lot of programmers because by default, things can slow down a lot whenever any floating point numbers are involved. This session will explain the secrets to unlocking maximum performance for floating point calculations, from the mysteries of Thumb mode, to harnessing the full power of the forgotten vector floating point unit. Stay away from this session if he thought of reading or even (gasp!) writing assembly code scares you.

• Presentation slides (pdf format)
• Sample project

Thanks for everyone who attended the session and for the great feedback so far. If you’re going to be in China next month, I’ll be giving a very similar talk at GDC China.

Session description:

This session will describe the iPhone performance optimization lessons learned through many hours of tuning. We’ll start with an overview of the performance analysis tools available on the iPhone SDK to help you narrow down your performance bottlenecks. Then we’ll cover the best way to set up your render loops, rendering best practices, how to deal with the limited memory, or even how to drop down to assembly to use the forgotten vector floating point unit.

#defining The Problem

The first approach that came to mind was to use #ifdefs. Hopefully, if I did things well, it wouldn’t require too many of them. As soon as I gave it some more thinking, it was clear this was a pretty flawed approach.

I like to be able to create a build with zero human interaction: Press a button, wait, and the build is ready. I don’t want to have to do any manual (read, error-prone) steps. So I couldn’t just have an #ifdef that I turned on and off depending on whether I was building the lite version or the full one. I can get around that by creating a new configuration in XCode, except that it wouldn’t be one, it would be one for every existing configuration I already have: Debug, Release, Distribution Ad Hoc, and Distribution App Store. So this would make a total of 8 configurations. That’s rather ugly!

In case the explosion of configurations wasn’t ugly enough, there was one other, even bigger problem: An #ifdef wouldn’t allow me to change the assets included in each version of Flower Garden, and, most importantly, I couldn’t change the Info.plist file to have a different bundle id (although maybe I could change the Info.plist for each of the new configurations and point it to the new one).

Not an attractive option. So how else can we do it?

New XCode Project

The idea is straightforward: Make a copy of the existing project for the full version of the game, and change it in any way you want: Remove resources, add new ones, change Info.plist, etc. You can still share common source files and define a preprocessor macro LITE in the new project to #ifdef parts of the code.

This approach sounds more promising, until you realize that changes made to one project don’t carry over to the other one. So if you’re done developing the full version, and you create the lite version at the very end, maybe that won’t be a problem (although, how can you be sure you’re done?) And making changes to two separate projects is never fun.

You could improve things a bit by starting out the lite version as a branch in source control. That way, changes made to one of the branches can (hopefully) be merged back into the main line or another branch (have fun merging xcodeproj files). I think it’s because I’ve had the displeasure of working in projects that went totally overboard branching, that just the word branch makes me recoil in disgust. Yes, this method might work, but it seemed cumbersome and error prone.

Any other solutions?

Stay On Target

It turns out I kept thinking in terms of a solution I could have implemented in Visual Studio (that’s what I get for spending so many years working with it). But fortunately we’re not in Windows-land anymore. This is XCode, and XCode totally rocks.

XCode’s build system, once you wrap your head around it, is much more flexible and natural than Visual Studio’s. It’s much more like a make file (and I say that in a good way–I do like make files!). You have files, and then you have targets. And there’s nothing that says a file can’t be in multiple targets (and the file only appears in the project once). Once you have multiple target, whenever you add a new file you have the option to add it to both targets the same time if you want. Perfect!

My Flower Garden project contains about 15 targets: 7 “engine” libraries, 7 test executables for each of the libraries, and one main executable target for the game itself. So the (now obvious) solution, was to simply create a new target for the lite version, in that same project, with the same files. It turns out this solution had all the advantages of the previous approaches with none of the drawbacks.

Lite Target Details

Once I landed on the target idea, it really was quite straightforward to create the Lite version by following a few, simple steps:

• Make a duplicate of the target for the full version. Just right click on the full target, and select duplicate.
• Rename new target to something else (Flower Garden Lite–I’m highly imaginative when it comes to naming things like this!
• Make a duplicate of your Info.plist (InfoLite.plist)
• Change the info.plist file setting for the lite target to point to InfoLite.plist
• Edit InfoLite.plist to have a different bundle identifier and maybe a different bundle display name (the name that’s going to show up under the icon on the iPhone).
• Add a compiler define to the lite target called LITE or something like that. That way you can #ifdef a few parts of the code depending on the version you’re compiling.

And that’s almost it. There’s one more trick that made my life a lot easier. It turns out that you will definitely want to change not just some code, but some assets depending on which version you’re using. So maybe you’ll have a Wall.png texture in the full version, but you’ll want to have a different version of that texture in the Lite version. I started out creating a new file called WallLite.png, but then it quickly cascaded into a bunch of code changes loading either Wall.png or WallLite.png depending on the version and it was ugly and time consuming.

A much better approach is to rely on the resource copy step of XCode. By default, XCode will grab the resources in your project and copy them all in the same folder, flattening the hierarchy completely. This can be a pain if you have resources with the same name organized in different folders because they will clash. But here we can use it to our advantage to supply different versions of the resource for the full and lite versions.

Just create a Lite directory and put any variations of your resources there. Then, in the Resources Copy step of the target, remove the resources you’re replacing and add the ones from the Lite directory. Whenever you build, XCode will put those new resources in the same place where the full resources were and your code won’t have to change one bit. This trick works even with xib files, which is great because I had to modify one of them to reduce the number of pots in the garden screen.

Once you have that set up, the rest is just a matter of deciding what functionality goes in the lite version and how it is presented. It can be as simple or as complex as you want.

In the case of Flower Garden, it was very straightforward. I limited the number of pots to two, and the number of different seeds to three. So I just had to change a few resources and add a couple of #ifdefs with the number of total pots and seeds. I also removed the resources that weren’t used in the lite version (the seed data for all the unavailable seeds for example).

Flower Garden lite was finally approved and it has been available on the App Store for a few days. So far it has been downloaded several thousand times, it has been very well received, and has definitely bumped up the sales of the full version. Definitely a few hours well spent!

[1] The lite version took a couple of hours to create and a month to approve by Apple.

[2] It was something I wanted to have created from the beginning, but my hands were tied because email bouquets were being sent through my server and I had a maximum number of emails I was allowed to send per day because of spam limits. Fortunately, as soon as the 3.0 OS was released, apps were able to use in-app email and that restriction went away.

There’s a darker side to Apple’s randomness. Something developers have been complaining for quite a while and it’s just getting worse: The approval process.

This is nothing new though. For a while developers have been reporting random rejections by Apple. Some of them extremely unfair and illogical.

A few months ago, if you got hit with one of those random rejects, it was annoying, but it was bearable. Usually a resubmit would get approved in under a week, so it was possible to fix whatever random thing Apple flagged down (or show them that it wasn’t an issue), and resubmit without wasting too much time.

Now things are different. Supposedly 95% of apps are approved (or rejected) under 14 days (although my informal and biased survey shows very different percentages). A mistake from Apple rejecting an app doesn’t cost you a week anymore, but perhaps as much as an extra 3-4 weeks! That’s a big deal for a company that’s trying to time the release of a product.

So far, I had been one of the lucky developers and I never got a rejection from Apple with Flower Garden. Actually, updates were usually approved withing 7 days to the hour (very suspicious, isn’t it?). But my luck ran out and I joined the group of developers hit hard by random and unfair updates.

Two days ago, Flower Garden 1.7, which had been in review for 24 days was rejected with the following explanation from Apple:

Dear Noel,

Thank you for submitting Flower Garden to the App Store. We’ve reviewed Flower Garden and determined that we cannot post this version of your iPhone application to the App Store because your application contains pricing information in the application, located in the “More Games” page. Providing specific pricing information in this location may lead to user confusion because of pricing differences in countries. It would be appropriate to remove pricing information from your application.

Once these modifications have been made please upload a new binary using iTunes Connect

Regards,

iPhone Developer Program

I was completely floored when I read that email. So apparently displaying a web page with prices for other apps is not allowed unless you localize that based on the language settings of the iPhone. How many apps are doing that? I doubt many (any?) are doing it. I can certainly bring up piles and piles of other games that are showing non-localized prices. But precedence is clearly not an argument with Apple. Even previous versions of Flower Garden had that exact same view with prices and it wasn’t a problem! Random reviewer strikes again.

But wait, there’s more. The prices are shown on a web page fed through my server. I made that change in 30 seconds and emailed them back, hoping they could simply re-test that functionality and approve it on the spot. No, that would be too easy! I had to resubmit a new binary and start the approval process again! I just gave them the change to cut back their work to a fraction of the time (supposedly they had tested other things that they’ll have to re-test because they have no way of knowing I didn’t change/update anything else). Sigh! I resubmitted it and I’m hoping for a quick approval, but somehow I’m ready for another 24-day wait.

So this morning I was excited to receive another email from Apple, I open it and…

Hello Noel,

Flower Garden Lite cannot be posted because it is a feature-limited version. Free or “Lite” versions are acceptable, however the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version.

Users can view unlockable seeds on the “Seeds” tab but cannot access them in the Lite version of the application. Please refer to the attached screenshot for an example.

Please upload a new binary and correct metadata using iTunes Connect .

Regards,

iPhone Developer Program

and they attached the following screenshot:

Users can be unlockable seeds but can’t unlock them? If you follow the included tutorial (2 messages) you unlock the first one. Another message tells them that growing the second seed unlocks the last one. Did they read that, or did they see a locked seed and had a knee-jerk reaction?

I replied to their email right away and explained how to unlock them. I’m afraid I’ll get an email back tomorrow asking me to resubmit and throwing Flower Garden Lite at the back of the queue. I hope not, but I’m prepared for the worst.

It might just be slightly annoying for hobbyist developers, but all of this is making the App Store very difficult to build a reliable, sustainable business around it. The lack of visibility, random approval process, unpredictability, and lack of direct contact make it impossible to have a reliable process or combine release dates with other events such as PR or marketing campaigns. At this point, I would even consider a “professional” iPhone developer account that costs $1K per year and gives you a direct contact in Apple and better visibility and predictability with the approval process. Otherwise, if things continue this way, I’m afraid that professional developers will only put up with this for so long and are soon going to consider the iPhone as a secondary platform and they’ll move on to other pastures like the PSP Mini or new opportunities that come up.

iSimulate consists of two different parts: The iPhone app, which you need to purchase through the App Store, and a static library that you link with your program. Once your app is using the library, launching the iSimulate iPhone app lets you connect your device to your app and forward accelerometer, touch, and GPS events. In other words, most of the things the simulator doesn’t do natively.

iSimulate definitely passed my picky installation requirements with flying colors. I was afraid the installation would hook up with existing framework libraries, add new configurations, and in general mess up my system. Fortunately, hooking up the iSimulate library couldn’t be easier: Copy the provided .a library anywhere you want, link with it in your app (don’t forget the -ObjC linker flag), make sure you’re using the Core framework, and you’re good to go. That simple. That’s how I want external libraries to work.

You don’t even need to initialize anything. Just launch your app in the simulator, launch iSimulate on the iPhone and it detects your program running and lets you connect to it. The iPhone app itself even looks very pretty and polished. The overall package is definitely very professional-looking.

From there, any touch on the device is forwarded to the simulator. So you can finally do off-center multi touches, or two touches that happen at different times, or even 5-touch events (the max the iPhone support). The other big one is being able to tilt or shake your device and see the game react correctly on the simulator, which is would have been very handy when writing the accelerometer code to move flowers around in Flower Garden, but would almost be necessary when you’re making heavy use of accelerometer input for games like Sky Burger. Finally, it also claims to give you location information, but I didn’t have an app I could easily test it with.

Flowers affected by gravity on the simulator

Another situation where iSimulate is a life savior is when trying to capture a video of your game. If you rely on multi touch or accelerometer features, then your only options are to either hack in something yourself, or dig out a physical video camera and record it the old-fashioned way (which is surprisingly time consuming and creates less-than-ideal results). With iSimulate you can still use a desktop video capture software on the simulator and create a top-quality in a fraction of the time.

Not everything is perfect though. I thought the forwarding of touch events would be incredibly useful, until I realize I have no idea what I’m about to tap because the program is running on the simulator, not on the device. So I’m just making a guess about where my finger is going to land. It’s not even like a mouse cursor that you see where it’s going and then you click. You’re literally tapping blind hoping you touch what you wanted. That works with a static UI, but if you have moving elements you need to touch, you’re totally out of luck. I wonder if they could extend iSimulate to capture the image from the simulator and forward it to the iPhone. Even if they only refreshed the image a few times per second, that would be enough to make touch input a lot more friendly.

There’s another big problem with touch input though. From their docs page, iSimulate works great with OpenGL apps, but doesn’t work with the following UIKit controls: Keyboard, UIScrollView (including MKMapView), UIPickerView and UITableView. Wow! Apart from the keyboard one (no big deal, we have a real keyboard attached) the other ones are pretty major. I’m sure they have a good reason why, but I can’t imagine what that might be from my knowledge of how the touch even system works (anybody from Vimov care to comment on that?). Heck, I’d even be willing to add some extra code to my app to hook directly into iSimulate input events if it means it would work with those classes. Apart from that, I found one case in Flower Garden where iSimulate failed: Touching the bouquet tag to bring up the editing mode. It’s weird, it would let me touch-drag it to move it, but it wouldn’t go into editing mode.

The accelerometer input worked flawlessly, but here iSimulate has some competition from Accelerometer Simulator, an open-source app plus library to forward accelerometer data from the device to the app. It’s not nearly as slick as iSimulate, but it’s free, so that migth be a more attractive solution for some people.

Overall, is iSimulate worth the $32 price tag (it’s $15.99 at the moment)? I would say yes if you’re developing OpenGL iPhone games with heavy use of multi touch and accelerometer input and you’re planning on making money from them. In that case, you’re better off spending an hour of your time polishing the game (or taking a break from programming) and buying iSimulate. However, if you’re using UIKit objects or you just need accelerometer input, then you might be better off just using Accelerometer Simulator. If Vimov can fix the UIKit input and display the output of the simulator on the device, iSimulate would become an indispensable tool in every programmer’s toolbox.

Obviously I’m biased when I say the class is going to be awesome (which it is), but I can also say with total honesty that 360iDev is an incredible conference. It’s very different from WWDC, but that’s what makes it so great: It has top-quality content and speakers, but it’s small and intimate, so you get to meet and hang out with all the other speakers and participants. It was at the first 360iDev conference back in March that I met Keith and Owen (among many other cool developers) in person for the first time and that’s how App Treasures was born.

So if you’re on the fence, I hope you give it a try. See you in Denver!

Identity Crisis deals with the horrors of a CRC clash on a resource right before submitting the gold master. And The Programming Antihero shows a fairly common trick in the games industry to get that extra memory after the artists and designers swear up and down that they can’t cut any more content.

Nothing like a good dose of reality to make everybody feel better about their own code