Fighting Procrastination: The Local Maxima Problem
I'm a big proponent of rapid prototyping, particularly the "evolutionary" prototype model of software development. Especially in games. I don't believe that you can design fun on paper, though I agree a good design document is important to server as a "paper prototype" when developing a game as a team.

With evolutionary prototyping, you don't "throw away" the prototype. You use parts of it, throw other parts away, but keep developing in a spiral model. At a certain stage in each iteration, you've got an improved prototype ready to demo, play with, get feedback on, and to act as a playground in which you can explore and refine your game's design. Each iteration and turn of the wheel brings you closer and closer to a finished game. But nothing beats having that playable prototype early in development.

There are some problems, of course. For one thing, it's harder to project when the iterations will come to an end and the project will be complete. Outsiders (and sometimes insiders) might have a mistaken opinion of how far the project really is, assuming you are "nearly done" when you have really only started and have only mock-ups available. And then there's another problem that I've been running into which I call the "local maxima" problem, which makes it harder to turn that wheel and begin the iterative cycle again. You get to a certain plateau, and realize that the only way to make progress is to lose some apparent progress. It goes like this:

You've got the "prototype" working nicely. But in order to get it to the next level, you have to break a lot of things. Rip out some simplistic, hardcoded crap that made the prototype work and spend some serious time doing it right. You need to do some massive refactoring of some ugly Frankensteinian code. It means taking a sledgehammer to your pretty, delicate prototype and moving it along to a not-so-pretty stage in the cycle of the spiral development process.

It's daunting. Your game will be taking a step or five backwards. It causes fear. In me, at least - I finally recognized it, and realized that it was causing me to procrastinate a lot of tasks, seek out distractions, and otherwise end up in a slump far too many evenings. Not a paralyzing fear or self-doubt, just a reluctance to put the pack back on and slog down from my plateau for a while to get back on the long path to the summit. I was more content to play around with new features that were only adding to the game rather than replacing things, or "chrome plate" features I'd just implemented.

Now, there are a couple of steps I could have taken to alleviate this problem, now that I recognized it. One possibility is to make a backup of your code (using source control REALLY helps there), so you have a safety net in case you screw things up. Another thing to do is to take a snapshot of the current stage of the game and use it for demo purposes. Both of these are common industry practices, actually, and I've been getting a little sloppy about that.

In this case, once I recongized the problem it was 90% solved. Armed with a ruthless desire to break as many eggs as I needed to in order to knock some top-priority items off my hit list, I went nuts. By the end of only three hours of serious development effort, I'd nailed EIGHT items on my "hit list." Considering I've been averaging about 1.5 hit-list items per night, this really felt like a victory. Now, some of these items were kinda low-hanging fruit, but it was still nice to go forward "kicking tail and making games."

And, curiously enough, by the end of the evening the game was looking and playing better than ever. I'd completed a "mini-cycle" of development in only a few hours! Why had I been so reluctant to take that plunge before? Why had so many high-priority items been sitting on my task list for so long? That was EASY! Let's do that again!

I don't know if this little story will help anyone else - or if I'm the only one who gets stuck on those local maxima. But I do wonder about all these indie games that seem to wither and die once they get to the point of being an impressive "tech demo," especially with inexperienced teams. Could it be they get paralyzed into a low-productivity state because they don't want to (or even realize they have to) go back before they can go forward?

Labels: productivity

- posted by The Rampant Coyote @ 11:14 AM (Permalink)