I have not worked on a game collaboration, but I have worked on other collaborative projects (comics, anime fansub, etc.) online. The success is, of course, determined by the least productive member. If you have a member who simply will not do their job, you can't finish your project. Because your main method of communication is the internet, someone can suddenly "disappear" and you'll have no idea if they're coming back or not.

Even though I know your question was for the future, here are some things I suggest:

* Set up a forum for your collaboration.

* Get MANY contact info from the members. Have them give you a phone number and have everyone involved trust giving out their phone number. People are more likely to at least respond if they're going to bail if you have their phone number.

* Don't collaborate with someone you wouldn't trust giving your own phone number to. Collaborations require trustworthy people anyway.

* If you're leading the project, give report deadlines... like everyone MUST report their progress twice a week (on specific days, by specific times).

* If you use messengers regularly, try to get everyone to actively keep their messengers on and talk to each other casually. Always ask how the project is coming along and talk about your personal progress. People will work harder if they feel everyone else is working hard, plus they will not want to say "I have done nothing" every time.

In the end, I think it's best to collaborate with people you know, rather than strangers, but it's very possible to collaborate with strangers and complete big projects. Think of anime fansub groups who have oftentimes a separate person do each of these things:

* Rip or find "raw" episodes.

* Typesetting

* Translation

* Quality Checking (usually several people do this)

* Video editing, etc.

* Publishing/distributing/webhosting/whatever

Usually this kind of collaboration would have at least 5-6 people working on it (though some groups "combine" talents and only have a couple people, but still) and they can do like... 200 episodes of some long series and complete their project :) So it is very possible.

One very specific example of group failure is Hero6. They were around for many years but they never finished their game, despite people's best intentions. They accepted members from all over the place and they all lost interest over time.

One very successful example is Black Mesa. They were around for many years, but through shrewd management and perseverance managed to finally release their game after over six years (seven?) of development. I didn't personally enjoy the result because it wasn't 'Valve quality', it was still a very impressive accomplishment.

Here is a interview with the person who became the manager of the project, and the problems and some solutions they came up with.

Maybe "easy" was the wrong word... I just wanted to know if it had been done successfully before and any pitfalls that go along with it. Thanks

It's really no different than collaborating with people who are sitting right besides you. It's a people thing, not a technology thing. Anything like DropBox, or some kind of source control will solve the technical aspect.

I've done this three times.

I joined an FPS project here on the forums as a mapper. It was a disaster, because no one on the team knew anything. I couldn't get simple answers for overall scale, player sizes, heights, and other misc data, so I couldn't map anything for them. Everyone had a different idea of what they were doing. That was about a decade ago now, and I'm sure they still haven't done anything.

I joined a modding project for NWN and it was more of the same. One guy making decisions that had no clue what the engine was even capable of. Another guy liked to script, but solved every problem by writing long, error prone, overly complex algorithms. So I ditched them all, took the one guy on the team worth a damn, and we started our own.

This project worked well. I did the scripting and some of the content, the other guy did most of the content, and guy number 3 had the server. We were always on MSN messenger and communicated constantly. I had txt files that detailed exactly how all my modded code worked, and how the content needed to be created to work with it. The only setbacks we had were patches that changed functionality, and me having to redesign around it.

So you need someone in charge who knows what they are doing. You need everyone on the team to be good at whatever is it they will be doing, and self motivated. Everyone needs to have all the information on how everything will work and fit together. Everyone needs to know exactly what they are responsible for, and what is expected of them.

i'm curious do you mean this more in a software sense or a manpower sense / as far as establishing a repository somewhere and giving access to several individuals to work on the project that is extremely easy and as long as you have around $100 somewhere you should be able to establish a cheap and accessible setup to all your team members. As far as completing a project , making sure it's done on time, ensuring that everyone is on the right page and maintains the same version as often as possible ? well that's an entirely different story and based on the experience, communication skills, and team dynamics of your team . It is a very vague question and yes it is possible ( I work in calfornia with a programmer in argentina daily). However viewing a few other responses it seems like maybe you are putting the carriage before the horse a little . If you don't have the resources or ability to make a game yet then trying to plan out how to establish an extensive network for yourself and multiple developers to work on a game is pleasant info sure but considering how complicated something can get and how quickly it can get complicated i would make sure that you had a solid foundation on how to develop games by yourself .

