It seems to be a challenging thing for me to do. Here's the scenario:

I will find a dev team or just one person and get really excited about a project.

But then one of a few things might happen.

Possibility number one: The team will do a few good weeks of work but soon loses interest and now it's like pulling teeth to get people motivated. Many leave, project fails.

Possibility number two: You and one other person are constantly in disagreement, where at first it wasn't that way. Now either you or them are leaving the project.

Possibility number three: The project changes scope every other day and hours of hard work are wasted. Team members loose interest and think of project of waste of time.

Possibility number 'x': expectations are set. they are not met. people flee.

but is 'x' the real root of the problem? What's the best way to find like minded people to team up with? (someone once told me "cash is like people glue", but I'm thinking of free resources)

- Thanks in advance

Alex Earley

I think having something tangible is key when recruiting a team. Personally I would find it more encouraging if someone had more than just say a design document (or as in most cases a vague description of what they want).

This solves possibility 3 as the project wont change every day as it is solidified, possibility 2 is down to your position in the team if you are leading your not exactly going to abandon your own project and your word should really be final. If you are stubborn when you are wrong you will lose team members not just those you disagree with.

Personally I am going to spend some of my summer working on the beginnings of a project, it has been sitting in my mind for the past couple of months though due to exams I wasn't in a position to really work on it. As a programmer I intend to plan out the game in a design document, begin working on the actual game and tools (so it is playable with programmer art) then start looking for people to do things like artwork and sound.

People like to see something that is already there rather than "it will be like this...eventually".

Thanks for the reply,

I'd like to share some recent insight on the matter.

A few people expressed that if it's an indie project (with little or no pay) it needs to be expressly interesting to them and the others need to be gaining some thing out of it.

Also one should never assume someone is going to do work your are not willing to do.


"People like to see something that is already there rather than "it will be like this...eventually"."

What is your take on an open source project then. open source projects will have trouble starting if there isn't much to show in the first place. Should an open source project get started right away or half way into the development.

Another question is, Once in open source how do you 'recruit' or is that even important?


These may seem like simple questions, but I am looking for insight, not just simple answers.

Quote:A few people expressed that if it's an indie project (with little or no pay) it needs to be expressly interesting to them and the others need to be gaining some thing out of it.

People don't like doing hard work for free and no personal gain. I don't think this is particularly difficult to grasp.

Quote:Also one should never assume someone is going to do work your are not willing to do.

Of course, the first question is why is someone doing the work in the first place?

Quote:What is your take on an open source project then. open source projects will have trouble starting if there isn't much to show in the first place.

All projects have trouble starting when there isn't much to show in the first place. With an open source project, it's just much more apparent how little there is, because your code is open as well.

Quote:Should an open source project get started right away or half way into the development.

If you are asking if the license should be established after development has started, my response is that it's best to establish licensing issues as early as possible. You want to resolve ownership and then distribution licenses as early as possible.

Quote:Once in open source how do you 'recruit' or is that even important?

Just like you recruit for any other project.

Quote:but I am looking for insight

Ok, here's something. Open source does not mean "automatic free labor". Open source is simply a category of licensing.

Thanks for the insight guys.

Most people try to recruit team members for the goal of implementing a specific game idea. That's difficult to do because usually there's only one person on the team for whom that game idea is their passion. This is the core problem.

How about changing that? Recruit a team for the purpose of forming a studio. The goal of the studio is not to make any one specific game, but rather to build and strengthen the studio itself over time. With that stated goal in mind it becomes easier to retain people because everyone's goals are now the same... to bond and strengthen as a team. To that end, small sensible projects are chosen in the first few years that will allow the team to gain experience working together.

The most important thing for the team leader is to remind those who try to increase the scale and scope of any chosen project that the goal is to be sensible and stay within the skills and abilities and experience level of the team... not tackle dream projects.

The smaller your first project the better. This can't be overstated. Try to make a first game that takes no more than 3 months to complete. Think space invaders, pac-man, donkey kong. Try to take a proven game design or set of game mechanics and re-imagine it for 2010. Build the teams experience in completing games start to finish.

Good luck.

disclaimer: ive not tried any of this so i'm just talking out of my rear :)

EDIT: Anri makes some very good points as well. Since you're going to be start by making small games, start with a very small team.