Bullfrog 2 Teaser Screencast

Marcus and I have been working hard on Bullfrog 2. There are many technical hurdles we’ve been navigating through, but it’s been fun so far.

We promised to keep you up to date with progress and discuss the technical challenges we’ve encountered. So far the challenges have been all due to our lack of experience in the new technologies we’ve chosen to use.

Open GL has been a bit of a change from drawing in Cocoa, but once I worked out the “little” problems getting the code to work on multiple graphics cards it’s been mostly smooth sailing.

The biggest challenge has been getting up to speed with the new Leopard technologies. We really want to write about this stuff, but can’t yet because of the NDA we’ve agreed to with Apple. Hopefully, we’ll get to talk about that stuff soon.

But, to show that we are making progress here is a short thirty second movie of our little green hero hopping around a small test level.

Keep in mind this is uses very rudimentary developer artwork I created just to test the screen scrolling and background tiling code. But, it does give a small peak into the direction we’re taking Bullfrog 2.

Bullfrog 2 Teaser

Acorn from Flying Meat

From Gus Mueller, developer of Voodoo Pad, comes a new bitmap image editor to the Mac market.

Acorn is a sleek, light-weight, and affordable image editor built with modern Mac OS X in mind.

Over the past few weeks I’ve been lucky enough to use Acorn through the beta testing period and it’s a very nice product. I’ve been creating all of my “developer art” in Acorn for my upcoming game, Bullfrog 2.

There are some great simple to use image editing tools and some pretty cool image filters built right in. But, I think the power comes from the plug-in API that allows extending the application using Python and Objective-C.

Bullfrog 2 Update

I can’t believe it’s been a month since my last Bullfrog 2 post. Unfortunately, development has gone a bit slower than originally anticipated due to work on other projects.


Over the past few days I’ve been moving code from the old Bullfrog game engine to a new Xcode 3 project for full-bore development to begin on Leopard.

Yes, we’ve made the decision to make Bullfrog 2 a Leopard (Mac OS X 10.5) only product. There are just too many things in Leopard that we really want to use.


As I mentioned in the last update, I’ve been learning OpenGL and working towards converting the Bullfrog engine from the old Cocoa drawing code. Today, I checked in my changes that have officially started us down the OpenGL path.

Our green hero is now fully hardware accelerated and I have resolved my earlier transparency issues.


The next step is heavy refactoring of the game engine. Bullfrog was my first Cocoa / Objective-C project and the structure of the code definitely reflects that.

Now that I have significantly more experience in how a Cocoa-based project should be structured, we’ll spend a couple of weeks moving code around and getting our foundation in order.

This will allow for multiple developers to work inside the project as well as make the code generally more maintainable.

Just the Beginning

We’re still very much in the preliminary development stages with much design work still to be done. But, it’s a good feeling to move forward on this project.

OpenGL Bullfrog

Finally had some time today to toy around with some OpenGL programming. One of the first architectural changes we’re going to tackle in Bullfrog 2 is to move all the graphics engine code to use OpenGL instead of Cocoa.

I created a new Xcode project to house our experimental code while we find our way around OpenGL. After hacking away for a couple of hours I was able to get a basic though flawed proof of concept to render our old friend from the first Bullfrog game into a custom NSOpenGLView.

I haven’t figured out how to get transparency to work with the alpha channel and the sprite is sized too small, but not too bad for a first go.

After some more reading I should be able to figure out how to fix the frog’s size and transparency issues.

I did encounter an interesting “bug” while putting together the UI in InterfaceBuilder. Using an NSOpenGLView directly with a custom class will never call your -initWithFrame: method. The only way I could find to get the method invoked was to use a Custom View (NSView) instead of the NSOpenGLView and then use my same custom class. Perhaps I’m just missing something, but this seemed strange.

Parsing Email Date Formats

I’ve been busily working towards the release of LicenseKeeper 1.2 over the past week. This morning I attacked a minor issue where some email received dates weren’t being parsed correctly.

After some investigation, it turns out that is was just a matter of handling an additional string to date conversion format. The problem and solution were fairly trivial, but my first and very lazy approach oozed ugly:

// Apple Mail style date... 
//      (ex: Sat, 24 Mar 2007 21:51:06 +0100)
_dateReceived = [NSCalendarDate dateWithString:dateString 
                   calendarFormat:@"%a, %d %b %Y %I:%M:%S %z"];
