I’ve been falling down the rabbit hole on my iPhone game — again. I’m getting too wrapped up in details: “I should shade this graphic better”, “that would look nice with a color gradient”, “I should extend the Bézier curve perpendicularly to its tangent, not just horizontally”, etc.

This is all, essentially, polish. I still need to do sound and music, for example. It’s just fun to polish because I know how to work with features I’ve already implemented — they have a high tweak/reward ratio.

In professional development, which is what I’m ostensibly doing, there are three(-ish) key project management trail markers you’re looking to hit, the ABCs of game development:

1. Alpha: The game is feature-complete. No new features need to be written, existing code needs debugging. All art/sound assets should exist, if not in final form.
2. Beta: All art/sound assets should be final. Code should be stable and fixes limited to high-priority bugs.
3. Candidate: Good for submission to your publisher. Fixes limited to crashes (shouldn’t exist), guideline violations (breaking the rules of your publisher’s platform), or legal issues.

You then iterate on candidates until one is accepted and released. My game, under these definitions, is still pre-alpha — I’d like to get it there before I leave for Europe next week. Then any work I do on it in Amsterdam will be improvement, not implementation.