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.
Read the rest of this entry »

In the course of working on a quick side project, I came across a few interesting items of note for those working on Objective-C projects.

I was looking for a way to recreate the behavior shown by some Core Foundation objects in that they may be cost-free casted to their equivalent type in the Cocoa framework. An example:

CFStringRef my_string = CFSTR("a string");
NSString* also_my_string = (NSString*) my_string;

It turns out that, should you have a need to represent a struct also as a subclass of some NSObject, you can do so by having your struct include a member of type Class (or struct objc_class*) named isa. The isa member is used by Objective C to access the table of methods and class hierarchy that your object (or struct, but we’re splitting hairs) is associated with. A much more elaborate discussion regarding the isa member can be found at Mike Ash’s website, which is damn near invaluable for learning more about Objective C.

Once you’e added the isa member to your struct, all that remains is to reflect your struct’s internal structure in the NSObject representation you’re creating. While it may seem obvious to some, it should bear worth noting that the order of declaration in your NSObject subclass should mimic the order of declaration in your struct. Here’s an example:

typedef struct {
  Class isa;
  int   some_number;
  BOOL  some_flag;
} MyDumbStruct;

@interface MyDumbObject : NSObject {
  int some_number;
  BOOL some_flag;
}
-(int) someMethod;
@end

Now that you’ve done this, you’ll be able to cast a properly created MyDumbStruct to a MyDumbObject instance. I say properly created because you will need to populate the isa member of your struct with the pointer to the Class object that correctly represents the class your struct will be associated with. You can do this by accessing the class method of the, ur, class in question. For example:

MyDumbStruct s;
s.isa = [MyDumbObject class];

That’s it – and here’s what you end up with in terms of capability:

MyDumbStruct s = { .isa = [MyDumbObject class],
                   .some_number = 2,
                   .some_flag = TRUE };
MyDumbObject *o = &s;
NSLog("My dumb object has a number: %i", [o someMethod]);

In my next post, I’ll show what I’ve been working on that actually uses this technique.

Addendum: This link elaborates on what I described above; it also describes usage of the @defs keyword, which will allow you to only have to declare the member variables for your Object once, and have them inserted in your struct at compile time.

My usual user interface experience with Apple software is of the pattern:

• Feel an app has a shortcoming
• Work with shortcoming
• Curse shortcoming in bars / Twitter / work
• Spend 10 minutes googling to see if someone else has experienced the problem, and find out the feature has been there all along, and has some shortcut key assigned to it
• Facepalm

So, predictably, when I was griping over the lack of a quick file navigation feature like Emacs’ C-X b or Textmate’s ⌘-T, a few minutes googling solved my complaint.

The Open Quickly option (shortcut: ⇧⌘D ) not only gives you quick file navigation, it also (as shown by the screenshot) gives you quick jump-to-symbol navigation. I can only say: sweeeeet. (And also, facepalm.)

(Update: Some minor clarification regarding the performance cost of eval())

Visitors to the site might notice that there was a drastic (and long called for) redesign of the site. It is not, I assure you, the sudden manifestation of artistic ability on my part; rather, it was some great work done by Erik Goens, which has made the website look like something a little better than “derelict”.

I’ve got lots to say about Text Tumble, and maybe even a little bit to contribute about Objective C (pending some exploratory work on my own part), but I’m afraid I don’t have enough ready yet to go in depth. So, in the short term, allow me to share a little bit of undocumented ERB capability that came to me by way of Eric Hodel’s Cached ERB Template class.

Background: ERB is the library used to drive most Rails templates. When you write a view template and use this form:

This is my html file, <%= @some_ruby_variable %>

it will be processed by the ERB library (which is part of your Ruby Standard Library) and turned into Ruby code which may be executed. You can see it for yourself in irb:

> require "erb"
> doc = ERB.new("this is my template <%= @var %>")
> puts doc.src.inspect

The “src” attribute of the doc variable is the Ruby code that will be executed when the template is rendered. You can evaluate it yourself, like so:

> eval(doc.src)

or use the .result method to obtain the evaluated template result, like so:

> doc.result

Each time you do this, you will evaluate the generated Ruby code anew. The cost of evaluating Ruby code programmatically is not trivial – it requires parsing and interpreting the string of Ruby code as if it were a separate file that had been loaded into the specified context.

You can bypass this by using some undocumented functions in the ERB library. The important method to consider in this case is the method named: “def_method”. def_method is a method that allows you to evaulate the ruby code and “compiles” it into a method, allowing you to call the method later on without re-evaluating the string.

