For the past several months we've had a lot of people join The Allacrost Project and many of them, I'd say roughly 50%, are either "no shows" that do not work or communicate with the team in any way after they join, or they are essentially "quitters" who disappear after a couple of weeks of communicating with the team and/or digging around and getting to work. Almost all of these people have been programmers, though there were a small number of other contributors as well. The question I wish to ask is: "Is this something that you commonly experience with your own projects?" In the early days of our project this wasn't a problem at all (our project is over five years old now). Everyone who joined our team in the past was serious and put in a decent effort. But more and more this has become an issue our team has had to deal with. Its frustrating because it does cost us time and effort whenever a new person joins our team since we have to setup accounts, get them up to speed, and figure out a good place for them to start. I'll share more about our hiring process later, but for now I'd like to hear the stories of others. Do you find a lot of "flaky" people joining your own team?

It is a difficult reality when it comes to game projects that do not pay its contributors. It is possible to find ways to better motivate members and increase retention during the initial screening process, but as long as there is no pay/compensation, there is nothing really stopping them from deciding to not contribute. Sometimes they have tons of motivation during the application process, but soon after joining, they become busy with school, work, another project, etc. and stop caring.

I've had similar problems in past projects. In my most recent project, I made it a point to work with someone I know in real life. Our personalities are fairly different, but we just feel a greater deal of accountability since we know each other personally.

My recommendation? Establish that deeper level of communication. This isn't a fix-all solution for everyone, but I've had good luck by having Skype calls with my team. Video calls are even better. The project is made more real for them. My buddy is in another state now, but we video Skype during our dev sessions. It works great.

By the way, your project looks awesome. It has some of my favorite 2D art I've seen in a long time.

Most people won't/can't work if they aren't getting paid by the hour and don't have a manager to fire them if they stop. This doesn't stop them from signing up for new projects, unfortunately. In fact, those people generally join the most projects since they can't ever stick to one.

In hobbyist game development it's especially bad since most people won't/can't distinguish between "wanting to work on the game" and "wanting work to be done".

Even personal connections can't always save you. You just keep trying new people until you find someone with some semblance of work ethic and self-motivation, or you do things yourself.

But honestly if you're working on a game project for five years I think you fall into the "flaky" category by default.

Quote: Original post by LockePick
Even personal connections can't always save you.

In fact, they're often worse. It's a very effective way to kill friendships.

LockePick nailed it. Most people cannot distinguish between "wanting to make a game" and wanting to "put work into making a game". If they aren't being paid or compensated -most- people will drop out as soon as they encounter any kind of difficulty (including actually working, or just a difficult part of a problem, or something that isn't "fun" to them).

I'm surprised it's only 50% who join and do nothing.

Let me recommend a more rigorous screening process if you don't already have one. Require a resume and portfolio, but since you aren't paying just be pretty open to people with less experience. Feel free to explain the reason for the requirements so people realize you aren't going to be super picky, it's just a way to screen. The act of requiring that means you'll get more serious people, and if you see finished games in their portfolio then you know they at least have the capacity to stick around.

The counter-problem to that is if your project isn't attracting enough people this may cut off a few helpful individuals who may have applied.

This is not meant in any offense to you, but part of the lack of motivation might be inherit in the project.

Going by your website, you have no gameplay videos and just a few screenshots. Over a 5 year period that's not really a great showing. I'd have a hard time being motivated to work on a project that's already got 5 years into it with relatively small gains being made as well.

Progress is a great motivator for more progress. I understand it's a bunch of people working for no pay in their spare time, so don't take this to offense. Just be aware that the symptom is not always the same as the disease.

Quote: Original post by LockePick
But honestly if you're working on a game project for five years I think you fall into the "flaky" category by default.

Why? Are amateur teams of hobbyists with rather grandiose project goals expected to finish in 2-3 years tops? That would be news to me. Maybe if I had worked on this project full-time for those last five years I'd expect more out of myself and our current state, but I think given the circumstances we're doing just fine. Just my opinion though.

I think five years of steady progress displays "commitment", not "flakiness".

Quote: Original post by way2lazy2care
Going by your website, you have no gameplay videos and just a few screenshots. Over a 5 year period that's not really a great showing. I'd have a hard time being motivated to work on a project that's already got 5 years into it with relatively small gains being made as well.