if (!_dateReceived) {
   // Entourage style date... 
   //   (ex: Tuesday, March 13, 2007 3:46 PM)
   _dateReceived = [NSCalendarDate dateWithString:dateString 
                   calendarFormat:@"%A, %B %e, %Y %I:%M %p"];
if (!_dateReceived) {
   // short style date with no time zone... 
   //   (ex: Fri, 1 Jun 2007 14:24:56)
   _dateReceived = [NSCalendarDate dateWithString:dateString 
                   calendarFormat:@"%a, %d %b %Y %I:%M:%S"];

Originally, I just had two date formats to parse so one “if” statement didn’t look to bad. But, it also had some nasty hard coded string constants.

Once I added the third date format, the code really started to look ugly and started to reek of code rot: too many hard-coded strings and cut-and-paste code blocks.

So, I refactored the code to move the date format strings to the application’s Info.plist file:

            %a, %d %b %Y %I:%M:%S %z
            %A, %B %e, %Y %I:%M %p
            %a, %d %b %Y %I:%M:%S

Now with the date formats moved to a more manageable and reusable place, the date parsing code block cleans up quite nicely.

NSArray *dateFormats = [[[NSBundle mainBundle] infoDictionary]
int i;
for (i = 0; i < [dateFormats count]; i++) {
   _dateReceived = [NSCalendarDate dateWithString:dateString 
                    calendarFormat:[dateFormats objectAtIndex:i]];
   if (_dateReceived) {

The big advantage here is that if I need to add more date formats to the parser the code doesn’t become more complicated and run the risk of adding new bugs down the line. It also eliminates the need to recompile the source file if all I’m doing is adding a new format.

Plus the code just looks nicer and is easier to understand.

Cocoa Cheerleaders

When starting out as a Cocoa developer or switching from another platform, sometimes the hardest part is knowing where to find information about your new chosen toolset.

There are some good resources around the net, but finding them can be challenging if you don’t know what to look for.

David Masters brings us a new Cocoa centric web site with a unique theme, but don’t let that scare you off.

Cocoa Cheerleaders has a very nice growing collection of links categorized by “Sites”, “Blogs”, “Casts” or podcasts, “Books”, “Lists”, and “Code”. Each link has a cool AJAXie site preview image with a summary and RSS availability indicators.

Debugging Cocoa

Thought I would share my growing list of handy tools and techniques for debugging Cocoa applications on the Mac. If you have any to add, share the love in a comment.

Debugging Memory Issues

Debugging Crash Reports

Logging Techniques

Debugging Tools

  • F-Script – Interactive scripting environment for Objective-C and Cocoa.
  • Class-Dump
  • OTX – Cocoa UI for otool.
  • BSInspector – Xcode plug-in for viewing detailed object information.

CocoaCast Interview

Daniel Jalkut and I took part in an informal discussion with Russ from the CocoaCast about our thoughts on Leopard, learning Cocoa, and ideas for the upcoming CocoaCast group project.

It was a ton of fun and Russ shared some really interesting beer to keep us from getting thirsty and to help us loosen up a bit.

If you are new to Cocoa or just interested in our profound thoughts and advice, check it out.

Handle Core Data Model Changes

In last night’s Boston CocoaHeads meeting, we had an interesting discussion of the pros and cons of Apple’s Core Data persistence framework. It was interesting to hear about how people are using this great technology.

One of the biggest concerns that came up with using Core Data is how to handle changes to your Managed Object Model or database schema. As of Mac OS X 10.4 (Tiger), Core Data does not directly migrate your data between different versions of your model. It’s also very unforgiving of trying to open a version of your persistent store that you are not expecting.

So what happens when you need to make a change to your Core Data model? What if you need to add an entity or change an entity relationship? This is inevitable over the life of your application. Requirements change and your users needs evolve over time.

As beta testing was finishing up for the first release of LicenseKeeper, I received some great advice:

“Make sure you handle Core Data model changes before you need to.”

When that emergency change inevitably rears its ugly head, be ready. Well, the advice was golden. The emergency did show up right before the 1.0 release and I was ready.

How do you migrate Core Data libraries through model changes?

Well, this same person also wrote a great article with plenty of example code to take you through the daunting task of setting up your mostly generic Core Data migration utility:

Core Data migration between contexts

Update: I had someone ask for the identity of the article’s author. Since the article had no attribution, I was trying to respect his privacy. But, Marcus Zarra of Zarra Studios was more than happy to accept credit. Marcus also mentioned that he had made the code available for download from Google Code: