I have been working on a project lately and would like to get some help with some aspects I am not as familiar with in my skillset. I don't want to just randomly start recruiting anyone who will sign on and would like to put together a successful team and have a successful finished product so I am trying to make sure I prepare properly so my question is when is a good time to start recruiting? How much material should I have ready for review for potential members of the team? Also what is a good dos and don'ts on recruiting?

Depends on what you're recruiting for and what the work load is. You'll want to recruit different skill sets at different phases of the project.

Game design needs to be done from day 1.

Art and style guides needs to be done from day 1.

Programming can be done when 50% of the design has been figured out, though there's no harm in starting early.

Business planning needs to be done before the project even starts.

Marketing can be done when the project is about 90% complete (keep in mind, the last 10% takes the longest)

Writers can be brought in roughly around 50%-60% production phase (my guess).
Testing needs to be done when you've got something playable, but the testing work load ramps up as the project nears completion. You can probably get away with not having dedicated testers for the first half of a project. Keep in mind though, issues not found through testing snowball in the sheer amount of effort required to fix them. Finding and fixing problems early can save you TONS of time and money -- fixing hypothetical bug A at day of introduction + 2 costs a programmer 2 hours of work, which translates to $40 * 2 = $80. Fixing bug A at day of introduction + 200 costs a programmer 30 hours of work (due to refactoring all dependent systems), which translates to $40 * 30 = $1200.

When do you need to hire someone? When you have too much work built up for one person to handle or when you can't do the work yourself.

IF you have a lot of work, something someone can spend 40 hours/week doing, then you want to hire an employee.

IF you have a bit of piecemeal work, consider contracting it out instead.

Quick note on this: Contractors are generally more expensive per hour than employees, but will save you money if you don't have a lot of consistent work. You don't want to pay employees to sit around doing nothing. Employees on the other hand, give you consistency and continuity which you don't really get with contractors / freelancers. You generally don't want to contract out stuff which has a lot of stylistic variety, such as artwork.

IF you don't want to pay someone to work for you, be prepared to have them quit on you at any moment. Unpaid people have very little incentive other than their own morale / personal interests to stick around. If your making an unpaid person fill a vital role in your project, you're taking on a huge risk in terms of project management.

IF you want to build a geographically remote team of unpaid people, good luck. Not only may members drop off the project at any moment, you will also have huge communication challenges. You've got people all over the world with different time zones, languages, schedules, and cultural backgrounds. Project management and coordination of effort will be a nightmare. You're essentially operating a free open source project, where you should expect people to pop in and tinker a bit and disappear. Don't expect a lot of progress, or for the progress to go in the direction you want, to your level of satisfaction.

Depends on what you're recruiting for and what the work load is. You'll want to recruit different skill sets at different phases of the project.

Game design needs to be done from day 1.

Art and style guides needs to be done from day 1.

Programming can be done when 50% of the design has been figured out, though there's no harm in starting early.

Business planning needs to be done before the project even starts.

Marketing can be done when the project is about 90% complete (keep in mind, the last 10% takes the longest)

Writers can be brought in roughly around 50%-60% production phase (my guess).
Testing needs to be done when you've got something playable, but the testing work load ramps up as the project nears completion. You can probably get away with not having dedicated testers for the first half of a project. Keep in mind though, issues not found through testing snowball in the sheer amount of effort required to fix them. Finding and fixing problems early can save you TONS of time and money -- fixing hypothetical bug A at day of introduction + 2 costs a programmer 2 hours of work, which translates to $40 * 2 = $80. Fixing bug A at day of introduction + 200 costs a programmer 30 hours of work (due to refactoring all dependent systems), which translates to $40 * 30 = $1200.

When do you need to hire someone? When you have too much work built up for one person to handle or when you can't do the work yourself.

IF you have a lot of work, something someone can spend 40 hours/week doing, then you want to hire an employee.

IF you have a bit of piecemeal work, consider contracting it out instead.

Quick note on this: Contractors are generally more expensive per hour than employees, but will save you money if you don't have a lot of consistent work. You don't want to pay employees to sit around doing nothing. Employees on the other hand, give you consistency and continuity which you don't really get with contractors / freelancers. You generally don't want to contract out stuff which has a lot of stylistic variety, such as artwork.

IF you don't want to pay someone to work for you, be prepared to have them quit on you at any moment. Unpaid people have very little incentive other than their own morale / personal interests to stick around. If your making an unpaid person fill a vital role in your project, you're taking on a huge risk in terms of project management.

IF you want to build a geographically remote team of unpaid people, good luck. Not only may members drop off the project at any moment, you will also have huge communication challenges. You've got people all over the world with different time zones, languages, schedules, and cultural backgrounds. Project management and coordination of effort will be a nightmare. You're essentially operating a free open source project, where you should expect people to pop in and tinker a bit and disappear. Don't expect a lot of progress, or for the progress to go in the direction you want, to your level of satisfaction.

This helps me a TON on what needs to be done. Thank you!

If he's talking about getting people to work on the project for free, though, these things become much more complicated.

Game design needs to be done from day 1.

Only as little as possible to avoid severe creative differences.

Nobody wants to work for free on somebody else's game design. It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.

You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members. Such as: one only likes JRPGs, the other only likes FPS - how do you resolve this? You don't. You only recruit one of them based on their having similar interests in line with the overall goal.

Narrow it down only just enough, but leave it open so contributors can feel like it's their game. Achieving that balance in itself is something of an art.

Art and style guides needs to be done from day 1.

Where volunteer projects are concerned, that's almost impossible. People will come and go from week to week, maybe only contribute a couple sketches, or one sprite. Things are unfortunately very unlikely to match.

