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.

At the end of last month, I transplanted THE OCTOBER GAME to a fresh app template. For the next week, I fixed lots of niggling little bugs, did more code cleanup, then another round of tweaking artwork. I also added a graphical display of lives, progress and score to the Play screen.

The last week or so was dedicated to rebuilding the Settings, Scores and About screens.

I’d implemented quick & dirty versions before but now was time to flesh them out and get the art style up-to-date. These areas were simpler than the Play screen since they didn’t have to manage a lot of real-time animation. Even so, art had to be planned, built, processed and revised over several iterations.

Next, I wanted to get a feel for the project as a whole. I’m visually-oriented so I thought I’d start out with a dependency graph of all the classes. Unfortunately the Class Model feature was removed from Xcode 4. Luckily for me, Nicolas Seriot wrote a very useful python script called objc_dep.py to generate a GraphViz file showing dependencies.

The raw graph it creates is a bit, ahem… dense.

I hand-edited it to take out most cocos2d classes and that cut the node count by half.

Muuuuch better. Yet it was still hard to get a clear picture. While the alternative graph editor yEd offers better layout controls, it doesn’t read GraphViz formats (.dot or .gv). To convert it, I found another python script called dottoxml.py by Dirk Baechle. With some jiggery-pokery in yEd, I got it looking more organized.

This helped me get a feel for the app structure. Then I was able to do some refactoring to clarify the intent of the code. I found a few loose ends. OCD says what?

Other than a memory warning, there haven’t been any real surprises in this last sprint. I’m sure writing that will, in no way, come back to haunt me.

What I learned

• It helps to break down future tasks a day in advance.
• Planning is a task in itself and takes a lot of mental energy.
• My master chart helps me stay focussed on the right work and not go on tangents.

What went right

• Held my productivity to 80% of my peak. Suck it, regression to the mean.
• Learned to break down tasks even more finely, whenever I felt stalled.
• Kept focus by frequently referring to my master task chart.
• All screens are fully functional. If you put a gun to my head, I could release this month. With no music, no marketing and a few sound bugs, so no.

What went wrong

• If I finished a task, like artwork creation, it was very hard to switch to sound editing or coding in the same day. I’m not sure how to overcome this yet.
• Performance problems keep recurring on older hardware (iPhone 3G, I’m looking at you). I’m a hair’s breadth from dropping support for older devices entirely. A good cutoff point seems like the iOS 5 barrier. I would probably have to buy a iPod Touch 3rd-generation to test on. How I suffer for my art.

What’s next

• Building out and play-testing levels.
• Polishing the background art.
• Product landing page on the web site.

An #iSketchADay entry revisited.

Gel pen on index card. Colorized in Photoshop CS4 Extended.

Where this came from, I do not know. Better inside your head than mine.

ViaCAD Pro 7 glass render preset with tinting in Photoshop.

By moving into a new Xcode project I could consolidate and toss old stuff without taking the risk of breaking the app. Getting your game into an unusable state is really terrible for morale, even temporarily. I didn’t have any experience with source control until recently, so all my exploratory development was done manually, like an animal. For instance, I’d rebuilt the audio and multitasking managers in a separate app to isolate them. Now they were tested and ready for re-integration.

This was also a chance to try out new ideas on how to be more productive. By keeping a daily running average and doing my coding earlier in the day, I essentially doubled my productivity compared to last month. I also did more fine-grained time estimation, but that was less effective. Most subtasks took twice as many steps as I predicted beforehand. Improving that is an ongoing project.

The master progress chart I started this summer is finally shrinking instead of growing. Here’s what I just got done with:

And the remaining work (as far as I can predict). The real story is in the end nodes.

Progress!