• Advertisement
Sign in to follow this  

online projects and motivation

This topic is 2792 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


About a month or so ago I started a project here which generated reasonable levels of interest. I've found though, that nearly everyone who got in contact pretty much dropped off the face of the earth after the first week. Typically:

- your idea looks cool and I'd like to help
- excellent, [brief discussion of the concept]
- sounds good. alright where to start?
- [gives access to project tracker and code repository]
- ok, i'd like to work on....
- go ahead. any questions? ok compiling?
- [silence]
- hello? how's it going?
- [silence - never heard from again]

I'd like to hear people's advice on putting together a workable team of volunteers - anything I can and should do to make groupwork as painless as possible, and basically vent some frustration.

How do you guys find it?

Share this post

Link to post
Share on other sites
Sad news is that I see nearly 90%+ (my own personal stats, this can truely be all over the place) of non-paid/voulenteer development in games end up like this over and over again until even the very talented and hard working parties are jaded beyond belief (myself included over past projects). And is usually broken down like this:

1. A large number of people under estimate the task(s) at hand and equally over estimate their own or other people skills to suceed or follow through with these tasks.
2. Join a project believing a lot of tangible/end usable work has been done and as soon as they get access to the inner circle feel that every thing was just smoke and mirrors and is nothing more than just sugar coated talk.
3. Want to be part of something but feel that everyone else will teach them or carry them along to greatness.
4. Everyone wants to be the idea guy/gal and getting in on the ground floor everyone pulls in a different direction or trys to inject their own personal goals in everything they actualy do.
5. Feels that they are only here to be the designer and drops the project when they feel the coders or artists (if any) are not doing anything or what they want.
6. Are not aware of the large dead zone periods where there is nothing to show and jump ship feeling it is not moving at their pace.
7. View it as a personal elective that they do not have to do so they feel that any sort of procrastination is fine since any work they do is worth more than what they are getting in return (that is nothing).
8. Like shinny new things and will move on to another project if it looks like it has more people interested or that it will go farther.
9. Everyone is in different locations around the world and have drastically different schedules that do not aline with others so ant any given moment it feels like you are the only one doing any work.
10. Feel that they are indeed doing all the work as everyone else sits back and slave drives them for something they are giving freely of themselves to do.
11. Think different tasks depend on other tasks to be finished before they do their work (ex. "engine" must be finished before artist start creating content, etc.)
12. Honestly do not know where to start for a good foundation and everyone scatters to different parts they believe are more important.
13. Do not like the coding style of everyone else and gives up on "princple".
14. Different levels of experience clash.
15. It was nothing more than an impulse moment and just kind of forget about it because it really did not mean that much to them in the first place.
16. The person who started the project usually is the one who trys to take the leadership role even if their skill set is not fully up to par with managing a larger team and more times than not are not open to taking some one elses lead in return.
17. Do not want to take suggestions from the people with real experience or at least the ones who have tried a particular route and maybe even failed (I see the wheel re-invented over and over with wrong paths retaken just because people do not want to listen to honest advice out of spite).
18. Some people are driven by what you can see and play with and sometimes if it does not get to that point soon enough the non-technical people usually drift away.
19. More people worry about making engines than games or planning for a future of re-usability and expandability that more than likely even with success will not come.
20. Really are not into it more than to have a social group that they can brag about.
21. Spend more time in idle planning and endless research for the "silver bullet" solution that nothing ever happens since they believe they have all the time they want.
22. Feel that no work can be done until they get more people or every "position" seat is filled.
23. Hold out hopping to nab a professional to fix all their problems.
24. Aim too high and never target a project with a subset of tasks that are best suited to the people at hand.
25. People just get dropped in with the basic feeling from others that they should know what they should do and work on right off the bat.
26. They never do any small team building projects to get used to everyone and have early sucesses.
27. Various age ranges and mental/physical maturity that may or may not be shared with others that causes clashes or misunderstandings do to how they talk or express themselves.
28. Ideas really are a dime a dozen and people become so inflexible to changing anything that they sabbotage what can be done for what they beleive should be done to the letter.
29. Everyone is a zealot over something, be it os, compiler, editor, art tools, or coding style and fight over thigns that really do not matter.
30. Just do not speak up and feel nothing is worth fighting over and just leave in silence never to be heard from again.

