Six Ways to Avoid “Development Paralysis”

Posted by Rampant Coyote on May 22, 2012

There’s a term called “Analysis Paralysis” where the final decision is long-delayed while an analysis and deliberation of options goes far beyond a reasonable amount of time. While there’s a lot of discussion about it, what it really comes down to is fear – fear of making the wrong decision. By putting off a decision, people can delay the consequences of making a possibly bad decision.

In game development – and sometimes other forms of software development – there’s a similar phenomenon that I guess we could call “Development Paralysis.” I’ve referred to it before as the “Local Maxima Problem,” and I think it’s a reason most first-time indie developers fail. I still struggle with it from time to time, and I’ve been doing this for … uh, a while. Yeah, I still procrastinate, especially when big changes are necessary.

What generally happens is this: With games, in particular, development is an iterative process. While design and technical documentation up-front can help lay the foundation, ultimately making a game is an artistic process as much as a technical one. Things change. Prototype “proof of concept” code must give way to more robust development code, aspects of gameplay must be ripped out or replaced, and there will be plenty of times where serious overhauls (or less serious refactoring) will have to be done on the code as the game goes from its early stages to a finished product. Many times during production, this means that the game will have to break in order to get better.  You have to descend from the current ridge to make your way up to the summit.

This is most commonly a programming thing, but it’s not entirely restricted to that. As a writer, if you have to make a major change to a character that has ramifications through the entire script, it’s a similar feeling. As an artist, having a technical change that requires you to go back and tweak all of your old models would be a similar challenge.

This can be frustrating for many people – myself included.  As an indie, at least, you don’t have to explain to your boss why the AI that seemed to be working “90% correctly” last week is now completely non-functional, but it can still cause the kind of “paralysis” and avoidance that can really stall a project. Hobby projects – where the external motivation of being able to pay the rent is not a factor – are particularly vulnerable. I have seen countless indie game “alphas” (or “pre-alphas”) that have disappeared  forever after showing a promising demo that was “70% complete” or somewhere thereabouts. The problem being that the last 30% was going to take three times as long as the previous 70%, the developers realized it, and it can be very hard to bite the psychological bullet and spend a month re-writing a system that only took a week to write the first time around – just to see a small improvement.

As a result, motivation drops, other aspects of the game get “gold-plated” while the fundamental changes are avoided, frustration mounts as the game is in a “broken state” for a long time (particularly among other team members), and so forth.

So here are some of my suggestions for getting over that particular hump.  I’m sure there are others:

#1 – Recognize the problem. I’ve said it before, and it’s still true: Recognizing the problem is the first step to dealing with it. Sometimes it’s the only step really necessary. But for those who need a psychological boost, here are some others:

#2 – Focus on the end goal. It’s why you are making games, right? Pysch yourself up by thinking of how cool / easier to work with / faster things will be once you’ve finished this particularly cumbersome task. Yeah, so the entire data structure needs to be changed and all the existing data needs to be run through a converter, but when you are done you and your team will finally be able to do X, Y, and Z. Focus on that.

#3 – Use source control / make backups. You should be doing this anyway. It’s a lot easier to start slashing and burning when you know that your previous hard work isn’t going away, and can still be there for reference. No acrobat practices without a safety net, and your development acrobatics shouldn’t be exercised without one, either.

#4 – Work from a checklist. Getting in the habit of being checklist-driven will help in innumerable ways, but in this case can help you recognize when there are some tasks that you have been procrastinating for too long. One thing that works for me is making a habit of tackling a set of tasks as a group, one of which must be a really bitter-tasting, ugly, pain-in-the-butt task that I’m otherwise prone to procrastinate.

#5 – Break the ugly task into smaller pieces. If a serious overhaul is slowing you down because it’s daunting, take some time to figure out if there is any way of staging to re-write in smaller steps. Sometimes this isn’t possible, but I find that for myself, it’s often easier to take a series of shorter sprints than a marathon.  Or in these cases, a number of medium-length jumps is easier than trying to hop the Grand Canyon in a single bound.

#6 – Make an internal team build “snapshot” of the currently running code. Again, this should be a no-brainer, but in tiny indie teams it can be forgotten.  Where possible, other team members can still work against this old reference, and you still have something to show while waiting for the new version – your massive overhaul – to get up to speed. In a week, you can happily delete that version because it’s embarrassingly bad, but while you are making your changes it can feel like you are losing stuff forever.

Yeah, this sounds like a dumb problem, and maybe my tricks to avoid the problem sound dumb, too. Except for the source control part, as that’s pretty much standard procedure for most experienced developers (but hey, maybe the newbs don’t know about it yet). But we’re all human. Even the crazy indie developers with their crazy work hours and stuff.  Maybe this will help.

Filed Under: Game Development, Programming - Comments: 4 Comments to Read



top