And most artists who will work for free are both unwilling and unable to follow a strict style guide.

The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.

For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets. They are also more motivated by fandom.

However, this is also illegal.

For programming, it's a little easier for somebody to drop in and contribute a function or two.

In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.

If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment. You'd basically just be finding an artist to work for to make his or her game idea. And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.

Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.

Some very valid points thank you. I plan on doing a 50/50 deal where the project is concerned. What I would really like to do is get a small group together, maybe 2-5 members and form a permanent team for this project and future ones as well to share the revenue equally with and pay for services we need from freelance/professionals as the project calls for it. I realize this is a large goal to have but something I have been wanting to make happen for quite some time. I don't have any high expectations of his happening over night and I will be doing as much work individually as I can until I achieve success so I am making sure to set some guidelines to follow. I had a team I worked with before on a MMO project and it failed miserably due to A LOT of the circumstances you guys have listed and what you have posted is really going to help me with this so it is much appreciated. Thanks guys!

If he's talking about getting people to work on the project for free, though, these things become much more complicated.

Yes, I agree. Free labor is cheap, but you get what you pay for. I think volunteer projects are great for learning new things and getting experience, but it's excruciatingly difficult to seriously build a game which you want to release based on free labor. I personally would never attempt it or join a volunteer project. That's not to say it can't work though. I met a team of developers upstairs in our building who are all working together for free on an HTML5 MMO (top down shooter). Each of them are living off of personal savings from prior jobs and have been slaving away on this project for almost two years. One of them has until next summer until his bank account runs dry, so you can guess what kind of stress and pressure they're under. So, I suppose it's worth noting that "free" labor is never free for everyone -- bills and living expenses don't stop.

Game design needs to be done from day 1.

Only as little as possible to avoid severe creative differences.

Nobody wants to work for free on somebody else's game design. It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.

You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members. Such as: one only likes JRPGs, the other only likes FPS - how do you resolve this? You don't. You only recruit one of them based on their having similar interests in line with the overall goal.

Narrow it down only just enough, but leave it open so contributors can feel like it's their game. Achieving that balance in itself is something of an art.

I disagree and still stand by my original claim.

Imagine you're brought on as an artist onto a project and are told by someone, who doesn't really know what they want, to make the art for their game. You have no idea what they're trying to build and it could change at a moments notice. A detailed game design is something solid to stand on and something to work off of. It tells you exactly what needs to be built and how it should all work together with other parts of the game. Without it, it's like you're standing on a constantly shifting sand dune which changes form with the winds. When you have to build concrete assets, it's excellent to have as much requirements definition as possible. Naturally, the game designer can't detail out every single nuanced detail, so the *creative* part for an artist is in the actual creative production of the asset. The look, feel, character, style, etc.

If you think the artist is going to be annoyed by a lack of definition, just imagine how much more annoyed a programmer would be (speaking as a programmer myself). I WILL not write up a complete game system if I don't know exactly how it needs to work. There isn't any "figure it out as you go". I also happen to design my own game, but I haven't designed all software I've built. There is nothing more sexy to me as a programmer than an air tight design. There's no thinking required, just implement it to the spec! There is no confusion. You know what needs to be built. It's very refreshing to work on projects with clear definition.

One thing you do allude to, which is critical, is "stakeholder buy-in". You don't need to give everyone on the team creative control / input on the game design. Chances are actually really good that most people are actually not very good game designers. It's actually *really hard* to do correctly. A programmer is an expert at writing code. An artist is an expert at art. A producer is supposed to be an expert at project management. A writer is an expert at writing. Game designers are experts at building game systems. You wouldn't want your artist writing code, or your programmer creating art, so why would you have either of them doing game design? That's not their specialty, and not the only way they have creative input into the production of a game.

Art and style guides needs to be done from day 1.

Where volunteer projects are concerned, that's almost impossible. People will come and go from week to week, maybe only contribute a couple sketches, or one sprite. Things are unfortunately very unlikely to match.

And most artists who will work for free are both unwilling and unable to follow a strict style guide.

The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.
For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets. They are also more motivated by fandom.
However, this is also illegal.

For programming, it's a little easier for somebody to drop in and contribute a function or two.

In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.

If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment. You'd basically just be finding an artist to work for to make his or her game idea. And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.

Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.

Yes, this is bad. What you describe is exactly what you want to avoid in a serious project. Pick any well produced game and really look at the art style in it. It's consistent. The color palettes are intentionally chosen to create an intended feeling / atmosphere. Think of Skyrim, how they have a bit of a saturated color palette and pretty realistic character models and environments. Now, imagine what Skyrim would have looked like if they had 30+ artists come in, each with their very own unique interpretations on what the game should look like. Some would go for a my stylized approach, others go for hyper-realistic, some go for cartoonish, etc. In a vacuum, each art asset would look good, but when you put them all into the same universe together, you can't convince the player that the game world has consistency and you break the suspension of disbelief, which causes a loss of player immersion (which some mods break).

As for programming, it's equally problematic to have people pop in and write up a function or two and disappear. As a programmer, you *have* to be familiar with the code base / framework you're working within. That costs time for us to get familiar with it (ramp up time). If a programmer doesn't spend time getting familiar with what they're working with, they run a huge risk of breaking something or writing code which has already been done.

Anyways, I guess my whole point here is that people are super important to the success of a game project. In some jobs, people can be treated like interchangeable components -- not in game development! The ramp-up time for a person to really get into a project and become an expert is long, and you can't ever carelessly throw away your most valuable resource (staff) through people mismanagement. If you're going to be serious about building a game and releasing it commercially, you can't afford to screw up the building of your team. If you're just working on a school project or hobby project, recruit away!