This list is no where close to being exhaustive and could go on and on but is meant just to give a rough idea of some of the difficulties involved. So yeah, this is basically venting some frustrations I have come across and I am sure you and other have as well. There is no single solution or best pratice is this case since these sorts of groups are all over the spectrum. The only real solid advice is keep all these things in mind and understand what makes people tick and what they think and feel (like from the list above) and work to improve all the points even if it ends up being yourself and or your project itself.

[Edited by - Corman on July 4, 2010 11:50:18 PM]

Share this post

Link to post
Share on other sites
Yeah, a lot of those ring true, especially #7. Ah well.
That said I'm very pleased with what's been achieved so far by the dedicated few.

Share this post

Link to post
Share on other sites
There are always exceptions to everything and behind most projects, even the short lived, are a core of very dedicated people. If this project is relatively new (less than a few months) you will find early on people with come and go like mad and at a relatively regular turn over rate. Even once you get past that you will always keep getting people come and go but you will start to find that you will be able to spot things sooner and smooth things out a little better. The best you can do is all keep working diligently and hopefully equally. You are only going to get better people once you have something to show that makes them feel they are on the same expectations and quality level. When it comes to doing work it also looks to break down like this:

1. There is more ideas about the project than ideas on how to tackle it reasonably
2. Artist that do stay will tend to produce more concept art than usable in-game content until they feel that the engine/technology is up to par to properly show off the quality work they believe they will do for the final product that the end user will actually see.
3. Programmers are usually more interested in the deep workings of the technology and feel it is hasty to deal with the things the desingers think of until they get further (but there are exceptions).
4. Then the split side of this is some of the coders are more interested in the gameplay mechanics and start working on things that are useless since they can not do anything until the rest of the "magic" has been done.
5. Everyone get distractive with "Ooooooo, what if?" things and jump from idea to idea and never work on anything beyond the first shallow proof of concept trial.
6. Endless cycles of trash and redo because no one is ever happy or they believe they see a problem they will come to that really could be easily worked around.
7. The core people always want the best for their project and actually create most of their own stress and barriers.
8. There are many and many little sandbox ideas done in code everwhere but no one ever truely sits down and melds it all together to keep building on.

Sometimes you just got to make a stance and decide to just move forward and make what you have work for you vs. beating yourselves up. Just like muscians not everyone is going to become a rockstar. It takes times and practice and the more you shoot for triple-AAA ideas for projects and work quality the higher your chances you are going to fail. I am not saying aim low but what I am trying to drive is keep working on it. Your first project does not need to be your magnum opus.

Share this post

Link to post
Share on other sites
So I decided to do a little research and check the forums for your poject you have mentioned. I very much like what has been done so far and I hope you keep up the good work. I have rated you up because of this and also for the fact that you have shown the positive effort to improve your project's work efforts by speeking up and asking for advice here. I want to let you know what I have posted here was never directly targeted at you and holds true for many people/projects even myself, other people's projects I have worked on, and my own projects as well.

What I think it boils down to is managing expectations people have or will have relating to every side of your project. This all starts with how you describe, show off, and bump your project to the end users who will want to play it, promote it, or even possibly join your team. And from what I have seen you are doing this pretty good so far. Next is monitoring the people you attract that have voiced their interest in helping you. I know you want people to join, but for the most part, the skill level you need is slightly above a large majority of the people you will run across.

Most of the people that can do what you need already have their own projects or are working with someone else. Because of this you are going to get more people that are a bit green in this field. They will expect you to help them learn or be more forgiving with them. A lot have misconceptions of what goes in to working a project even as yours and believe the tools do most of the work for them. You can't always be picky but do not lead people on and give the the truth of the matter softly and do no lean towards being a dictator.

