Jump to content
  • Advertisement
Sign in to follow this  
okiedoke

Getting to know devs and creating partnerships.

This topic is 2904 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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".

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
You have to get to know each contributor well enough to understand his motivation for wanting to join your project. You have to find common ground. If his motivation is not in line with the project goal, then you know not to accept him aboard. Once you have a team working on the project, when someone starts to fall behind, you can sway him by reminding him of his motivation for participating and show him how working can help him achieve his own goal.
And you absolutely do need to get agreement up front on expectations. Your expectations of each contributor, and what the contributor can expect from the project. Who owns what IP, and what happens to someone's past contributions if he drops out. Everything has to be set forth right up front.

Share this post


Link to post
Share on other sites
If you're doing a non-paid project with others over the internet - and have never met face-to-face - then it's very hard to get a project off the ground. Personal tastes, egos, lack of skill - you get the idea.

Instead of a team, look for a programming buddy and make your first game something simple such as an Asteroids clone. This keeps things simple, and if the other person buggers off, its a project you can finish on your own.

A good, deep insight in to what makes a good team is the book "Masters of Doom" by David Kushner. Actually, it shows you how even a talented team can really screw things up, but their mistakes are worth learning from, if you get what I mean. Also, reading articles in Retrogamer magazine can also give you an insight into how some companies operate...

Another thing to look at is games made for the Home Computers back in the 1980s. They were produced by either "lone wolves" or 2-3 man teams, and the most valuable member would be the programmer. And rightly so, because making a game requires a good mixture of programming, maths and software development. Without those you simply don't have a game. However, team up a good programmer with a good artist(both visual and musical) and you have a recipe for success.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!