Posts Tagged ‘iOS’

Gold Runner for iOS now an Open Source Project!

Monday, January 14th, 2013

In the past I have been accused of having a career based entirely on one game: Gold Runner. It might actually be true.

Gold Runner was a game written for the TRS-80 Color Computer in 1984. It bears a striking resemblance to a game called Lode Runner for the Apple 2 and other 8 bit computers of the time.

It also happens to be my favorite computer game of all time. I’ve always had an obsession with the game and it’s never been far from my mind when contemplating game development of my own.

So in 1994 I finished Gold Runner 2000, a version written for the MM/1 personal computer.

The MM/1 would most accurately be described as a hobbyist computer bought by a number of members of the Color Computer (CoCo) community after the Color Computer 3 had become dated, the rest of the computing world had moved on from 8 bit to 16 bit systems, and Tandy had failed to provide such an upgrade path for the CoCo.

Gold Runner 2000 maintained all of the play mechanics from the original, but increased the size of the graphics images such that a whole level took up the size of 9 screens. This means that Gold Runner 2000 was a 2D side-scrolling game.

Color Computer (and MM/1) enthusiasts used to gather periodically for conventions, or “Fests”. And I took Gold Runner 2000 to just such a Fest in Atlanta soon after it was done.

From that exposure, I met a number of people. A couple of them worked at a company called Microware. Microware developed the operating system (OS-9) that ran on the MM/1 and Color Computer 3. When Microware needed some new developers with OS-9 experience, one of my new friends, Boisy Pitre – Microware employee, thought of me from having known my work on Gold Runner 2000. He contacted me, and it just so happened that I had just graduated from Arizona State University with a degree in Psychology. I worked for the credit card division of Chase Manhattan Bank, and prospects for a career with a basic liberal arts degree were pretty slim. So I took the job with Microware, in Des Moines, Iowa.

Almost two years later, I left Microware, moved back to Phoenix, and through a series of lucky occurrences and knowing the right people, continued working as a programmer despite not having the appropriate degree.

So yes, Gold Runner is responsible for me having a career in this field today.

Now, in 1997 I was moving on from the CoCo, fully entrenched in MM/1 development, and I missed my favorite game. So I decided to write a clone of the original CoCo Gold Runner for the MM/1. I played through every level of the original game, mapped each level out by hand on graph paper, digitized all of the sounds from the original, and re-created the (very simple) graphics from the original.

And, I must say, I did a damn good job. I recreated every aspect of the CoCo original. I copied the high score screen exactly, with the graphical effect of the line for the current high score alternating between white-on-black and black-on-white. I copied a graphical glitch from the original that, when a character was on the far-left edge of the screen, displayed the leftmost pixel of that character on the right side of the screen, one pixel lower than it would have been had it displayed properly on the left side. And finally, I recreated the oval-shaped fade-in feature of each level as it started.

High Score Screen

Game Screen with Oval fade-in

I decided that I didn’t just want to create a Gold Runner game, I wanted to create a Gold Runner “engine” – a codebase that could be moved to a different platform and easily modified to get the game running on that platform. Or, the code could be easily enhanced to make a new version of the game for the MM/1.

Eventually, this “Gold Runner Engine” was shelved without ever having powered another fully completed game.

Fast forward to 2008. I had recently started working as an iPhone developer, and had written a couple of simple indie iPhone apps, and I decided that I wanted to do an iPhone game. And then it hit me. I could resurrect the Gold Runner Engine, port it to the iPhone, and not only have my first iPhone game, but at the same time resurrect my favorite computer game of all time on the newest gaming platform in existence.

And I did just that. Impressively, for code that I wrote fairly early in my career, the Gold Runner Engine ported fairly easily to the iPhone and in pretty short order I had a perfectly functioning clone of Gold Runner for the TRS-80 Color Computer on the iPhone.

I polished it up, tested it, released it, and sat back to see what would come of it.

It sold a number of copies, I really don’t remember even a vague estimate of how many.

