The Game Deadline Problem, part 2

The deadline problem is, unless a project has a hard limit (like a fixed budget or a client milestone) or a willingness to halt work, it’s pointless to even call it a deadline. And a due date is more a wish than a prediction, given my track record, so I’m not even going there.

Right now THE OCTOBER GAME is running without a deadline or a due date. It’s kind of a problem.

At the end of October I had a choice:

1. Cancel the project and admit failure
2. Set a new deadline, after which the project halts
3. Work on the project until it’s done

Ha ha! Just kidding. There was no choice at all. Even by December I couldn’t stand the idea of not finishing the game. I might have said to myself “any app project is a valuable experience”, or “this is an opportunity to learn something new, yadda, yadda…” Those are what you call rationalizations. I want the game. It tasks me. It tasks me and I shall have it.

A month into Spring I’d changed the way I work. By limiting my hours and resting more I achieved a steadier pace. As I added features to THE OCTOBER GAME, a few of the classes seemed to grow bigger than the others. They became harder to work with and debug. I needed to write better, not just more code.

Analyzing my developer notebook, my plan file and my daily log entries, I found two main kinds of bug: race conditions and incorrect game states. I’ll write more about those later. Essentially I had to stop all forward progress and rework the core game entities. I won’t say I didn’t have fun but it cost two more months and brought me into the start of Summer. That’s when I learned to plan better and keep an eye on the big picture.

To be continued.