GottaEat is a casual arcade game for iPhone and iPod Touch. It costs a dollar (in the US store).

Hop to catch flying insects.

Avoid the deadly bees or you’ll lose a life.  Lose 3 lives and it’s game over. If you do really badly, you’ll earn a dunce cap. If you play a better game, you’ll earn a top hat or a cool viking helmet.

Each level is nice and short so you can play whenever you have a free minute.  If you get interrupted, don’t worry, it’ll pick up where you left off. You can even play your own music instead of the game’s.

I put lots of help pages in the game if want to know more.

I had fun making it and I hope you like it. Enjoy!

Pencil on index card. Painted in Photoshop CS4.

Faber-Castell PITT artist pen size-S. Tinted in Photoshop CS4.

What came before

After finishing the level editor, I created the last few stages and played the game through many times, editing and adjusting to get a good difficulty progression. Right now there’s a good ramp-up with the end levels hard enough that even I can’t always win. If you beat this game, you’ll definitely earn it. link:evil-laugh.wav

Play testing

I had a friend play, which led me to make a few tiny tweaks to the user interface. I would like to get a few more testers on different devices but I’m not sure how to go about it. More on that later, maybe.

Performance

Performance issues have dogged this project from the very beginning. Keeping the frame rate near 60 fps has lead me to rewrite this game three LONG STREAM OF EXPLETIVES DELETED times. If I’d chosen to drop support for older devices earlier, I could’ve cut development time by a full third. When I started this project I was willing to support the iPhone 1st gen but I’ve had to retreat from that a bit. Once I get an iPod Touch 3rd gen to test on, I’ll make a decision where the cutoff point is. That said, I am so done with iOS 3.x, it’s not even funny.

Lingering bugs

To my surprise, I’m still finding bugs. A quick search of my development log reveals an astounding 200 bugs found and fixed over 17 months of development. I haven’t done a detailed analysis of the data but it looks like I’m generating fewer bugs per unit of time. The thing is, I’m writing less code overall. I wouldn’t be a bit surprised to find my bug rate to be constant by lines of code. Certainly it’s in my best interest to write as little new code as possible.

Cleanup

My policy is to do cleanup sprints after major feature pushes. I try not to mess around with the oldest code even though it’s rather ugly, stylistically. For one thing, most of the bugs have been squeezed out. Art assets are a different story. Images have several processing steps to make them program-ready. Audio also has pretty strict restrictions such as file format, volume, frequency and bit-rate limits. Any change and all the steps have to be repeated. It’s a real pain so I tend to save up corrections and do them in big batches.

Next steps

I still have to do one last art sweep before shipping, as well as generate branding images for the web site. I’m also putting together a plan for the promotional push, something I’ve never done before and a source of extreme anxiety awesome-fun-cookies.

I’ve mentioned before the little side-projects I work on. But there’s another kind of practice called a Code Kata. The big idea is to solve the same problem repeatedly, each time extracting new lessons. It’s the same problem, but you try to come at it from a different angle. While the name is taken from the martial arts field, the concept is more like the deliberate practice of the musician. A beginner might practice scales, but more experienced performers would have well-worn pieces that they comes back to, both for private enjoyment and education.

There are a number of well-known code katas floating around but I think there’s value in having a personal set. I’ve spent the past few years learning Objective-C and the Cocoa framework specifically for use with the iOS operating system. I write iPhone and iPad apps even for my own private use. It’s my “home” base. Within that realm, there are a few subjects that I keep being drawn to:

Touch-controlled Shapes.

Particle Simulations.

Timers.

Down the road, I want to add some more like Machine Learning, Maze Generation and Image Processing but there are only so many hours in a day.

Also, I totally earned this:

As I mentioned last time, the game was feature complete including scaffolding like the Top Scores and Help screens. I’d found creating levels by hand to be unbearably slow and error-prone. This led to creating an app to automate the creation, editing and export of game level data.

To avoid the mistakes of previous attempts, I would

• Plan more before coding
• Break the job into smaller sprints
• Budget enough time to make real progress

I started out by describing the functions I needed for an app of small, medium and large scope.

Then I sketched interface designs

Then I detailed how I would implement the parts.

Later, I started to become concerned about the time this was taking. While I was careful to budget more than the usual two days, I now realized I’d been working on the editor for a month. I was only 1/3 finished and couldn’t make a single full level yet.

This led me to reassess the value of the project. I decided to scale back and adapt existing work, rather than call a halt. I’d determine the most awkward part of the current workflow and improve just that.

Once I decided this, I built a few levels using a horribly primitive and tedious workflow. I needed Xcode, Property List Editor, Apple Mail, TextWrangler, PasteBot, both my old and new level editors and the game running on the iPhone. Madness.

Still, after making a few levels this way, it became clearer what would make the process slightly easier. I took a few days to add it, then went back to making levels. I repeated this cycle a few times and now I’m up to Level 26 of 36. The process is still hard work, but it’s manageably complex. If I see some simple tweak, I’ll add it, but no more thoughts of some universal nail driver tool what pounds all kinds of nail real good.

Here’re some screens.

Time spent: 2 months

Lessons learned: Start with a primitive workflow and fix the single worst pain point that can be solved in a few days work. Baby steps. Or rather, small bets.