We also happen to have several playable releases (did you check the download page?), our last one being less than three weeks old. No, we haven't produced any gameplay videos ourselves yet, though others have played the game and used our editor and put them up on youtube/vimeo. If you want to call those small gains, that's fine. There was a big learning stage for us initially and we made the decision to design our own engine (easily a good two or three years by itself right there). Personally I think its a damn good thing to have such a history, since the vast majority of projects die or disappear within months. At the very least it shows that we are committed and established.


Anyway, I don't want to turn this thread into a discussion or critique about my project in particular. So lets leave that aside and address the more general problem here, since its clear that I'm not the only one who has it.




I agree that LockePick has a good point and I never thought about it that way. I think I have trouble identifying with these sorts of people that join and leave because once I commit myself to something, I see it through to the end no matter what. So I'm very careful about what things I commit to in my life since I never break my commitments.


Yes, I realize that it can be hard to motivate yourself to work on a project when it doesn't pay the bills or they can't be fired (although we have actually fired people from the team in the past). But honestly, people who apply to our team upfront know that there is no remote prospect of any financial compensation. They have access to the code (since its open source), the art, the playable demos, documentation, etc. etc. But I still don't understand why the take the time to fill out and submit an application (although it takes less than five minutes) and then just decide to not do anything. What are they thinking? If they are too busy to work on the project, why did they bother signing up in the first place? It makes no sense to me.


I have noticed that people who tend to come on our IRC channel and ask questions or just chat about the project have a much, much higher retention rate than those that just read one of our help wanted posts on gamedev or elsewhere and send in an application.

Quote: Original post by M2tM
Let me recommend a more rigorous screening process if you don't already have one.

Interesting for you to suggest that, because in the past that's exactly what we did. We had a pretty intense screening process, requiring people to fill out a much larger/longer application, bounce back a few e-mails between us and the team, and the entire team took a vote on whether the person should be invited to join us or not. There were problems with this though. It took up more of our time to deal with new hires even if they didn't work out and like you said, there's a chance we might have turned away some people that could have really been a great help to us.

Our current model is to pretty much accept anyone onto the team that submits an application so long as we have space for them in the area to which they apply. The thinking behind this was that it makes no sense for us to turn away people who want to work on the project when we're not paying them anything. So both of the major approaches we've tried have had their downfalls. I wonder maybe if we don't allow people to join the team *until* they do some work, that would take care of the problem. Of course, we'd have to keep them engaged through the forums so that they could figure out what work they could do to join. Hmmm...



Thanks for the feedback/comments/insights so far. Keep them coming!

There's a trick that gets used a fair amount in the paid side of things, particularly in contracting: the "probationary period." During, say, the first eight weeks, a new hire is placed on a small task that should be possible in around six weeks for a decent developer. Give them time to ramp up, and then at the end of the period, see how they've integrated.

The majority of people will fail this test.

It is also important to note that you may fail the test in the candidate's eyes, so think of this as a two-way screen. You get to see if the "new guy" is up to par, and simultaneously your candidate(s) can evaluate whether or not they would like to commit to your project. If you have multiple potential candidates, this can be a great way to issue a tie-breaker.


The trick to pulling off the probation system is to think of the newcomers as non-hires until such time as they complete the period and produce satisfactory work. Since you aren't a paid project this is a lot easier; you don't have to worry about shelling out two months' pay for someone who doesn't work out. If the newcomer fails the probation, oh well, move to the next stack of applicants. If he does well, however, you not only have a trained and integrated team member ready to deploy, you have whatever they accomplished during the warm-up period.

I come from the programming side so this may work far better for coders than, say, artists or composers, but you did mention that programmers were your biggest issue for the moment, so I thought I'd throw it out there [smile]

Quote: Original post by ApochPiQ
There's a trick that gets used a fair amount in the paid side of things, particularly in contracting: the "probationary period." During, say, the first eight weeks, a new hire is placed on a small task that should be possible in around six weeks for a decent developer. Give them time to ramp up, and then at the end of the period, see how they've integrated.

The majority of people will fail this test.

That's quite a contrast between what you think should be possible and what an experienced contractor can reasonably do.

This leads me to believe that your expectations are unreasonably high, and/or that you have serious problems in your initial screening.


I do agree that some will struggle with it, but they are a distinct minority. Yes, I have brought in contractors several times. If your initial screening is reasonable, yet the majority are unable to do 6 week's work in 8 weeks, then obviously something in your system is invalid.

Actually I was just feeling excessively cynical; you are of course correct that people who truly fail such a test are a minority, especially if there's a good screening process up until that point.

I retract my statement [smile]