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.

3D Realms could really have benefited from the advice on feature creep and “Save it for the sequel” on the Duke Nukem Forever project.

I hear tale that the development team actually tried to keep George Broussard away from other games at the time because he would always come back wanting to add some feature of them to Duke Nukem afterwards.

Of course, I guess the somewhat counter-intuitive advice to draw from a DNF example is NOT to have so much money available that you cannot conceivably have to worry about deadlines for over a decade.

Deadlines are damn helpful I’ve found. I would tweak my art forever if I didn’t have deadlines I had to meet so I could continue to afford to eat. Most people aren’t going to be near the perfectionists about your work that you are.

I worked on a game project with a team of fairly experienced individuals last year. We had 3 months to turn out a finished “something”. One person, our “game designer” had never worked on a deadline project with a team before. He had a ton of great ideas and concepts, but the team continually replied to them in a deadpan “the scope needs to be smaller”, “smaller”, “too big – make it smaller”. Our poor designer was pretty frazzled by the end of our first planning meeting. In response to our final plan for the scope of the game, he said “But that’s tiny and bare bones!” To which we all replied, “And extremely ambitious for 12 weeks.”

We were right of course, having gone through feature creep and scope problems before. As it stood, we STILL didn’t implement everything we had planned for by the end, but we got it done.

Maybe it is just a symptom of only working with indie teams or student teams (albeit talented ones), but I much prefer carrying a project on my own shoulders by myself. Someone inevitably flakes, or turns in a feature, or piece of code, or art asset the night (or morning of!!!) before we have to ship the final build of the game.

Once, on my first team game, someone turned in a pivotal character model 30 minutes before our final build of the game had to be posted on a server. Needless to say I had spent the night before working around the lack of said model and making the game work without it. I had quite the angry response for his hurt “you aren’t going to use the model?”

Personally the toughest tips to implement myself are the “make it playable as fast as possible” (because I am an artist first and programmer a far distant second) and “powering through the valleys”. Those valleys inevitably have to do with programming for me. Working on art is easy and relaxing and rewarding for me. Programming is slow, ponderous, frustrating, and even when I finish, I take no satisfaction in the finished work, seeing it as a chore I am just glad to be done with (which, inevitably, it never quite is, always needing to be revisited a couple of times later on).

I guess what I am saying is that everything not involving art or design falls under the “painful task” category for me.

I programmed a randomly generated 3D maze level using tilesets once, and had a bug where exactly 1 tile piece would be flipped the wrong way in every single iteration of the level. It took weeks and working through the logic of the code on paper to find it was because of a logic error in the formulas that only cropped up once the code had gone through so many loops.

Can’t I just stick to making things look pretty and awesome? Do programmers feel the same way about making “programmer art” as artists do about making “artist code”?

I dunno – I get pretty jealous of artists because they have the ability to really improve the game so very quickly with the addition of some quality artwork. Whereas programming… well, the game NEEDS to function, obviously, but you work so hard at stuff that’s pretty invisible…

> Pictures are all good and well but without the game they’re no more than a pretty slideshow.

Most consumers don’t even read reviews before plunking down their cash.
Pictures are what sell games. Oh, and movie licenses, too! 😉

Greg Squire said,

“Pictures are what sell games.”

There’s a lot of truth in that statement. I’ve noticed a trend among iPhone developers where a lot of them don’t even bother creating a “Lite” or “Demo” version of the game. They are relying solely on the screenshots and description of the game to “sell” the game. Not sure if that’s a good strategy, but perhaps that is enough for a $.99 game.