Something that helps is the way you run your project. I recommend using Agile, trying to get a vertical slice done every two weeks. This means that instead of writing out the whole database, you only write out two of the tables. Instead of writing out a large scale player management architecture, you outline what it should be, and only do the minimal you need to get the game to show a player on the screen.

Here is a major benefit of how it helps with a freelance team:

1) if no one sees any changes (I.e. your programmers are working on the perfect database layout for 2 months) no one really knows anything is happening.

- Players don't care how awesome your architecture is, or how ingenious your database layout is. They don't see it. And half the time you spend more than a month working on an architecture for other things to use, your going to want to change it in some significant way before the game is done.

2) When the changes are visible, playable and often, your team members will be more excited about the small details. This helps keep up excitement.

3) When you try a small section, you can decide if it is working or not. perhaps you need to change your approach, perhaps it needs addtions later, but you've figured that out in a two week period, instead of having it jumbled in a mess of 20 things over a 6 months period.

I've run numerous failed projects, and a couple successful. The successful ones all approached things on getting playable content however small or useless, immediately.

I've done collaborations on different kinds of things. One game, two books, a few songs, and one video. The songs and video were in person. The game and book were online.

I'll just talk about the game. It was about a month and a half ago. I put up a post on gamedev, weeded through the Final Fantasy + Mass Effect + Monkey Island game of the year contenders, and found an artist with seemingly modest ambitions and quite a bit of talent.

To give you the highlights: We picked up another programmer, and he was going to code up the game in Java while I did minor scripting in Lua. I did the story and helped with the art. The artist didn't even know what he wanted the game to be like himself. This is cancer for any project. He kept throwing out these insane ideas that were way too ambitious or didn't make any sense. The programmer wanted to build everything from scratch. His own Lua parser, his own XML parser, his own level editor. Despite my constant reminder that building everything from scratch is retarded and hypocritical (why build the parser from scratch? Why not write your own markup language from scratch, too? We're too cool for XML). Those two forces were tough to contend with, and I failed as a leader on the project as it quickly broke apart.

As a result of that and other non-game online collaborations, I think if you're going to work with people online, start miniscule, not small. Just show your individual work together, pass around e-mails or IM's about stuff you think is cool. Become friends. When you do work on something, make it super-duper small. I'm talking something you could probably do on your own. You need to know how well you work with each other, but also get something done for all the time you put in. From now on, my first project with any online group will be tiny like that. I don't want to jump in the deep end with people that I'm not sure can swim.

From personal experience, whenever I've joined a team from the classified section, it all starts out really well. Everyone is ambitious and want to create a good game.

Firstly, where it's failed for me is when the other members are from vastly different time zones. It means that you have to either wake up early to get some decision work done or stay up late. Sure, programming wise it's very easy to do because all you need is a list of things needing to be added to the game and you add it whilst everyone else is offline but, by the time you've gotten a basic concept written down, all the ambition is gone from the frustration of not being able to communicate properly.

Secondly, I find that organization in the project is always lacking unless there is someone leading the project. When it comes to team decisions it sometimes goes out of hand and people tend to disagree with other peoples ideas which can aggravate people. When it comes to deciding what to develop, if the team is comprised of non-programmers or nooby starting out programmers, people decide on the higher level of development instead of thinking of the development in a detailed way. For instance, someone in the team who is a ignorant nooby programmer or an ambitious game developer (etc) thinks: Concept(demo game), kickstarter, game, steam. This is wrong because it leaves lots of the development to be made up as it goes along. What a team should be doing is split each part into modules.

So for concept one of the modules would be engine which would have separate modules in itself, graphics, physics, world, etc.

Anyway, I'm sure collaborations work but this is just from my experience in the past.

This discussion is very out-of-place compared to the other discussions in For Beginners, but very frequently discussed in Business/Law and in Production/Management. So I'm moving it. But I'll leave a pointer in FB.