What Went Right

1. A Simple Idea.

When I chose the first project for Binary Solo’s foray into iPhone development, I personally chose a very simple idea.  I had no clue about the programming language that would be used, the tools, or anything else really, so I knew that we had to make sure the first idea was simple.  Innovation can wait.  I think going with the wordplay genre was a good choice, and I love games like Taboo.  I decided to make something similar to that to take a lot of the decision rules from the code to the user.  As a bonus, this allows for users to create house rules since the game itself does not have any method to enforce what they say.

From a programming stand-point, this game was simple in technology.  The only features that the user visibly sees is buttons, graphics, and text.  The most complicated feature was adding custom phrases.  The iPhone SDK already provides the code to create buttons and display text and images, so it was more about using what was there.

2. Objective-C 2.0 works like C++ & C#

I was afraid that I would be battling a new language tooth and nail, however that was not the case.  There were a few expected mis-steps figuring out some of the Objective-C quirks, but for the most part it was an easy transition.  If I could not quickly figure out an Objective-C based solution, I could always implement a C++ one.  This was almost never the case, save for one, but it provided a fallback which made the actual coding process less of a transition and more of an extension.  As a programmer learning a new language always has its follies, but they were greatly reduced in XCode.

3. Amazing, Quick Assets

I think Guess What? looks and sounds excellent, which was in no part thanks to me.  From the start of the project I made sure that I had consummate professionals on hand to provide assets, and I think they really delivered.  Phil Davis whipped up the logo based on some programmer art, white-board, chicken scratch and turned out a pretty logo.  Promptly after that he created the actual art for the game.  I had only made a few placeholders before I got the email containing a whole slew of backgrounds and buttons.

The other half of the assets, sounds, were also just as prompt and awesome.  I contracted another friend, Arin Mann, to create the background music for the game.  I had a good idea of what I wanted, but that doesn’t exactly translate to the keyboard very well.  I told him I wanted that same excitement of recent game shows, something that will build a sense of urgency in the players as time counted down.  What he delivered within a week or two was nothing short of incredible.  It had the feeling I wanted to capture.  It actually had a useful function of re-enforcing the time limit.  In fact, a lot of first impressions are praise about the music.

4. No Deadline

Binary Solo was and is not focused on iPhone development.  There, I said it.  That isn’t to say we aren’t going to do a bit of it for now, but we’re flexible.  This project was more of a pet project than an official studio-wide, all points bulletin project.  I had the flexibility to code for a few hours a day, a few hours a week, and while I was going through all of the wedding shenanigans, a few hours a month.  I was able to go at my own pace because we had no deadlines, or expectations for that matter.  This took a lot of pressure off of my shoulders.  Had I needed to get tasks done for a demo or make sure no one had tasks with dependencies falling on me, I might have coded some quick hacks and tempers would have flown (during the wedding month, approximately) to new heights.  Luckily, that was not the case.

5. Support Framework

Due to the nature of this game, and of this platform, I knew that the game could easily be extended later.  This shows as we submitted our first update shortly after release.  (Although it sat a while waiting for approval.)  The way that Apple handles updates is nice, so we knew from the start that we could send plenty of updates down the pipe.  All of the data is in an easily editable, underlying structure that allows us to quickly push it through.  I’d like to claim this as my victory, but it’s mostly Apple.  I have already started on incremental updates and so far the process is very simple.  With the first update down, I’m ready to throw some time into the next one so we can really see Guess What? shine.

What Went Wrong

1. Trying To Use Interface Builder

For some reason I was very insistent on using the Interface Builder.  It was going to be a very simple project, and it should be able to handle it.  I figured the time savings of using a Designer based tool to generate code would help.  Unfortunately, I think that obscured the code-base and made it harder to track down the bugs that were found.  There were a lot of issues in the beginning that were a simple misunderstanding of what the Interface Builder did for the developer, and what the developer was expected to do.

