This post was originally intended to be published in June. I held off publishing it though, intending to expand upon it. In retrospect, it’s pretty damn big, so I’m just going to let it ride, and address TextTumble’s approval process and release process in a separate post. -CZ

We made it! 249 days since the first source code commit, TextTumble is finished. At around 11:30 PM, I cracked the champagne

and sat back to enjoy the prospect of a job completed. While there is still some additional features that will be fit into the online scores and profiles, I feel very happy labeling the package with “1.0″ (A version number whose significance can be daunting to a first timer like myself). As it sits in Apple’s review queue now, I’d like to give you an abbreviated history of the game’s development. I’m not going to offer much in the way of advice or instruction here; this is just telling a story.
(more…)

A common technology use for a word based iPhone game is the inclusion of an SQLite database containing the word list of the game, to be queried when checking for potential matches to a sequence of characters. While the ease of offloading data management to SQLite is certainly a boon (as opposed to creating your own data structure to load the word list at run time), it is important to keep several things in mind when doing so:

* Normalize your data. If you are querying the database for words, for example, ensure that your input data form matches your database data form before you issue your query. Using a dictionary as an example, make sure the words in your dictionary are either all upper-case or all lower-case, and that your input data matches. The difference between SELECT word FROM dictionary WHERE UPPER(word) = UPPER(?) and SELECT word FROM dictionary WHERE word = ? is at least n + 1 calls of UPPER. Buy yourself that time with in advance data treatment.

* Query on change. Chances are, your game state will only need to query when some user input or game event occurs. Should this be the case, your data structures should be such that they only query the database when absolutely necessary. For instance, using a word based game as an example again: if the user has spelled CAPITULATE, and the I in CAPITULATE is removed, your data structure should already recognize that CAP and LATE are still words (based on the previous query that also showed CAPITULATE to be a word), and not query the database again to rediscover this. While it places more of a burden on your game logic, you’ll avoid the cost of another scan across your dictionary against each potential word candidate.

* Indexes. This should be obvious, but your database should be aggressively indexed if it will be queried during the update loop. Create UNIQUE and PRIMARY indexes as relevant, and do so in advance.

* VACUUM. The VACUUM statement cleans up fragments left behind from successive INSERTs and DELETEs. You should VACUUM before shipping your database to clean up any work you’ve done in development, and if your database will be modified by the game, it’s a small thing to issue the statement during your game’s quit-cleanup phase.

* Cache failures or successes. Consider creating an in-memory cache of failures or successes ( whichever is more likely to happen based on your requests ), and use it often. You can whip together a simple ring buffer in no time, or you can create something more complex that expires stale data based on access count or time of last access.

Most of this advice has been inferred through repeated performance optimization of Text Tumble. If you’ve decided to do your database access in the update loop, this should help you shave off a few hours from your optimization work (and get closer to your target constant FPS ).

It’s a tough thing, moving between web development (a world which is dominated by scripting languages) and game development. I’ve been programming computers since I was 16, and for the majority of that time, I’ve been /paid/ to develop webpages, and /dreamed/ about developing video games.

Now, here I am at 28, finally doing that. While I’ve worked on video game mods in the past, those really aren’t quite the same thing as doing a from scratch video game. (Even one that, were it not my own, I would think of simplistic – embarrassingly so, when compared to other games) And, while I certainly can make my way among the major points of a more explicit memory management language (additionally, where resources may be constrained, though saying that the iPhone is memory constrained may receive different reactions from different developers), it’s rather like saying I can speak Spanish. I’ve been trained to do so, and have been able to in limited situations, but my day to day usage is far different- (see, Ruby, JavaScript, Python, et al)

So getting started on iPhone development, while not impossible for me, introduced me to a different set of problems than I’m used to solving in web based apps.

* OpenGL: I’ve played with OpenGL in trivial apps off and on for years, always swearing I’d do a better job learning it, then never getting around to it. Now that I actually AM using it, I feel like I have a lot to learn when it comes to how colors combine when objects are rendered over each other, or image bit alignment. These aren’t things I need to know in the simple case, but I can see how becoming much more familiar with these things in the future will open a lot of graphical options to me.

* Data structures: Believe it or not, this one actually bothers me quite a bit. I’ve spent a lot of time thinking about how to represent a list of entities in memory where my primary method of access would be spatial. It may be naive, but I’ve been constantly thinking about how a “spatial hash” may work, and be implemented. I’m kicking myself now for my silly list style representation, when I could have spent just a day looking through the Algorithms book beforehand and implemented a balanced interval tree instead. This is a common thing for me, working with real time “physical” objects now – learning to reference my books and the internet FIRST, not after the fact.

* Appreciation for physics: I feel like knowing and learning more about physical simulation will change me from being an average developer to being a /good/ developer. While I don’t think I’ll ever author a paper on a topic, being more aware of where to turn for an equation that describes some physical phenomenon that accomplishes what I need (and being comfortable in how to translate that to actual code) will be invaluable.

* State : This is infuriating for me, as I should have known better. Maintaining state, changes to state, and centralizing access to this information is something I should have known right from the beginning of TextTumble. While the code is by no means unmaintainable, I see now the bad habits forming through independent has_done_x state flags littered through the code. Surprisingly (to me), abstracting all this not only would reduce the noise in source code, it could also lead to efficiencies in rendering by abstracting the state change facility of OpenGL. Only sending state changes to the hardware when they are necessary (obviously in retrospect) leads to an increase in framerate, which will obviously pay off later on.

There’s more of course, but the sum is: I really couldn’t be any happier than I am right now, (re)learning things and finally making a game.