First I had to get a handle on the core languages of C and Objective-C. Plain old C was relatively easy to pick up with a PHP/JavaScript background though occasional Google searches (usually ending up on Stack Overflow) are still required to fill in the gaps in my knowledge. Aaron Hillegass’ Cocoa Programming for Mac OS X was an excellent introduction to Objective-C and the Cocoa Framework (as well as Apple’s developer tools, Xcode and Interface Builder).

Simon Maurice wrote a number of articles that helped me get up to speed with OpenGL on the iPhone. Unfortunately, due to a conflict with his employer these articles have since been taken down. I wish I had had the foresight to archive a local copy.

Then I did an audit of various game engines to gain an understanding of how a game works from a high-level architectural point of view as well as the low-level solutions to problems unique to games. The two that proved most informative were Cocos2d iPhone (Cocoa/iPhone) and Flixel (ActionScript/Flash).

Even with all of this research behind me I was still a bit lost. I went through a number of subpar iPhone and game development books before O’Reilly’s iPhone Game Development was published. While a bit thin overall the chapters on Game Engine Anatomy and the 2D Game Engine were invaluable; without this book I’m not sure I would have been able to put all the pieces together and translate the knowledge and understanding I had acquired into an actual piece of playable software.

And the learning continues, most recently figuring out how to compose music for the NES sound chip for use in the game.

Despite this review reading like a sequential process, it was anything but. There were a lot of missteps, horrible books, and overlapping content in between but it’s the wrong decisions that make you appreciate the right ones.

Early last year, I applied for a MakeWork grant from local Chattanooga arts initiative CreateHere. In May (thanks in part to generous recommendation letters from the talented Messrs. Marcotte and Rubin and some handsome illustrations by Mr. Cornell) I was awarded partial funding for my proposal to create a faux 16-bit game engine. My new game designs are far more ambitious than my inaugural effort, Horror Vacui, aspiring to multiple worlds and levels, various unique power-ups and hand-crafted pixel graphics, all of Super Nintendo caliber.

A few months after the release of Fever I started on the engine. This past December I took a whole week off from support to make one last uninterrupted push and finished the core components of asset management, audio/visual output, a unique touch-based input method, and tile-based animated sprites and maps. I also built out an HTML-prototype map editor. It may sound like I took a vacation to get some work done but when you’re doing what you love, it’s really not work.

A simple proof of concept was required to iron out any kinks in the finished frameworks. That concept proved more interesting than the original game I set out to create.

Pushing Pixels

Before I get to Mimeo, I want to address my love of pixels. The aesthetics of Mimeo (and Horror Vacui before it) are not born solely from nostalgia. Good pixel art strikes the perfect balance between appreciable craftsmanship and the gestalt. A single pixel out of place, one too few or too many, ruins the illusion. There’s an unmuddied, economy of expression, the thankless result of the limitations of cartridge-based consoles.

At its core, play, and by extension video games, is learning. Call it discovery or mastery but a good game introduces new ideas (teaches), leverages existing ones (reviews) and layers them to create unique challenges (tests). Teaching, at its core, is communicating. Verbosity is an academic sleeping pill. A game’s graphics are the player’s teacher and a good teacher is consistent, clear, and concise. Like good pixel art.

Super Mimeo Bros.

Mimeo (even the name) started as a Mario clone with a twist: instead of power-ups affecting the player, they affect the entire game world. A story and mythos quickly developed. The so-called Mimeoverse consists of two 16-bit demiverses sharing 32-bits between them. When the evil Kleptopus King, an 8-bit octopus with an inferiority complex, discovers a portal into Mimeo’s realm and begins to syphon off its bits, Mimeo is sucked in and down-sampled to 2-bit. So begins Mimeo’s quest to restore balance to the demiverses.

Mimeo collects carts to upscale himself and the game world and enables switching between acquired resolutions to solve platforming puzzles. He will find guidance from nearest-neighbor and native rabbit Gaido. Collected bits translate into 1ups. Disposing of certain types of enemies leaves behind hoodies that grant Mimeo special abilities. The Quantum Glove puts Mimeo’s bits in a state of quantum superposition; enemies can’t hit him but they can’t dodge him either. “It’s so bad.”

8-bit Hits

In addition to creating the scenario, programming and designing all the graphics I’m also composing and producing all the music. The game uses a Nintendo NES 2A03 APU sound chip emulator (courtesy of Blargg) for authentic sounds that will keep pace with the game’s graphics. Here’s some sample mp3s of the foreboding Fortress:

• 2-bit bass
• 4-bit hi-hat
• 8-bit melody
• 16-bit counter melody

I’m using a combination of MilkyTracker with the nespack.s3m samples for composing, Garageband for arranging, and MML for producing the final NSFs used in the game.

Resolution