But, within a year of my releasing it, a company had bought the rights to the original Lode Runner game and began seeking out games on various platforms which they considered to be infringing on their newly acquired intellectual property. A number of games, including Gold Runner for iOS, were targeted and removed from sale.

Back in the late 90s when I was still working on the Gold Runner Engine, I had made some modifications to it for a new game I was intending to call “Gold Runner Plus”. I added in floating (roaming) gold bricks, teleporters and moving platforms. But I never quite finished those additions to make the new game.

When Gold runner for iOS was removed from sale, I decided the best thing to do would be to resurrect that almost-completed “new” code, port it over to iOS, and release a new game, one that would have play dynamics not found in Lode Runner, and thus would be immune (I thought) to claims of copyright infringement. But finding that codebase on old 3 1/2 floppies for a long-dead computer proved difficult. Indeed I still haven’t located it.

So now I have decided that the best thing to do is just release the iOS version of Gold Runner as open source.

The project can found on Github here.

I could end this entry here, but I want to use this opportunity to get something off my chest.

While Gold Runner for iOS was still on sale, there was one common criticism found in the reviews that it got. Every reviewer said the control scheme was terrible.

Now, we’re talking about a game with a main character sprite that was as small as 8 pixels by 9 pixels, moving around a tiny screen, and having to climb ladders that were 9 pixels by 9 pixels in size, and that used a touch screen for input.

There was no ideal control scheme for such a game.

Nevertheless, I offered three control methods: 1) on-screen buttons where the character only moves as you’re touching the button 2) on-screen buttons where touching a button starts the character in motion in the given direction until a different button is pushed 3) flicking the screen in a direction starts the character moving in that direction until another flick is performed or the screen is tapped.

Game screen with button controls

Horizontal game screen using "flick" control

It took some getting used to, but after playing several times, the controls – especially the flick method, were quite usable. But computer users have a tendency to give a program, be it a game or a productivity app, one chance, and if they don’t like the UI or the control scheme, they rant about it. I think it’s ridiculous, but it’s just the way things are. Nevertheless, bad wishes to those who ripped the control scheme on the App Store.

I would love to see someone come up with a better control scheme.

Ah. I feel better now.

One final thing. The original codebase was written in ‘C’ on a system that didn’t have what would be considered frameworks or even a reasonable set of APIs, by modern standards. It was shoehorned into classes to fit iOS design patterns. As such, it isn’t exactly the most sparkling set of code I’ve ever written, not to mention the fact that I wrote the original code just two years into my professional programming career, some 15 years ago. Nevertheless, it works, and shouldn’t be too difficult to understand.

All things considered, I’m pretty proud of the work I did on it, though I would never show the code off as an example of my best work.

So that’s it. I hope someone out there gets some use out of this code, and perhaps uses it to do something cool.

If you do, I’d love to hear about it.


Building Better iPad Tables

Friday, September 2nd, 2011

When Cocoa Touch first debuted, it only applied to tiny little handheld devices without much screen real estate to work with. As such, it made sense that the multi-column tableviews present in Mac OS X’s flavor of Cocoa were replaced in Cocoa Touch with a single column version.

But then came the iPad.

The iPad uses Cocoa Touch, but it has much more screen real estate to work with than an iPhone or iPod Touch. The iPad is fully capable of supporting a table UI that has multiple columns. And indeed the view-based architecture supports the ability to customize table cells to your heart’s content, even on an iPhone.

Nevertheless, it doesn’t seem particularly easy to approximate the UI of a data-driven desktop app on the iPad, as there doesn’t seem to be any method for more complex table layouts on the iPad.

But that’s exactly what I need in writing Giftory for iPad.

So I wrote it.

And now I’ve released it for anybody else to use.

The primary UI for Giftory on the desktop is a display of gifts, including, for each listed gift, its name, the store it was bought from, its price, the names of its giver and receiver, its hiding place, and a couple of other relevant bits of info:

Mac OS X Giftory Table View

Table View for desktop version of Giftory

This UI utilizes text fields, popup boxes, combo boxes and check boxes to achieve its functionality.

