My most recent decades have been spent writing programs on Windows computers using the C++ programming language. The transition to programming an iPhone app on an Apple computer using Objective C was daunting. I believe the story of how I fared might be a little interesting to other programmer types considering the same type of leap. (And along the way I hit on one really, really useful paradigm that I think “sealed the deal” and would like to recommend to others.)
This post is “A Progression of Prototypes (or, “The-Idea-That-Sealed-The-Deal”).”
In addition to being frustrating, I can definitely say that the early days of iPhone application development are darned expensive. It’s a good thing that the money flows like a rushing, refreshing waterfall once you’ve fielded your app! (Just kidding…who knows?)
You can’t develop Apps on a PC, so you need an Apple computer. It’s almost like these Apple guys are exclusively in it to sell you hardware and stuff, otherwise why wouldn’t you be able to “get your Objective C on” from your Windows box? How can they possibly make money like this?
Further, you can’t really run/field Apps with just the iPhone “simulator,” because several things run differently on the simulator than on a real phone (in-app purchasing being a prime example)…so you need an iPhone, too. Thankfully, having an iPhone has its own benefits, though (sorry Apple fans) I can’t exactly say the same thing for my spiffy new Apple computer. While there are many things to dislike about the Windows experience, I’m pretty used to it by now…and, well, let’s just say that the Apple “Finder” tool is not the sharpest knife in Apple’s tool belt. Also, the XCode development environment (compiler) is free, which is a good thing, but it, too, is an uncooperative beast – if you don’t agree, just try to get your build settings squared away from scratch for Debug, Release, and Distribution (with signed keys)! And testing your code for in-apps purchases? Ugh.
Anyway, enough grousing…Apple will probably withstand my meager complaints and will be happy to take 30 cents of every dollar my apps make, to boot.
I started with the Beginning iPhone Development book, progressing through “Hello World” and “Push this Button” examples, all using XCode for the development studio and Interface Builder for the screen layouts. The book is good for showing how to do this, and also makes a reasonable introduction to Objective C.
My real goal was to get some “buttons on the screen” showing the game layout, populate those buttons with words-a-la-Squramble, and see if there was actually a game there. My hand-drawn prototypes showed that there might be some fun to be had, but nothing beats trying to work through a real, randomized puzzle on an actual prototype.
Being a Windows (MFC) programmer at heart, my first instinct was to subclass the UIButton object so that “Squramble” (child class) buttons handled game operation. Those buttons could store the letter they were attempting to represent, could draw themselves using whatever slick graphical appearance I wanted, and could also handle the application of game state changes. This turned out to be difficult for a number of reasons, the primary one being that Apple doesn’t want you to subclass UIButton. (MFC’ers can subclass CButton all they want, but there’s a specific-but-not-obvious restriction against this in XCode.) The infuriating thing is that you can actually subclass UIButton all you want, but you can never get your own handlers to fire. Eventually, though, I was able to get this to work by using the Objective C “category” class extension feature, which is even more free and easy than C++ subclassing because it allows you to add any old interface to any old class that you want.
Here’s a look at an early version of the button concept:
Once I got the button to draw and react, I spiffed up the graphics a bit and invented some visual “pipes” that connect them so that the user can follow the words a little easier.
With buttons and pipes in hand, I started on some game logic. What happens when you tap a letter in the puzzle? This turned out to be complicated, but moreso because I was just plowing through it without an overall design in mind; I really just wanted to be able to play some puzzles. Wrapping my whole idea around a specialized subclass of UIButton was fragile and ill-conceived.
Eventually, though, it all came shakily together into the first iPhone prototype of Squramble, shown below. The pipe logic was really squirrelly, being all wound into the button class, and all of the buttons didn’t quite respond as I wanted them to, but at least you could work through the high-level idea of Squramble without hand-drawing the puzzle.
Obviously, this mad-dash-to-prototype isn’t the technique that sealed the deal. We all know this isn’t the way to program a real system, yet somehow it ends up being how many systems are really built. Oh well…in my case it was sufficient as a proof-of-concept alone.
After proving its concept, the mad-dash-to-prototype failed in all other ways. The Objective C class hierarchy for puzzles and letters was married right to the code that drew the buttons on the screen, and the pipe technology was unwieldy. Following the triumphant proving-of-the-concept, Squramble languished because the developer didn’t want to wrestle with the flawed design. Having to struggle with unfamiliar Objective C-isms didn’t help either.
The breakthrough came when I observed the in-progress version of IF Tracker, also by Looking Glass Software. While waiting for some art and food database assets, my partner was able to get his entire application working…it was sort of a “shell” for the app, but one that was 90% functional and lacked only the “polish” of the final artwork and the “completeness” of the food database. I said to myself, “I could easily get Squramble up and running (with a solid, pre-planned class design) if I didn’t have to worry about how pretty it was.” All that fussing with making pretty, animated buttons was keeping me from making a solid game model under the hood.
From there, I also observed that if this application was written in C++, progress would be meteoric compared to the Full Stop pace that had been established for some months on the Objective C prototype. As we have already established, I’m an old hand at C++, but a relative newbie on Objective C. And it turns out that you can easily use C++ classes in an Objective C-based iPhone app…so…
The Idea-That-Sealed-The-Deal was to design and implement my game logic without worrying about the way the game would be shown to the user. This, my partner informed me, was in fact a well-known programming technique called Model-View-Controller architecture (read about it in the Wiki, if you wish).
By switching to C++, I was able to build a very functional model of the puzzle logic needed for Squramble. This model was driven by a cheesy MFC-based controller that handled button clicks and user input. The controller and the model communicated the results to the screen through a view. Both the model and the controller were portable C++, but the view was a Microsoft-specific MFC C++ dialog. Progress in this area was absolutely amazing; a fully-functional and feature-complete prototype was done in 6 weeks (and do keep in mind that I also have a full-time day job). Things went so swimmingly, in fact, that I was able to build my own flavor of “achievements” into the model: the Squramble “ribbon”…and to hand-build over 120 ribbons to include with the game.
Here’s a screenshot of the cheesy Squramble MFC prototype:
If you have a game idea but are having trouble getting into iPhone programming for some reason, consider my Idea-That-Sealed-The-Deal. It doesn’t matter if your game interacts solely in the form of console input and printf()’s…that in itself might even be a good thing. You can build it in a way that you want to build it, using C++ even, and you can make it pretty later. Making progress = good. Complaining about how hard it is to make progress on the iPhone while in fact making no progress = not good.
This leads us to the next blog post, which talks about the wonder that is Cocos2d.