With the launch of the iPad I have decided to change what I'm working on. My previous iPhone project was mostly just a vehicle for me to learn Objective C, get familiar with UI elements and become comfortable with the general Apple way of doing things. I believe it has served that purpose. It's a shame to leave the project unfinished, but I have learned that if I don't nip a project in a bud it can suck too much time. I'm sure I will return to it at some point.

My new app is a game (duh) that will target both iPhone and iPad. I haven't decided if they will be the same app or two separate ones. I suspect the latter as I want to get it done asap. Focusing on one platform (iPhone first) will help tremendously.

I'm not going to reveal a lot about the game yet. I started a design document, but a fair bit of it is still gestating in my head. What I will say is that it requires a lot of physics. As such I'm diving into Chipmunk Physics API, which seems ideal for what I am doing. I'm also considering the cocos2d engine since it has support for Chipmunk built in.

I have a hard deadline in mind. I've given myself eight months to get it done. I am currently working by myself, but will probably call upon others for help with the artwork and audio. I want to get a nice prototype up and running first, though.

Let's see how this goes!

In addition to the technical aspects of my trials in iPhone programming I will also use blog this as a soap box to espouse my opinions about iPhone gaming in general.

First, I believe that having a "Lite" or "Free" version of your game is absolutely essential. Without it people will pass your game by unless it happens to have huge critical acclaim (Flight Control).

Apple changed this dynamic a bit in their latest update that allows in-game purchases from free apps. Now, rather than having two versions of your game (lite and normal), you can just have one. Allow the user to play some levels and then ask them to upgrade to unlock the rest. It remains to be seen if that strategy actually translates into a higher buy-in compared to the usual two-version method.

Another thing I've come across is that the lite version doesn't get to the interesting part of a game. You get to play the first few levels, which are usually the easiest and have the fewest features. When I'm trying out a game I want to see the full-spectrum of what I'd be buying. You don't have to show every single feature, but at least give me a challenge to let me know what I'll be up against.

As an example, the game MinMe does this. It's fun, but really easy to breeze through the levels offered in the base version before it asks you to unlock the rest. It would have been better to sprinkle in some harder challenges. I definitely liked the game, but wasn't willing to splash out for more when I don't know what I'd be getting.

On the other hand, the lite edition of Labyrinth recently added some levels from the sequel, Labyrinth 2. This was done very well as the levels chosen demonstrated some varied features from the full game. They didn't show all their hand, but still enough to whet your appetite.

One of the reasons for posting progress updates here is to document the problems I encounter during development on the iPhone. By doing so I hope someone will find it useful when searching around for the same issue. Basically anything that stumps me for more than a couple hours is good to write down. Some of these may be "duh, what were you thinking" type of issues, but that's all part of the learning process.

First up is a problem I had most recently where a UITableView delegate wasn't responding to the didSelectRowAtIndexPath method (message, whatever). This would only happen when the table was placed in edit mode. My searches found this link that answered it nicely.

This is one of those "duh" moments since it was just a simple property change. Still, if you don't know about the existence of that property it leads to wasted time and frustration.

I'm continuing to learn Objective C and the coding conventions employed by the iPhone software environment. I'm over the hump when it comes to understanding how to use Obj-C. The big hurdles now are learning the toolkit.

I have some forms displaying and am navigating between them adequately. I'm continuing to learn classes like TableViews, NavigationControllers, and more recently ImagePickers.

Some bugs that have caused me problems were related to Objective C being a weakly typed language. You can create an object of the wrong type and not find out about it until run-time when some method goes off to the weeds. Also, you can send messages (C++: invoke methods) to objects that are nil (C++: NULL) and the run-time environment won't complain. This leads to strange behavior later and haves you scratching your head as you trace back what happened.

The memory management scheme is also something I still need to fully understand. Objects are "retained" and "released" instead of explicitly freed. In my opinion this doesn't solve much when compared to C++'s "new" and "delete". Both ways have their benefits. It just requires a different way of thinking with regards object lifetime.

As happens with a lot of my projects, it is turning out to be more involved than originally anticipated. Not that I'm complaining. It allows me to learn even more aspects of the system and environment before jumping to a game.