next »

[Mr Dumle]

Does anyone have experience working in teams doing a hobby game project?
I like to know what works and what doesn't. For example, should one enforce strict deadlines or have a more easy going philosophy?
Share your experiences!   

[ANtY]

Never go with "strict deadlines", even don't do any sprints, etc. Just make todo list with things do do before next milestone with separated tasks for every team member.
Sometimes ask them if they did something new, don't get mad when they'r not doing anything for 2 weeks, its normal

[ink.inc]

Make sure that your duties are split and clearly defined. Also, have a to-do list. On top of that, make sure you TALK to each other. Communication is extremely important. If something sucks, do NOT be afraid to tell the other person. Try to make sure as much as possible that you guys are on the same page.

One more thing: spend a decent amount of time prototyping.

[BoxedLunch]

i've been doing the art for a game for a while, but do to both of us not being able to stick to a game very well, or for long, we kind of phase in and out of work on it. so far it's working well. you feel less stressed.

[eclectocrat]

First you get electric dog collars, lot's of chloroform and a dilapidated factory in a rough part of town. Next you need some ambitious high school girls willing to trump up rape allegations, a dirty cop or two, a senator ...  oh wait, I'm thinking of EA, never mind.

Seriously, a game requires X amount of work. That X is pretty constant (our ability to estimate X is another issue). You need to divide that X into tasks and subtasks. Alternatively you can go bottom up, and start assembling little X's into bigger ones. Then you gotta work!