The biggest expectations to manage are your own. This goes for any project starter, leader, core developer, and so on. You feel you have the greatest invested intrest in every aspect and your drive will be more than likely stronger than any others involved (and as it should be). You may be able to commit nights and weekends but you have to view this as an extreme upper bounds of what anyone else will be able to even add to. You should never expect anyone else to do more than you will be able to do or even match what you are putting in.

Even if people pledge their efforts to you they still have lives and will still more than likely view this as YOUR project. You have to scale everything and look at it equivelently as if you were putting in 80 hour work weeks on this project. So even if someone is barely doing half of what you do they have still put in a great ammount of work. Even if they are only able to put in a few hours on a single day over the weekend they have done way more than can be expected.

Between having to fix dinner, clean up, shower, and relax a bit before my next work day I barely have a hour or so of free time a night during the week. This will still be quite common for a lot of people even if they just only have school. So unless they have a strong drive and feel they are a part of something they can also call their own most of your peek times will be the weekend. But you also have to keep in mind people want their social lives too and have waited all week to go out on a Friday night or do something with friends on the weekends. There are only so many nights were you do not have to worry about staying out too late or having to get up on time for the next day.

You also have to keep in mind the number of other projects that are out there and even how many of them may be farther along, larger groups of people, or even more compelling. So any ammount of activity is better than you many think. What you do have going for you is that you actually have something you can actually show vs. having just a help wanted thread five pages long with nothing but talk and no actual work to show. Most ideas die at this point because the people requesting help to form a team usually are waiting for people to make their dream come true because they are unable to do the work themselves.

All this is just the start and a drop in the bucket but keep up the good work and that chin high!

Share this post

Link to post
Share on other sites
thanks for checking it out :)

The time issue really is the kicker isnt it?
I usually try to get in a solid few hours a night, but the other productive member can really only commit weekends - and I'm perfectly fine with that.

I guess I like to be kept in the loop though - it's very cool to be working with somoene who'll answer your mails, or who'll even actively contribute to the project with new ideas. What gets me though, is the huge number of potentials who just disappear - usually after we've given them access to the source code, and spoken at length about specifics on the project. I'd totally understand a "omg this is horrific!" *runs for the hills* type response :) it's closure at least.

If time's the issue, then managing the project so contributers can get involved with a minimum of effort, get up to speed with the framework, how things are done, and see the status of other members and their tasks - is something I should work at. We're using some good tracking software to manage the project itself, but I'm still doing the introduction, code walkthrough and future vision spiel by email and IM - which is probably why you're reading this rant now. If I can reduce the load on everybody (myself included) in welcoming newcomers and bringing them up to speed....

Alright, there's something to ponder. Thanks

Share this post

Link to post
Share on other sites
Just wanted to pitch in and corroborate what Corman has said. Running a project is hard even when everyone really does want to work on it; throw in the curveball of volunteering and side-project status, and things just get sticky.

In my own experience, it's relatively easy to get a lot of people who express interest in contributing to a project. Back in school I had an RPG project that I wanted to do some voice recording for, so I posted a want ad on the bulletin board and waited a week or two. I had probably a dozen people say they wanted to help, but in the end nobody actually ever did any work. (It was a great way to meet attractive women though [grin])

I think the bottom line really is twofold. First, the average volunteer sees something like a new project, and thinks "oh hey that looks like fun." This is dangerous. Anyone who joins a project looking to have fun is going to be flaky at some point or another, because as soon as it stops being fun and starts being work (i.e. immediately) they're going to lose interest.

The second half of things is the silent disappearance act, which happens far more often than not. Sometimes people just forget, sometimes they move on to other interests, what have you. There are any number of reasons for stopping work. However, from what I've seen, the biggest reason for doing so silently is that people seem to think that somehow that's easier on everyone involved. Sometimes it's done out of a desire to avoid conflict, sometimes a desire to avoid responsibility - but usually it seems that people go quietly because they don't want to deal with any friction.

I wish I had some easy solutions to this, but sadly even adding a paycheck to the equation doesn't always solve the problem. I've worked with far too many people who, even when fairly compensated, decide to just start phoning it in. And all too often, when it's time to quit entirely, they'll do so without much (if any) warning or explanation. There's been a handful of great teammates that I've lost touch with out of the blue, and never known what happened.