I’m aiming for a 2010 holiday season release. There is still much work to be done as every asset exists in 4 different resolutions (I said this project was ambitious) but the majority of core pieces are already in place.

You can catch up on past progress on Dribble once it goes public and follow along with the unfolding process on Mimeo in the Tumbleverse, a development diary. Over the course of development I uploaded some short demo videos to Flickr and this slightly longer executive summary progress report to Vimeo:

I dabbled with Neil Baldwin’s Nijuu. It turns out I’m just not comfortable that close to assembly language. I finally (as of this writing) settled on MML or Music Macro Language. Nullsleep’s MCK/MML Beginners Guide proved a very non-threatening introduction but neonempyr’s Ultimate PPMCK MML Reference definitely won the thoroughness round. (The latter went missing the day after posting this. Fortunately I downloaded a copy for offline use. Here is my mirror of the Ultimate PPMCK MML Reference)

MML looked like a manageable language but it seemed none of the tools designed to compile MML into the requisite .nes or .nsf files were available on OS X. All of the links to the OS X versions had either 404’d or fallen prey to squatters. After a day of searching I finally found a copy of ezMML, an editor/compiler built—or rather thrown together—for OS X. Oh sure, you can resize the editor window but it doesn’t resize the texteara. I can forgive an unpolished UI if the utility is there but when a crash during an incremental save wiped out an entire morning’s work (the post-crash saved file was completely empty) it was time to move on.

I use Textmate for the majority of my non-iPhone programming and text editing needs. I don’t recall it ever crashing (except having to force quit the occasional 30MB SQL file). So I spent the afternoon hacking together rudimentary MML syntax coloring as well as the Build and Run commands.

Now I have a reliable (and resizable) MML editor with a single key-command to compile an .nsf and automatically launch Audio Overload. I can listen to my composition as easily as I can preview my HTML in a browser.

This bundle perches precariously on the shoulders of giants and is offered as-is, as always.

I don’t like magic. I like knowing how something works.

I don’t like taking things for granted because if magic breaks, unless it’s your own trick, you don’t know how to fix it.

And nothing in recent experience is as magical as the iPhone SDK. I’m sure the Objective-C language and Apple’s dependent frameworks solve a lot of problems encountered by experienced software developers. As an inexperienced developer without the context of those problems, these clever pre-made solutions seem like unnecessary hoops erected for the sole purpose of jumping.

Compounding this confusion are NIBs, XIBs, and Interface Builder. Interface Builder allows you to create and connect visual interface elements to your Objective-C classes. These interfaces are stored precompiled in a NIB or as XML in a XIB. It sounds like a brilliant idea—and it is—but as a software solution it’s a confounding mess. Especially when you’re developing software that doesn’t require standard UI elements (like an 8-bit game).

So the first thing I do when creating a new iPhone project in Xcode is sever any connection with Interface Builder or dependence on XIBs. I prefer to start with a Window-based Application and immediately Delete (Also Move to Trash) Resources/MainWindow.xib. Then in Resources/<AppName>-Info.plist I delete the “Main nib file base name” row and save. Finally I copy the AppDelegate class name from Classes/<AppName>AppDelegate.h (deleting the no-longer-necessary IBOutlet from the @property declaration while I’m in there) and paste it in as the NSString fourth argument of UIApplicationMain in Other Sources/main.m like so:

UIApplicationMain(argc, argv, nil, @"<AppName>AppDelegate");

I can then create my window programmatically in the applicationDidFinishLaunching method with:

windowFrame = [[UIScreen mainScreen] bounds];
window = [[UIWindow alloc] initWithFrame: windowFrame];

With no IBRabbits in my HatDelegate or Trick Referencing Outlets up my SleeveController I can go about the business of making my own mistakes and learning from them; so that one day all of this might make sense.

1. On your desktop, copy your API key (found on http://yourdomain.com/lessn/-/) and paste it into the following url: http://yourdomain.com/lessn/-/?api=<API key>&url=%@
2. Email the completed url to yourself
3. On the device, copy the url you emailed yourself and launch Tweetie 2 (the url can be constructed on the device but it takes some back and forth application switching)
4. On the Accounts screen, click the Settings button. Click “URL Shortening” then “Custom…”
5. Paste the url and click Save

• api: returns just the Lessn’d url as plaintext. Example usage, http://yourdomain.com/lessn/-/?url=<long url>&api=<API key>
• redirect: allows you to create custom redirects. %l in the value of redirect is replaced with the Lessn’d url. Example usage, http://yourdomain.com/lessn/-/?url=<long url>&redirect=http%3A%2F%2Ftwitter.com%2F%3Fstatus%3D%l

If you want to tweet a Lessn’d url from Fever you could replace the default Twitter service url in your Preferences Sharing tab with the following: http://yourdomain.com/lessn/-/?url=%u&redirect=http%3A%2F%2Ftwitter.com%2F%3Fstatus%3D%t%2520%l