Cocoa Touch table view cells are generally only fit to embed labels to customize the cell to display several pieces of information. Some table cells have been implemented with a label to provide the name of a data field, and an editable area where the user can enter a value for the field. But editing multiple data element values always requires utilizing another screen.

None of this is suitable for editing multiple data elements for a given data object displayed on a single table row.

I created “Reusable Dynamic Table Cell Classes” to solve this problem.

These classes provide a subclass of UITableViewCell that utilizes objects built to simulate the functionality of pop up boxes, combo boxes and check boxes, as well as standard text fields and buttons. Using these classes developers can programmatically define a row UI for their tables, associate the row with a data object, such as a dictionary or managed object, and manage the data through the generated interface:

iPad table view

Customized iPad table row using Reusable Dynamic Table Cell Classes

The classes aren’t currently suitable for situations in which the row itself needs to be selected, but they are ideal for situations in which the table rows simply display various elements of a data object, and those elements are editable.

In the next post I will go into detail about the design of the data cell classes and how to use them in code.

The open source project can be found at:

More sleeping with the enemy. Next up: Android

Saturday, March 12th, 2011

As it’s now all about the money, it makes sense to look into developing for the only other viable modern smartphone OS, so I got an e-book on Android development and set out to port two of my simpler iPhone apps to it.

Much like the iPhone originals, rewriting them for Android didn’t take long, and gave me a good chance to assess Android development and compare it to the experience of iPhone development.

What did I find?

Well, first off, I almost hate to say this, because I know that one gets used to what they know, and something unfamiliar can often be perceived as frustrating, poorly designed, garbage, etc…

That said… I really, really am not a fan of Eclipse, which is the IDE that the official Android development pages tout as the de-fact Android development IDE.

When the T-Mobile G1 first came out, we dabbled a bit in Android development.

It was hard to get past the fact that there was no visual layout tool for Android that was even in the same ballpark as Interface Builder for iPhone.

It’s been a couple of years. I figured that they MUST have improved the layout tool by now.

Ummm. NO.

Sorry, but it’s absolutely terrible.

On top of that, I think the Android emulator leaves a lot to be desired compared to the iPhone/iPad simulator.

But I could live with those. I actually, at times, found myself enjoying Android development.

Except for one little thing.

Almost every time I wanted to figure out how to do something with my UI, and I searched online to find the answer, most, if not all of the answers started with something to the effect of: “in the layout xml, you…”

I’m not a fan of Java’s layouts. I’m also not a fan of performing tasks in xml. Lacking a good Interface Builder equivalent, I do most of my UI creation in code. Therefore I need answers for how to accomplish things IN CODE. I’m amazed at how hard it can be to find such answers for Android.

But the real problem is, it’s not just that the answers are hard to find, sometimes they don’t exist. Android is a very nice mobile OS, with some very nice features. However, the SDK seems kind of half-baked, because a lot of the features aren’t available programmatically, or at least are unnecessarily hard to get to programmatically.

Here’s one example:

I have a button. I have two graphics files for that button. One for the up state and one for the down state.

I expect that for any SDK for any OS that I’m using, I can find a call such that I can set those up and down images in a couple of lines of code like this:


setImageForState (img, BUTTON_STATE_UP);

setImageForState (img, BUTTON_STATE_DOWN);



And sure enough, on the iPhone, we have:


[button setImage:upImage for State:UIControlStateNormal];

[button setImage:downImage for State:UIControlStateSelected];


So how do we accomplish the same thing in an Android app?

Would you believe:


button.setOnTouchListener(new View.OnTouchListener() {

public boolean onTouch(View v, MotionEvent event) {





return false;




No, I’m not kidding, and it took a while to find this solution, most answers just said, “in the layout xml…”

Sorry, but that’s ridiculous.

So the bottom line is, Android is a perfectly fine mobile operating system, and it may one day be a pleasure to write for if they actually develop a decent layout design tool for it and give developers simple programmatic access to all of the functionality available through layout xml.