For instance:

> doc = ERB.new("foo bar <%= @baz %>")
> class Test; end
> doc.def_method(Test, "call_dynamic_method")
> t = Test.new
> puts t.call_dynamic_method

def_method will take the generated Ruby source and evaluate it in a manner similar to this:

> doc = ERB.new("foo bar <%= @baz %>")
> method_name = "call_dynamic_method"
> method_source = "def #{dynamic_method}; #{doc.src}; end"
> Test.module_eval(method_source)

You can see a more elaborate version of this technique in the Rails source in ActionView::Renderable#compile!. That means that, if you are using Rails, that the performance gains from this are already applied to you (and have been since Rails 1.0). However, if you are using ERB on its own, it’s a good technique to have at hand.

I had to clean out a ton of spam comments caused by my momentary blog inattention. Sorry if I deleted any of yours!

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 ).

I was looking over the code behind the New Relic RPM plugin for Rails, and noticed a small bit of code in the following style:

@obj = SomeClass.new
# Do stuff
def @obj.a_new_method
  # add functionality
  # to obj, specifically
end

Without entering into the mostly futile discussion regarding the numerous goods / evils of this sort of monkey patching, it was a cool piece of Ruby functionality I hadn’t yet seen.

As I just posted, I recently had the chance to add JQuery style function chaining to my Spatial Query javascript library. By function chaining, I mean the ability to do something like this:


$("div.of_interest").css("border", "solid 1px black").show()


A useful technique in situations where you plan on performing multiple operations on a given set of data.

I went straight to the source to determine how to create that sort of functionality – the JQuery source, mirrored on GitHub by JackDanger.

The relevant code was in jquery/src/core.js. The simplified version of the technique could be stated like:

var jQuery = function(selector, context){
  return new jQuery.fn.init(selector, context);
}

jQuery.fn = jQuery.prototype = {
  init : function(selector, context){
    /*
      Acquire the elements in question
    */
    return this;
  },
  // The rest of jQuery's functionality would
  // be defined in this prototype, such as
  // .each, .find, etc.

};

jQuery.fn.init.prototype = jQuery.fn;

The line of particular interest is the line:


jQuery.fn = jQuery.prototype = { // etc.


Here we assign the prototype to a separate variable, jQuery.fn, in order to refer to its members (namely the init function) in the main jQuery function. Then, in order to make sure that new instances of jQuery.fn.init have the methods declared in jQuery.prototype, we assign the jQuery.fn.init.prototype to the jQuery.prototype.

Now at this point, the jQuery function can return instances of “itself”. In order to chain from one function to the next, functions of the jQuery.prototype will either return this or jQuery(collection_of_elements) to allow the chain to continue.

There are lots of other cool techniques in the jQuery source – they’re obviously having fun pushing Javascript to what limits they can find.

I recently had the need to build sets of polygons and compute an overall union of them; being the painfully naive person I am, I jumped right into the task thinking that it would be relatively easy. A week later, I had finally arrived at a working polygon clipper modified for boolean operations on poygons (mostly, see the README), but boy was it ugly. Throughout the entire process, I kept thinking “wouldn’t it be nice if I had a decent Vector/Matrix/Polygon data structure”. I made a few dirty attempts at writing something I liked looking at, but none of them were very satisfactory – really, I wanted something that looked a lot like JQuery. Something that just took whatever data I threw at it, and most of the time did something sane with it.

So, I decided I’d write Spatial Query, a small JS library that lets you do all the gruntwork Vector/Matrix/Polygon work easily. And some not so gruntwork stuff, that I just needed anyways – like generating a convex hull, or the union of two polygons.

  $p([[0,0], [0, 10], [10, 10], [10, 0]]).convex_hull_2d();
  $p([[0,0], [0, 10], [10, 10], [10, 0]]).union_2d([[5,5], [5, 7], [15, 7], [15, 5]]);

Since the project that spawned this library dealt with geometric data, there is also some functionality that will allow you to compute distances between latitude and longitude, as well as conversion between Latitude / Longitude and WSG84 coordinates:

  $ll([lat1, lon1]).distance_to([lat2, lon2]);
  $ll([lat1, lon1]).vector();

Better explanation and more is available in the README

There are still some kinks in this version that I’ve got to iron out, so I’ve not even bothered assigning a number to it. Consider it version zero point ugly.

Thanks to my employer, the Indianapolis Star, for letting me open this to the public.

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.