Despite that, I kept pushing on and using it because each time I thought the Interface Builder was finally mastered.  Then I would be surprised again.  One thing that the Interface Builder lacks is any visible code generation (or I just didn’t find it.) which is a real pain coming from Windows using Visual Studio’s Designer.  A level of magic exists between how the Interface Builder works and what I get to see and handle in the code myself.  This disconnect lead me down the wrong path far too many times during development, especially so with a nasty slow-down bug that almost had me switch entirely from Interface Builder.

2. Apple Sample Code

Now, I’m not slamming Apple’s sample code.  However, once or twice the sample code lead me astray.  There are little gotchas and quirks that the sample code conveniently does not handle, and when you try to do something slightly different, you might run into those.  A specific issue with timers comes to mind where I had followed the Apple sample and then tried to re-use a timer.  Bad idea.  Very bad idea if you were following what they were doing with their disposable timer.  That’s not to say that the sample code did not help me.  Far from it.  Sometimes the sample code was a saving grace.  It’s just very annoying when you end up debugging an issue for a few days and then find a buried post on a Google Group after a few hours of searching and find that one guy who notes, “They did not cover this in the Yadda Yadda Example, but do this one thing before you use their code or else.”

3. Getting the Data

Apparently people buy databases, mined data, and libraries for a reason.  I did not even consider creating anything robust for all of the phrases I would need in the game.  A definite lack of foresight on my part.  I ended up manually entering all of the phrases into the game.  Only half way through the process did I create a tool to speed it up, but even then it was nothing robust.  If we are going to update and support Guess What? more extensively, I will definitely be writing a better tool to handle and automate the process a little more.  (So get all your friends to go buy it. )

4. iPhone Provisions, Certificates, and Profiles (Oh My!)

I had an iPod Touch.  I bought a Mac Mini.  Now I am all set to develop iPhone games right?  That’s what I had envisioned based on how easy it all seemed in the forums and success stories.  I did a little research and found that in order to test on my iTouch I would need to be a paid developer.  That was a hidden cost I was not fond of.  I thought I could hold off until the end, but eventually I realized the Simulator was just too limiting sometimes and we paid our fees a little early. That is, after the fiasco that was getting Apple to accept us as a company.

Now, we thought, we can go ahead and put our app on the iTouch and test it out for real.  However, there was another step to go through.  Because any iPod Touch or iPhone can be hooked up to a Mac to debug your app, Apple had to put in some pretty steep protection against letting XCode install apps all willy-nilly.  You wouldn’t want to have people passing around source code to bypass the App Store.  In order to do this you have to create a Certificate for your Mac to install apps, a Profile for the device that lets it accept the app, and then a Provision that tells XCode it is all right for X app to be put on Y device.  It’s an entirely lengthy process to go through the first time and I had to go through it a few times to get myself and others set up to test it.  I don’t know if this is 100% what went wrong material, but it sure was frustrating.  Then on top of that there’s a whole Ad Hoc system so that you can get other people to test the game (or from what I hear, preview apps for review sites). The whole affair is kind of a necessary evil to learn.

5. App Store Rejections

Before we submitted to Apple, we thought we had fixed all of the bugs.  However, because of the way that Guess What? copies data to your iDevice, there was one that slipped through the cracks.  Since I already had installed the game on my device, certain files already existed and did not need to be copied.  This came back to bite us in the form of an App store rejection.  Of course, this is a nine day process that takes a while.  After finally finding the bug and fixing it, we resubmitted. However, this time I forgot to set the release date and we never really hit the front page of the store.

Any iPhone App marketing wizard (No one has perfected it yet. It’s still magic.) would tell you that sales are greatly affected by not being on the What’s New, What’s Hot, or Featured lists when they come out.  Maintaining sales relies on some Top 100 action and if you can’t capture it right away, it’s an uphill battle to get there.  This compiled on top of a missing Lite version and no big marketing push at launch really hit us in the wallet, the hardest place to be hit after a game’s release.

The Numbers:

Programmers: 1

Artists: 1 (Contract)

Audio Designers: 1 (Contract)

Testers: 2 (Contract)

Dev Time: 4 months