Shortcuts Are Not Your Friend

I’m wrapping up work on Roly-Polies HD, a physics-based game for the iPad, and the last thing I needed to do was to rearrange the levels. There are 60 levels in the game and when I created them I didn’t worry about putting them in order, I just created one, saved it to the database, created another, saved it, etc.

Since the database has an “orderby” column all I had to do was change the value in each record and then when I pull the level info from the database everything will be in the correct order, from easiest to (roughly) hardest.

And that’s when I discovered what I’d done a couple months ago when I first started working on Roly-Polies.

This Shortcut Will Surely Be Okay!

I created a global variable called currentLevel and initialized it with the value 1 — to get info about that level I’d just pull from a table created by pulling data from the database.

And then when I’d finish playing a level I’d move to and load up the next level after doing this:

So far, so good. Nothing exciting happening here.

The problem rose it’s ugly head when I realized I was using _G.currentLevel as the key to grab different level-based items from the database. Stars and blocks, two types of items in the game, are stored in tables with levelID as the lookup key.

When I first created the code I decided since the levelID was an auto-incrementing field I could use _G.currentLevel as the levelID when I needed to access the different tables.

Remember at the start of this post I mentioned changing the orderby column in the level table? Before I made the change the 15th record retrieved from the levels table had a levelID of 15, the 23rd record had a levelID of 23, etc.

But now the 12th record might have a levelID of 3 and the 3rd record might have a levelID of 49.

_G.currentLevel and levelID are no longer the same number.

I’m screwed.

Here’s A Quick Fix!

Fortunately I’m a smart guy who’s been around the block a time or two and I figured out a fairly quick way to fix things. Since I pulled all the level info into a table at the very beginning, at any place where I used _G.currentLevel to specify the level, I could change to this:

…and I’d be good to go.

Search, replace, and in about 15 minutes I was testing the new build. Things acted fine, but going back to the “Choose Level” screen I noticed some weird things happening. Scores weren’t being credited to the correct levels, etc. Somewhere along the line I changed something that shouldn’t have been changed, or didn’t change something that should have, or something.

Looking at the database functions I saw some of the queries were based on levelID, but based on levelID and the row number being the same.

So now I’m in the middle of rewriting SQL queries and after that I’m just not sure what’s going to happen.

In less than an hour I went from rearranging game levels to rewriting chunks of the “finished” program.

All because I decided that the levelID and the row number of a record could/would be the same thing.

Shortcuts Aren’t Worth The Time They Take

I’ve been programming since 1984 — professionally since 1986. I know better than to do stupid things that will come back to bite me in the butt.

And yet, that still didn’t stop me from “saving” 10 or 15 minutes when I first started coding Roly-Polies by taking that shortcut. What’s sad is that I even thought about whether I should make the assumption about IDs and row numbers and decided it would be okay — in this case. After all, I wasn’t creating code that other people would be working on or maintaining, so it’s not like someone wouldn’t be able to figure it out, blah blah blah…

I’m glad to say that I don’t make huge mistakes like this all the time — just often enough to get me back on the straight and narrow, no matter how inviting the shortcuts look.

Photo credit: Path through the woods by supersam5, on Flickr.