Oddage Postmortem

Rands said it well: Shipping version 1.0 won’t kill you, but it’ll try. I have the luxury of a full-time job, so getting Oddage 1.0 out the door was made less painful by the reality that survival wasn’t on the line. Still, making a good product is work. I’ve told you about the evolution of the interface. Here’s how Oddage got out the door.

I’m not a Programmer

Well, to the extent that’s necessary, I am now. But I’m not the guy who has been doing it since 12 years old, who can instantly visualize a design pattern in his head, who can take spaghetti code and make it self-documenting, beautiful, elegant, efficient. Wil Shipley is probably that guy, come to think of it. His Pimp My Code series leaves me trembling in awe and inadequacy.

No, in truth, I am a product guy. I see in my head the ideal configuration of certain pieces to solve a problem and then I start building. These days, when you have a limited budget and resources, being a product guy means you build software.

When I was a kid, I was obsessed with Star Trek: The Next Generation. I especially loved a gadget from the show called a tricorder. When the day came where a tricorder toy was available for purchase, I did what any eight year old boy would do and begged my mother to take me to the store for it. (After we were done at the Star Trek convention.) She obliged me, seeing the abject desire in my eyes for this simple object in the Sunday paper toy circular. When I got it, it pleased me about as much as any toy ever could.

Then my eight year old detail-oriented brain kicked in. “Hmm,” I thought. “The blinking lights on the outside. They’re just painted on. They don’t blink like on the show. Why didn’t they care enough to really make this cool?”

And a product designer was born. I still loved my Tricorder, but I desperately wanted it to be better. Just because it felt like it should be and could be. The knowledge of this missed opportunity gnawed at me for years after.

I need to do this

I spent most of my teen years desperately needing to create something. But I’m not artistic or especially handy. I’d get these absurd bursts of restlessness and I couldn’t make them go away. I wanted to build. I didn’t know what I could build. Later in life, I now realize this is my product creation bug biting me. It feels good for me to create a product. It salves my soul. When I am not engaged in the creation of a new product, I become depressed, irritable, restless. Like I said, for awhile, I didn’t realize the root of this. I figured it out by accident when I started building things obsessively in Second Life. In Second Life, the scripting language is C-style, which was hard to learn when you have… no background at all in code beyond HTML. I learned anyway. It worked out. I designed products that I loved and made real money doing it — about $5,000 over the course of two years. Decent money for a hungry college student working in his spare time.

I love the iPhone. The tricorder and other scifi gadgets primed a lifelong desire for a computer that I could carry around with me. Nothing satisfied that desire until iPhone. Now that I had a platform I loved, I wasn’t content to passively absorb the products other people built. The product bug bit really hard. So it was that I decided to learn Objective-C and Cocoa. It was hard. Nearly impossible, it seemed, at times. But I did it anyway, because I need to design product.

What is Cocoa?

I knew in only the most basic terms what Cocoa actually was. I needed a book to gently guide me into the world of Apple’s APIs and object oriented programming. And I needed it to be specific to the iPhone. Unfortunately, such a book didn’t exist. Apple kept a strict NDA surrounding the iPhone SDK and not a word was published by third parties. Moreover, the SDK was in flux for the better part of 2008, making it an unwise financial decision to attempt to publish a book that could be obsolete weeks after going to press.

The next best thing is Cocoa Programming for Mac OS X, 3rd Edition, by Aaron Hillegass. The book assumes some comf0rt with C. And that’s all. It was as close as I would get to perfect, covering as it did the Xcode IDE and Apple’s Cocoa API for the desktop. It couldn’t teach me iPhone development, but it could give me an understanding of the tools I’d be using.

It was still hard.

For one hour, every night, for months, I administered what I called my “Programming School.” I sat in a quiet room and dutifully went through one of the lessons in Aaron’s excellent tome. I carried the book with me everywhere, even passing a day in a Jury Duty pool by working through programming lessons.

Then one day, something happened. After many weeks of slogging with minimal comprehension, I decided to start writing down specific principles of Objective-C in a floppy, softcover moleskine notebook. In the middle of picking apart some source code I’d found, I was copying some notes down about instance methods versus class methods. Something incredible happened. Deep in my brain, a new connection was made, resulting in a palpable mental jolt. I looked up at the screen and it was like the climax in the first Matrix movie, back before they started sucking. Where once there was a wall of code that to0k significant effort to decipher, I now saw an elegant, intelligible system. I soared through the project’s .m files, for the first time grasping the meaning of the code as clearly as if I were skimming a James Herriot novel.

The Trials

So now I understood Objective-C and began to digest Cocoa. It was promising progress, but just as even the smartest 2nd grade writer is going to have a hard time penning a college level term paper, my reach still exceeded my grasp.

UITableView

Cocoa Touch has a class called UITableView. If you’ve ever edited settings or used contacts on your iPhone, you’ve used UITableView.

It’s a great way to organize and present information. It’s also a big pain in the ass. I knew that table views were essential to the meta portion of Oddage. There’s just no better way to present configuration options and high scores. They’re also a familiar interface element, reducing the learning curve for a user new to the application.

Which meant when I spent six hours one Sunday afternoon trying to learn how to use them, I couldn’t succumb to the urge to give up. I’ve seen crappy nibware on the App Store whose config views were implemented through some hideous method unrelated to table views. I couldn’t bring myself to do it. I don’t ship crap, came the mental refrain. So I stuck to it.

Honestly, I don’t remember how, but I sorted out how to make a UITableView implementation work. Then I made it better because I like to read what smart people have to say and Fraser Speirs has smart things to say about how to best make a UITableView.

UITableView wanted me to quit.

I refused.

High Scores

High scores are a pain in the ass. My initial high score implementation was so buggy it could cause the whole app to crash on the off-chance your final score was the same as one already in the list. That rarely happened for me, so I left it alone for awhile. It even made it into the first beta build. A tester caught it within the first hour.

If you’re wondering, the best way (I’ve found) to store a high score list is to create an array containing a dictionary for each score entry. In each dictionary, you can store the score, the name of the player and the date it happened, plus any other data you need, all tidily labeled with keys of your choosing. In Cocoa, you can use NSSortDescriptor on the array to sort it against any key you like.

High scores is a function that is tedious and tedious is not what I love. Still, I’m glad it works and I’m glad I did it right.

MVC

Apple advocates a Model-View-Controller design pattern for iPhone applications. In simple terms, this means that you keep application data management separate from the code that presents that data. MVC took awhile to completely grasp and I’d be a liar if I said I was now expert. Still, the first versions of Oddage made a mockery of the design pattern. I’m not obsessed with following the rules, but the MVC recommendation was a good one and by not applying its lessons I was making an application that would be impossible to maintain.

I decided to re-write Oddage, ensuring clearer boundaries between its internal components. The re-write was worth it. The code was infinitely more manageable the second time around.

Success

It wasn’t all an uphill climb. The stuff I learned developing the rigid, procedural code for my Second Life projects gave me some good background to build Oddage’s engine. For each turn in the game, I randomly select two categories of words, then randomly select words from those categories. The random selector is a series of for loops that manage a handful of dictionaries and arrays. Oddage underwent plenty of revisions, but that core engine of the gameplay exists to this day pretty much as I wrote it the very first weekend, aside from some improved memory management.

I also think the evolution of the interface was an outstanding success, both in terms of appearance and usability, but that’s all covered in another post.

Oddage was a gratifying foray into iPhone development. I’m already at work on my next app and Oddage 1.0.1 was just submitted for Apple review. In the iPhone SDK, Apple has gifted me with tools to make great product. That makes me happy.

Comments