Eight Tips to Help You Finish Your Indie Game

Posted by Rampant Coyote on November 22, 2010

A request for suggestions in the forums over the weekend reminded me of some advice I’ve often given to indies. Though, considering how long it has been since I have released a commercial indie game, I wonder how much of a hypocrite I am giving out any kind of recommendations. But hey, if nothing else, I can serve as a clearinghouse of third-person suggestions, right? None of these pieces of advice originated with me, but I do believe ’em (even if I don’t always follow them).

1. Keep It Simple

I’ve often said that indies really, really need to keep it simple. Particularly when first starting out. What “simple” means is deliberately left a little loose. What’s simple to an experienced, veteran game developer might be hopeless for a newbie. I caught a little bit of grief over my “game in a week” project because of this – because what was possible for me was far more complex than most beginners could achieve. The telling thing for me, however, was how little of my intended scope I was able to implement in that time.

But especially for a first-time project, keep it simple. Painfully so. Cut your design down to the smallest, purest levels of gameplay. Strip down your art requirements. Make something that you feel absolutely certain that you could finish in under a month with time to spare. With that, you’ve got a chance of being done inside of half a year. Because these things always take much, much longer than expected.

#2 – The Secret of Scheduling and Budgeting

I’ve frequently been asked, “How do you calculate the schedule for your game design?” Now, if I were the one to ask on a question like that, Frayed Knights would have shipped a year and a half ago. But really, what it really comes down to is establishing a baseline through a history of projects, and comparing your current project against it. If you have a new team put together,  it’s going to be very hard to nail down a projected schedule in advance. This is especially true if it is a team of part-time indies volunteering their efforts for a stake in the final release. What are their capabilities? How fast can they develop? How motivated will they be when the initial honeymoon period has worn off and they are down in the trenches turning a proof-of-concept into a real, robust game?

Thus the advice of starting small and simple, above. That can serve as a baseline.

One almost universally employed trick  is to do all you can to break the design down into a series of smaller tasks. They should be broad enough to encapsulate the entire game (and yes, no matter how hard you try, you’ll discover additional tasks at the end that were never considered), but small enough to be able to wrap your head around and complete in a reasonable, finite period of time. Say, a week. Maybe two, at the outside. If you find that each team member has a hundred tasks that should take one month each, you’ve probably uncovered a flaw in your project plan – namely, the scope of the project.

Assuming everyone has about 8-20 tasks that should “average” about a week to complete, measure the actual time to completion as the tasks get knocked down. If all your one-week tasks are taking three weeks and your two-week tasks are taking six weeks, you’ll know you underestimated task completion time by a factor of three. Now you have some data on which you can estimate project completion time. Then double it. ‘Cuz you’ve missed almost half the tasks that should be on your list.

#3 – Make It Playable as Fast as Possible

Get as much of the game integrated into an actual, playable game as quickly as possible. Even if 90% of the features and gameplay are missing. You need to be working with a functioning prototype as quickly as possible.

There are hundreds of good reasons for this, but the biggest one is that when your game transitions from being a “paper prototype” in a design document to a real, working prototype, it is going to evolve and change. The sooner that happens, and you discover all the holes and changes that need to be addressed, the faster and cheaper it will be for you in the long run. You don’t want to wait until the last minute to find out that all of your levels need to be re-done to include AI pathing data and a different collision system.

And the sooner your game is playable, the sooner you can find out what works, what doesn’t,  and what you should focus on for the final product, the better the final product will be.

#4 – Develop a Cautious Relationship with Scope / Feature Creep

Inevitably, as your game goes from being a simple concept on paper to an actual, playable game, you will get a better idea of what’s fun, what’s not, what would make the game better, and (if you are good) what should be removed to make the game better.

Scope creep (AKA feature creep) happens naturally. And it is not, as some managers might say, always a bad thing.  Making games is more art than science, and sometimes the most awesome, killer ideas that “make” a game are the ones that occur to the developers late in development.

Feature creep can be your biggest ally, but can also destroy you.  If you tried to implement every good idea, you’d never finish your game.  You need to respond aggressively to it – keep it if it’s got the potential to really kick the game into high gear, or use it to replace a weaker existing feature that should be dropped (ideally before you’ve spent much time on said weaker feature), or nip the idea in the bud.

Or use suggestion #7, below.

#5 – Be Able to Carry the Project on Your Back

There’s a tendency for many first-time indies to band together for a common project, each contributing to a shared vision of a dream game. Unfortunately, these collections of pooled effort almost always end badly, shortly after the first “key” member of the project drops out.

My general feeling is that unless the indie is running a full-time studio with real employees, every project should be scoped as if it was a “lone wolf” solo effort.  There should be one person in charge, and that person should be the one most capable of carrying the project on his back – doing it all himself – if need be. This doesn’t mean he should do it all himself, only that – if all else failed – he could. And he should seriously be “in charge,” capable of replacing any person on the team – with his own efforts, contractors, or a new recruit.

Otherwise, you have a “weakest link” problem.

#6 – When In Doubt, Cut It Out

When you find that things are taking too long, especially when they are threatening to send the development process into limbo (I’ve been there many times, thanks…),  there are several approaches you can take. Lots of project management tools you can choose from. At least, so I’m told. I only know of a few. You can search for bottle necks, re-assign tasks, bring in additional help, find out ways of automating routine tasks, etc.

Or – best of all, you can “scrub out” tasks. Simplify. Cut it out. Back when I was working on the original Twisted Metal game, we used to call the producer at SingleTrac, Scott Campbell, “Sargent Scrub.” He wore the nickname with pride, I think, because he was so quick to scrub lower-priority features and levels. The funny thing is, I can’t remember any of the undoubtedly cool-sounding features that were cut. In the end, the game was a success without them. He made the right call. It kept us on schedule, and allowed us to devote time to the more important parts of the game.

#7 – Save It For the Sequel

I’m sorry to tell you this, but in the end, your game will probably not be all that you dreamed it would be. Things won’t have worked out as you planned, the quality won’t be quite what you wanted, and there will be all kinds of features you really wanted to see in there. It will never be perfect.

Guess what? That’s what sequels are for.  You can iterate forever in a vacuum, or you can get your game out the door, get feedback from your audience, and release a sequel that is better than your original game would have been after even ten years of development. Even if you have no current plans for a sequel, keep it open as a possibility so you can toss ideas in that mental file with less guilt.

#8 – Power Through the Valleys

In every project, you are going to hit peaks and valleys of productivity. The valleys follow the peaks naturally – after some awesome new additions to the game get implemented, you go through a patch where you have to debug, refine, optimize, and lay the foundation for the next big feature. It can sap morale, as so much effort goes into development with little to show for it.

I don’t know of any silver bullet to help with these times, other than to understand that they are a natural part of development, and don’t spell the “death” of a project unless you allow it to be so.  Expect them, and be prepared to power through them.

One trick I used when developing Void War was to arrange my task list (of “mini-tasks”, usually ones that would only take an hour or so) into groups of “fun” tasks, painful tasks, and tasks for things that would enhance the playable game immediately. I’d then complete these tasks in groups of three. Powering through the painful tasks (like fixing a collision bug) and the not-so-fun tasks that would make obvious (morale-boosting) improvements to the final game would bring me closer to being able to work on a “fun” task again.

So there you go – eight tips to hopefully help you finish your indie game. Strangely enough, the closer I get to the finish line on mine, the more valuable I see these tips in helping me get there again, too.

Good luck, and have fun.

Filed Under: Game Development - Comments: 13 Comments to Read



top