Teams are made of people. So managing teams is actually a very human affair. In fact there is a specific job title for managing teams... um, it eludes me now... Dilbert aside, there are such things as good managers. Respect your teammates, maintain motivation and be nice to each other (this doesn't preclude being assertive). If you make someone unhappy, they will become a bad teammate.

A more concrete suggestion is to carefully choose realistic and suitably challenging milestones. Milestones which you can execute and see on screen are really motivating.

[Jay Margalus]

My advice for you is a bit less esoteric: Use version control.  Either SVN or, depending on the project, Git.  If you've got multiple hands dipping into a projet, you should always know what's being changed, and by whom.  Less headaches for you in the longrun... trust me.

Other than that, depending on how hobby-ish you want to keep it, I'd use a project management system like Basecamp so everyone knows what they're supposed to do, and when they're supposed to do it by.  It's also great for sharing ideas, documents, etc.

[Chris Whitman]

I've never had success working in teams. However, I think a big failure was always in terms of who "owned" the project. I came to realize after many, many occurrences of having people back out that, when the project isn't actually generating revenue, the best way to keep people interested (and the fairest way to work, honestly) is to make sure that creative work and input is spread around really well. The moment you turn into an auteur just getting other people to produce resources for you to use for your vision is the moment everyone else loses all motivation to participate. Make sure the project feels like everyone's and not just your own.

[ink.inc]

The moment you turn into an auteur just getting other people to produce resources for you to use for your vision is the moment everyone else loses all motivation to participate. Make sure the project feels like everyone's and not just your own.

[AndrewFM]

Also, if it's a hobbyist project, expect its priority level to be fairly low. If people on your team put their project tasks on hold for other important things in their life, you should be perfectly okay with that. That's the correct and responsible thing to do. It's a fun side-project, not a job.

Expecting someone on your team to hold the project as top priority in their life will stress them out, and make them jump ship very quickly.

[Daid]

Talk, talk, talk and talk more. Communication is very important, be clear about what you want and don't want. Be honest if you don't know something. Know what your own strengths and weaknesses are, if you know shit about code then don't think for the code guy, let him do the thinking. Tell him what you want and he will come with suggestions that make it easier to implement for him. Being in (about) the same timezone really helps here. Communicating across oceans is a lot harder.

Start small, don't try to make something huge from the start. Let it grow. Keep your start plan simple, if you want to make a megaman/kirby/metalgear/mario crossover, in 3D. You'll need lots and lots of stuff, complicated code, lots of graphics and many sound effects. If you just start out with a  megaman like platformer the chances of getting anywhere are a lot higher.

Don't 'collect' a team and then start working. Just start working, see it more as your project with people helping then 'our' project. Also, if you can have something playable at all times it really helps, this keeps people motivated. Which brings me to another important port, asset management. Be sure to share new stuff as fast as possible, if the arts guy made a new sprite or something, and the code guy integrated it into the game the same day it really boosts morale.

I'm currently in 1 team project, where we use dropbox.com as asset management. Which is really great, as soon as I fix some code it's synchronized with the other guy and he can test it. As soon as need graphics are put in there I get a notification and can start to use them. This keeps our development cycles very short and fast. But if your team contains more then 1 programmer this might not work.

And last, if people don't have the time, then they don't have the time. Don't bitch them about it, just keep moving yourself.

[dantheman363]

Make sure everyone is on the same page and has the same goals.

[Fun Infused Games]

I'm gonna echo the communication thing as well. And don't just communicate, document (informally is fine) what the results of those communications are. It is so easy to forget or dismiss ideas and hard to revisit them later if they are mixed in with old emails or came about in general conversations. I started using a private forum for my recent collaborations and it works pretty nicely, each thread is a self contained topic which makes it easy to go back and learn about any design or technical choices.

[tsameti]

A thousand times, this.

Find common ground. Be willing to make concessions. Make your collaboration a social dialogue and not just a work circle. Recognize your limitations and the capabilities of your teammates.

If your group is small, you need one group facilitator. This person is not a lead designer, it's simply their job to keep meetings on topic, brisk, and productive. They ask team members to set their own goals, and they may help coordinate when game features get integrated. If someone else appears to be taking this role, take a back seat and encourage them to live up to that responsibility effectively.

Schedule regular meetings and stick to them consistently but not fanatically. Your major objective each meeting is to set realistic goals, and then to meet them. It's more important to set a less aggressive benchmark and meet it than to set one twice as ambitious and only make it halfway there. Why? Because now you have a long string of successes, instead of a long string of failures.

You've got to work with people that you can humanize, that is to say: face to face or voice conversation. No exceptions. As we are social animals, your partner must see a human being behind your forum tag, otherwise they will drop out on the slightest notice.  Invest in a webcam or microphone and use Skype if you can't meet over dinner or over drinks.

Be aware of the age and career status of your partners. If they have young children, they're busy as hell. If they're students, make sure they belong to an established student organization first. If they're unemployed, they'd damn well better have a plan other than the success of your game.

Never insult or alienate a teammate. If they are underperforming, allow them to find their own place in a task of lower responsibility. It's possible for people to get their act together, or even contribute something amazing down the line. If they leave the project on friendly terms, they may re-skill down the line and contribute to a future project. I've worked with a few students who started off admittedly dead weight, but they honestly wanted to get better and they DID.

Hm... I think that's most of the things I've learned...

[HyperNexus]

Make sure that they are as intrinsically motivated as you are. If not then you'll end up doing more work than the other members in the group which can cause resentment.

Definitely keep the atmosphere easy going. It's a hobbyist project and so it's a good idea to form an environment in which everyone is comfortable so they can be productive. Nobody needs extra stress on top of what they are doing outside the project.

Choosing to have deadlines is something that should be chosen by the group. Sometimes people like deadlines because it means that they have something to work towards. Yet at the same time people can produce rushed and less creative work. As long as the deadline isn't used as extrinsic motivation then its okay.

My best piece of advice is to just find people that you enjoy working with. Once you've done that then everything else falls out.

[broadcastbrian2]

When your team mates are speaking let them finish there idea. Don't interrupt them or speak over them. Speaking over your team mates will make everyone angry and some may even leave.

[Konidias]

If it's in person, you may finish a game. If it's over the internet... well... let's just say I've yet to finish a game working with people over the internet.

The biggest problem is that people feel little to no guilt for abandoning a project or not pulling their weight when it's over the internet... There isn't enough of a reason for them to stick around. Everything starts out well but the moment things get hard or actual non-fun work is required, people just flake out. I've had it happen time and time again.

[.]

This thread is really interesting btw. :3

I have another question. What if the person you are working with is really commited to the project, and is excited doing the programming for it, however, they don't put out any suggestions or ideas. It's like they are only waiting for orders.

My view on working in a small game dev team is that there's really no director or any of those titles that would exist in a commercial game studio, where people are actually more important than others and those at the bottom have no say.

I mean, I don't want to be the person that is only giving orders. I want everyone to give their ideas so they too can be more passionate about the project. I always ask question like "What do you think about this?" or "How do you think we should do it?", to which I get nothing.

Anyone been in this situation?

[ANtY]

My biggest dream is to work with a small team of really enthusiastic and motivated people. People who do what they do because they have a passion for it. I'd love to just be a part of that. I don't wanna be the lone guy who runs everything. I'd wish someone would tell *me* what to do and what they need, instead.

+10000 

@Greiv: it's rather like most of ppl aren't excited and aren't suggesting any ideas

[tsameti]

I mean, I don't want to be the person that is only giving orders. I want everyone to give their ideas so they too can be more passionate about the project. I always ask question like "What do you think about this?" or "How do you think we should do it?", to which I get nothing.

Yea, I've seen this a lot. Sometimes it's just that this teammate doesn't like being put on the spot. Let them take a role which is a little less creatively vigorous and a little more hands on. Sometimes they come up with really cool ideas only when they're working, sometimes they just don't feel very creative in general.

Sometimes those people are extremely hard workers, and they're invaluable in actualizing the ideas the rest of the team has. As long as you keep your ears open, and them involved in the conversation, eventually they'll chime in with their perspective, even if it's technical.

If they really and truly have nothing to contribute... they'll fall out of the project on their own. It just happens. It's tough.

[baconman]

Honestly, we could probably do that here, it's just a matter of placing the forums in an order that works more smoothly.

1. Design <-collaboration would come here, in this phase.
2. Writing
3. Programming/Implementation (IE: Technical)
4. Art, Music and Sound
5. Feedback
6/1. Business (where applicable)
6/2. Announcments (IE: we're done!)
__________

The main issue is that it takes patience. Everybody works on their own time, so you can't really rush anything, in any step. This means you may end up waiting longer than you'd like for something. We ALL want finished projects, both to complete and to play from one another - but it only comes in time.

The design phase is all about defining core gameplay. The writing phase is about putting personality and plot into it (even if you think it's extraneous, other people may/do not). Programming and implementation (IE: level design) is done after that, to ensure that the needs of both are (mostly) met in the project's outline. Art, Music, and Sound should probably come in both "placeholder" and "polished" forms, but should be made fitting to the story/action; which can only work after that's been decided on; and while it *can* be coproduced with the programming/implementation, the fact is that it's usually far easier to modify artwork to fit a programming scheme than it is to modify programming to fit an art scheme.

Feedback and touch-ups are applied, good things are added, bad things are revised or scrapped, then the business end where applicable takes it's role, and then finally, you get a finished, polished product.

Then it comes down to a willingness to help others in their visions as well (I love doing this, btw; which is why it's sometimes hard to avoid playtesting/feedback for me), and then allow the patience for everybody to do their part; because not many of us are in a boat of financial independence and free to neglect other things in life; and we all work in inspired spurts. For instance, I'm participating in the forums here quite a bit right now, and working, and getting ready to move. Therefore, I'm not getting a lot of work for my projects done right now.

Once I get moved and set up, though? I'll probably spend a few weeks away from here, and work on wrapping up a couple of things I've been bobbling in and out of for the past year; like "The Zmix Project," and making more headway on... well, there's probably about 10 things I'd like to mash out, and it's hard to pin down any single one I'd like to focus on, because what I make for one kind of ties into the other stuff, too!

^.^ I get the feeling I'm gonna be busy/active here for a long, long time.