The best I can offer is to just stick it out, and when you get someone who does really commit, capitalize on it [smile]

Share this post

Link to post
Share on other sites
Original post by ApochPiQ
However, from what I've seen, the biggest reason for doing so silently is that people seem to think that somehow that's easier on everyone involved. Sometimes it's done out of a desire to avoid conflict, sometimes a desire to avoid responsibility - but usually it seems that people go quietly because they don't want to deal with any friction.

*sigh* unfortunately all this really does is create uncertainty.
I think what I'm learning from this is not to get people involved in the project immediately. spend a few weeks getting to know them otherwise, just chatting about games or the project in general, and then if they turn out to be OK , give them the framework and get going...

For me there's always the temptation to go straight into it , eg.
"Hi, I'd like to help."
"Excellent - a contributor!" [laughs maniacally]
"hey, where'd y'all go?"

Share this post

Link to post
Share on other sites
Also, seeings as groupwork is such a huge part of game dev, and this kind of thing is apparently such a common problem, I'm wondering if gamedev.net should promote some sort of official etiquette to online collaboration?

I'd suggest "Keep your team informed" as being pretty high up there.

Share this post

Link to post
Share on other sites
Original post by Corman
1. A large number of people under estimate the task(s) at hand and equally over estimate their own or other people skills to suceed or follow through with these tasks.

Hi all,
I think this cannot be stressed enough. A lot of people joining a new project are willing to invest some time, but most want to see results rather quickly. If your project is in a very early stage, or a fairly mature state with a lot of code, this is not likely to happen. Joining a new project with an existing code base means working into a lot of code, this often seems like a big hurdle for especially fairly novice programmers to take.
It's the expectation of "I'm joining this new project and i'm going to change the world by doing it" which makes a lot of people leave quickly, when they see it's not going to happen.
In my experience it's therefore important to lower the expectations the people have when joining a project. When you first talk to them make clear to them that it will be a lot of work (read hours/days) to contribute to your project. This is a risk, as it might scare people away, but the people who really want to contribute usually know this anyway and they will be ok with you telling them. Most of the people still underestimate the work they have to do, even if you tell them it's going to be a lot, so don't worry to much about scaring them away.

Here are some counter measures that can help (again, in my experience):
- Make clear to new people that working on a project takes a lot of time and is not always fun but even work sometimes
- Make them contribute their first 3 fixes through patches before you give them repository access (It won't bother them and it will help you keep the repo clear of unnecessary users)
- Comment your code (yes it's that simple)
- Have a bug tracker so people can find themselves tasks easily (and most importantly, without relying on your help. Working autonomously feels great!)
- Let the new contributer choose on what he wants to work
- We have an in-code tutorial which takes you through the important classes. It's basically comments inside the code explaining what each portion of code does on a fairly high level and then says "To continue your journey, now check out xyz.file". It's a little adventure through the code if you will. A lot of new folks have found it quite helpful.
- Make sure you thank the contributer for his contributions! In open source world this is all they are going to get! So if someone supplies a patch, thank him for it. If he continually contributes, add him to the credits. I know this hard for us computer folks, but saying "Thank you!" really is a great motivation.
- Make them feel part of a team. Always talk in terms of "we are releasing a new version where we implemente a, b and c." "We have to tackle this new problem", etc.
- Create an IRC channel where you meet up with people regularly(this can be hard if you live in different time zones) and require regular contributers to join when they work on the game or even better always when they are online. Again this is a team building experience to everyone and you get to know each other fairly well. This will also help new people as if experienced contributers are online as often as possible, rather simple questions can be answered quickly instead of taking the new guy ages to figure out.

Obviously these are no all healing ways but they will certainly help in keeping contributers. And don't get me wrong, this might lower the bar form 95% of new people running away to 90%, it won't lower it to 20%. But it's a start.

I also agree very much with Corman on the other points he makes as well.

So all in all you really have to hang in there and with time you will get longterm contributers to the project if you let them join the project and let them take responsibilities etc.

I hope this was of any help.

Share this post

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

  • Advertisement