Mistakes made: I didn’t keep a close connection between theoretical features and actual workflow improvement. Didn’t work in small enough sprints so the cost of mistakes was still high. Well-designed features or well-built code that solves the wrong problem is a subtle failure mode.

What I did right: I’ve been alternating between game development and very small practice projects. I’ve learned so much that it’s completely been worth the diverted time. The key is keeping them small and short. Also, Unit Tests up the wazoo.

A few months after my last effort, I wanted to try a new method of app development. Previously, I tended to write code in a big burst of activity. That’s fine for very small projects but if code grew past a certain threshold it became really hard to work with. It was like driving successively larger vehicles on wet sand. A bike is no problem, a car is harder, a semi-truck becomes impossible to steer or back up. It gets more attractive to just abandon it and start over. So the new way was to build smaller, more independent bits of functionality. That way I’d have something useful whether the full project succeeded or not.

I started at the most basic level: A button that switches between states and shows images reflecting that state.

Then I grouped those multi-state buttons into a cell.

Multiple cells would be grouped into a more complex control, an AttackGroup strip.

Those would be grouped into levels. Levels would be grouped into a whole Game. Then I’d have some method of transferring the data to the actual game app. That all sounds pretty complicated, right? The big idea was to construct the smallest, simplest useful bit and re-evaluate at each stage. If it started to go wrong, or I needed to work on something else, I’d at least have the last completed part to use.

In fact, something did go wrong. As I completed the AttackGroup strip, I realized I couldn’t specify two enemies in the same lane yet going in opposite directions.

Not only was this configuration allowed by the game rules, it played a critical role in making levels more challenging. Since I was near the limit of my programming skill, I had to either stop here or devote an indeterminate amount of time to research. Then I’d have to redesign the control. Then I’d continue work until I reached my limit again.

I decided I didn’t have the skills yet so I halted the level editor project and went back to work on the main game app. Even so, I used the AttackGroup strip control many, many times to generate individual AttackGroups, which I hand-edited into game levels.

Time spent: 2 days

Lessons learned: Spend more time planning before coding, to avoid dead-ends. Budget research time for more complicated work.

Mistakes made: Got too focussed on fine details and not the big picture. Let myself get discouraged by mistakes.

To do: Improve general coding and design skills with small side projects.

In the following months, I continued developing THE OCTOBER GAME, increased performance and fixed tons of bugs. I recently reached the point where all the features in the game were in place. Except for lots of fun, playable levels. To do that, I would need an editor.

To be continued.

Writing code is fun and this leads me to jump into projects, then drown in rising complexity. To counteract this, I try the simplest thing that could possibly work.

The simplest thing was no level editor, but that had it’s own problems. As I mentioned before, it was possible to make levels by specifying all the attributes of each enemy by type, direction, motion curve, number of flybys and flight lane.

A column of enemies was called an AttackGroup. A set of AttackGroups made up a Level. A set of Levels made up a Game.

The levels would become progressively harder in order to present a real challenge to the player. I figured about thirty would strike a balance between game length and level creation effort. That number was arrived at after due consideration and careful research, and in no way from thin air.

As it turned out, building levels by hand was hard to predict, error-prone and very slow. The obvious solution was to work at a higher level of abstraction. That meant creating a graphical tool to configure enemies and display them interacting in real-time. Ideally, it would output a formatted file to drop into the game app and playtest with.

The big idea was a grid-based editor with motion preview. No need for detailed configuration. Just touches to toggle through the various enemy types laid out in a grid. Time was controlled by a simple slider. I figured I’d get the basics done and if that went well, I could elaborate later.

It took a couple days to get it built and I learned a lot about making custom controls. I was pleased with it until I realized that the simple motion system (just sliding two grids of buttons around), wouldn’t accommodate an important gameplay feature: multiple enemy flybys. Rather than migrate the animation system from the actual game app, I decided to halt work on the editor and concentrate on more direct game features.

Time spent: 2 days

Lesson learned: Start from the lowest level and build up complexity. Compose simple controls into larger ones. Have natural stopping points so the project doesn’t drag on.

Mistakes made: Should have planned the design more before coding.

Later, when the pain of hand-building levels grew again, I built another editor.

To be continued.

Faber-Castell PITT artist pen size-S. Tinted in Photoshop CS4.

The core of the game is simple, the player jumps up to hit enemies flying across the screen.

As a complication, some enemies are good to hit and some are bad.

The game needed variety so I made multiple kinds of good hits: food and bonus.

Further subtypes allow for different scores, behaviors and appearance. The system could be expanded as far as I wanted. For this small game, I wound up with six kinds of enemy. Three food types, two bonus types, one danger type,  plus an invisible null type, used for spacing. They’re rather small on screen and they move fast so I kept the colors simple.

I added a few more adjustable parameters like straight and wiggly paths plus different flight directions.

Movement is restricted to five flight lanes so I could predictably stack columns of enemies or put danger closer to the player.

This allowed 350 variations for each column of enemies.

Along with speed and spacing, that would allow enough variation to design fun levels.

And that’s how you get complexity from a tiny number of adjustable parameters. If I hadn’t started simple, adding variety would have quickly become overwhelming.

While it wasn’t that hard to generate a few levels by hand, it soon become impossible to predict the feel of a level just by looking at this:

So I needed to construct a level editor, which was harder than I expected.

Dun dun duuuun!

To be continued.