My third attempt at a level editor for THE OCTOBER GAME succeeded, but not how I expected.
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.