Whether you're a beginner, hobbyist, aspiring game developer, or a seasoned veteran, this article provides some great guidelines and hints for creating a great Indie game development team.
The article assumes you're putting together a zero or low-budget team to build an Indie game. It answers questions like "Who is the leader?" and gives you great advice on how to keep your team motivated and making constant, steady progress on your game.
If you're considering starting a game development project or if you're already part of a team, this article is definitely a must-read.
Who is the Leader?
You of course! You're the one that has all of the ideas, you should lead the project. You should also reap most of the rewards since everyone else is just doing what you ask them to do.
In order to put together a successful team,you must find a strong leader. This leader must be able to finish the entire project by going solo, although he might not be able to do certain aspects as well as someone else.
Generally this is a person that's a skilled programmer, artist and/or game designer that's also a dabbler in the other three subjects.
Reserve the "project leader" title for when you have a fairly large team with many people wearing the same hats and it gets to the point where it's obvious that you need a designated leader… and by that time it should be obvious who that leader is.
The person doing the bulk of the work and pushing things forward is the leader. The leader should lead by example. He pushes forward and gets things done. He blazes the trail and sets the direction and everyone else follows. Other "management" styles won't work… someone dictating what needs to be done is a dictator, not a leader.
A good idea is to start things out as a democracy and once the team gets large enough you elect a leader. This especially works when everyone on the team has read this article and agrees with the bulk of it.
Avoid Position Titles
Position titles like Programmer, Scripter, Artist define one hat that a person wears. If you put a hat on a person, give him a title, he's less likely to wear multiple hats.
Don't do this!
Encourage everyone on your team to wear as many hats as they possibly can wear, with one exception… the game designer. Although the game designer should be encouraged to wear other hats too, there should only be one person as the designated game designer. I'll talk about this in more detail in the next section.
Also, avoid "Lead Developer", "Lead Artist" for as long as possible. If you have only one person doing all of the programming and he's a good programmer, feel free to let him call himself "senior programmer" but avoid and discourage "lead programmer" type titles… as soon as you recruit another programmer, what happens if he's a better programmer and able to put more time into the project? Demoting someone from "lead" positions is difficult at best… and many times results in morale issues and team breakups.
If you need a designated leader for a given subject area, it's best to resort to democracy, with those in that subject area having votes that weigh more than the rest of the team's votes. Complicated, I know, but it's better to let the programmers elect their leader without the artists weighing in too heavily on the vote, otherwise it becomes a popularity contest and ends up electing the most likable person, not the most qualified person.
One and Only One Game Designer
A game design created by a committee (or worse, created by the community) is a disaster waiting to happen. Too many times I've seen Indie / hobbyist games with a game design put together by a committee of inexperienced game developers, and the game flounders and drags on forever and nothing ever really gets done.
You should have one and only one lead game designer. That game designer should have absolutely zero input from anyone on the game design. He can collaborate with people writing back stories, art, etc, but he shouldn't seek input from them on game mechanics, etc.
Ok, now you're thinking I'm crazy and completely wrong… but go with me on this for a minute.
Game designs are crap shoots. Even great game designers create game designs that flop, and the only real way you can tell if a game design is fun is to play it.
Keep the game design minimal and implement it as soon as possible…. then and only then should the game designer as for feedback, thoughts and comments. Feedback should be based on actual game-play experience.
And that leads me into the next section…
Ship Early, Ship Often
As soon as you have a playable albeit incomplete demo, ship it internally to all of the developers and let them play it.
Even if it's not finished. Even if it has nothing more than a splash screen and a simple scene with a camera flying around. Even if it's an MMORPG and you don't even have multiplayer aspects finished.
And once you ship something internally, continue distributing patches and updates… try to automate the process so the updates can happen weekly or at a minimum once a month.
When people see something new, they are motivated to contribute more. Team members will motivate other team members this way…. try to get your team to realize that it's more important to develop iteratively and do an internal publish of an unfinished product than it is to never have something visible to show.
Enthusiasm feeds enthusiasm, and shipping early also lets other members of the team play the game and provide feedback to the game designer earlier rather than later.
When you play a game, even if it's not finished and even if the artwork looks like crap, you can tell if it's going to be fun or not… it's better to find that out as soon as possible. It also gives the game designer and other team members the ability to identify emergent game play… typically mistakes or unexpected and unplanned features of the game can be a whole lot more fun that the originally planned game design.
Take advantage of it, it's well worth the pains of having to create your distribution and patch system up front.
Your goal should be to have an internally distributable game within 30 days of starting the project, and you should have major features implemented within the first 90 days. In other words, if it's going to fail, fail early.
Fix Bugs Immediately
While features can remain broken and incomplete, don't stand for bugs that cause application crashes or other instabilities. Fix them immediately, otherwise the benefits of "Ship Early and Ship Often" will be negated.
Have a bug tracking system that everyone on the team can use, and every time there's any kind of bug have them enter it.
Version Control and Branching
There's nothing more important to a game development project than version control and branching.
All new features should be implemented in a branch, while the trunk of your version control system remains your "golden stable".
You should take advantage of peer code reviews and peer art reviews… the person or people who do the work should not be the person who merges the branch into trunk and do the reviews.
Keep branches short lived. While you can distribute an internal distribution from a branch to test a new feature, it's not a good idea to have multiple branches being developed simultaneously for an extended period of time.
Don't forget to create tags for every release, whether it's internal or not. You never know when you're going to need to be able to reproduce a given branch.
For further reading, check out my more recent article about all of the Early and Often things developers, not just game developers, should do.