Can an internet team stick together?

#1 Look around many of these teams are over seas etc. Its requires lots of contact I think.

Also Mods are often over internet teams aren't they?

I think trust is important to the people who are going to work for you.

#2 Trajectory Zone (look at yesterday's snapshot) is all done remotely across the Internet. Has it worked perfectly though? No. Mike Morrison and I broke down and started doing phone calls when time got tight for UI components. A quick phone call accomplished more than 20 emails worth of bouncing ideas back and forth.

I yet to get into a situation that required a face to face meeting (in fact, I've yet to MEET any of my teammates in person!), but there's a great deal of efficenty in bein' able to just walk to the next room and ask questions, have company meetings, whatever.

I've also lost contact with some of the team members, and will have to ditch some content since they no longer reply to email, etc. That doesn't normally happen in real life, but it can online.

#3 I'm not sure if all the members of team behind Think Tanks were working remotely, but at least some job was done this way. Also, look at Orbz team. Actually, I think it was Justin who posted good tips on how to succeed in "remote environment".

#4 21-6 did a presentation on how to be successful at this last year.

Another, similar session is scheduled at this years IGC, with 21-6 and Max Gaming contributing.

In short, it's possible, but not "easy." Constant, clear communication is required. Phone numbers are a good way to achieve that but not the only way.

#5 Remember to get RL info from all members - phone numbers, address etc.

If you suddenly loose contact to one of your key ppl, then everything can fall apart if you only got a nick + email.

"C3 Command" died that way (a larger team of 15 ppl where I was one)

#6 Sign a NDA as fast as possible. They could fool you totally.

#7 Although the majority of BraveTree exists in one place and we mostly work under one roof, we do have team members distributed all over the place.

I have developed an extremely good working realtionship with Pascal Bos (he lives in the Netherlands, BraveTree is in Oregon).

I think the major factors of the success of the arrangement was the fact that both Pascal and I spent a great deal of time learning about each other and becoming aware of our influences and motivations.

As artists, Pascal and I share some of the same likes and dislikes when it comes to art, so it is easier for us to 'hit' a certain look very quickly.

It takes extra work to make remote team members work, but it is worth it.

One bit of advice I would give is to invest your time into the team to help them get what they want out of it. If someone is learning, growing, and enjoying the experience, they are far more likely to stick around and see the project through to completion.

Joe

#8 I live in florida and have very little trouble working with my partner in Australia. I think a good team depends more on the people then the location.

#9 From what I've read in mags like Game Developer, any video game company has a high turnaround with employees. The Indie situation is a bit harder on teams (and their games) because most everyone has the initial energy, but not all have the perceverience to see a project to its end. Top on that it's generally a hobby or royalty-based pay (when game finished & shipped,etc)--well, these factors just don't make things easier. :-)

I, for one, am glad that we stuck with Trajectory Zone and MidnightRyder Technologies.

-EricF

#10 Yes, internet teams can complete a title just as well as any other company out there. It isn't a requirememnt that they all work under one roof, and if that issue was forced, I think you would lose most of your team. Not to mention, your overhead skyrockets.

Our team was scattered throughout Finland, Arizona State and Washington State. Our new team resides in Germany, Virginia State, and Oregon State.

Our main mode of communication is MSN messenger (although any chat client would work), and a common language (usually English, because most of the world already knows English). I still maintain contact with developers from all over the world, including Germany, UK, Australia, Hungary, Russia, Argentina, etc.

I have never met any team members in person, never spoke on the phone, and have seen photos of only a few.

Definately get an NDA, or some other contract out, especially if the payment is strictly royalty based. I wouldn't advise ANYONE to perform any kind of work without a contract of some kind. There are many people who would help you get these kinds of things under way, if you are unsure how the contracts work.

#11 The Legends team has been mostly IRC based. We use IRC extensively for communications. I think a few of the guys have met but we're scattered across the States, United Kingdom, to South Africa.

An important part of an internet based team is the communications, and infrastructure. Our CVS repository is on the net, our changelists are updated from it and available from our website, our bugtracker lives in public, our build machines are triggered from the IRC channel, etc...

The nice thing about IRC for this sort of thing is that you can get everyone together in one place, and still have personal communications if required.

The virtual office is a reality, and doable. The biggest issues are timezone differences, and of course there isn't that "personal" contact, but it's entirely feasible.

I'm not too sure how it would pan out for a project that isn't "Free" as Legends is...

#12 Trust is a major issue, too.
Sad to say, I've seen and been involved in projects that the creator either just gave up on or was flat-out lying to begin with.

Thankfully, not everyone is like this.

-EricF

#13 Its all about production. You should have production rules in your mod/custom team to keep people in it. If someone stops producing or you stop producting you shoudl be moved to retired on the team. If someone has contributed alot then they may get some time but for others it really should require something on a regular basis. Too many teams just meet and chat and build the website, that is it.

#14 Internet teams are great. The distance prevents you from killing team members when you really really want to. Although the distance may be the reason for the problems that are causing you to want to kill them. So it works out well :)

#15 Good posts all together.

Trying to sum up:

* Get NDA and similar documents signed up front
* Get real life contact info
* Create clearly defined communication paths. Doesnt matter what it is, as long as its used frequently and with a purpose
* Have rules about contributions! No contribution = not part of the team
* Make everything available for all members online (documents, cvs, access to development servers)

Did I miss anything?

#16 Good stuff, ol chaps! I can't wait to show ya'll what I have :)

#17 I think I missed the word "design document" in this discussion. I think that, together with the story, this is the most important thing to accomplish. Write it down very detailed, so everybody knows what the intentions of the game are. And then "freeze it". Everything which comes up after that moment, can be written down for a next version of the game.

Also, in an internet project, it is very possible to have culturule differences in the team. Ideas about the amount of violence for example.

Next, since a game is in fact a piece of software, see it as a such. Have a projectleader (the eldest or the one with the most experience) be a teamleader. Not in the sense like "you do the work, I make the money", as we read much to often these days. This is even more important because of the distance-issue, I think. With this comes a planning and such.

Finally, don't try to write the next Doom or HL. Although these are populair games, and logicaly a dream of every game-developer, there are other game-types which also have a large audience. Many people like puzzle games for example. And they are often much easier to accomplish.

Maybe I'm to sceptic, but I don't think I'll ever participate in an internet project myself. My experience in the (regular) software industry is, that communication is just the toughest threshhold. Even when the other persons are in the same room...

#18

Quote:And then "freeze it". Everything which comes up after that moment, can be written down for a next version of the game.

Having worked on eight commercial games that were released (and been involved in the design of several others that never got that far), AND worked outside of the games industry for a few years now, I have to say that this is a great ideal that I have never seen actually work in practice - and in most cases, I'm glad it didn't.

I'm currently working at a company employing the "Extreme Programtming" methodology, which was in some way a response to the fact of life that the original design / specification / requirements ALWAYS change. And in most cases, they should. There's a military expression that "no plan survives contact with the enemy." I think no game design ever survives contact with the development team, testers, or the players.

A design document is a great (and ESSENTIAL) jumping-off point and a method of communication and cooperation. But I've found that you can't really design "fun" on paper. You can try to describe it, and you do a lot to help others catch the same vision. And you can make some good guesses as to what might be fun. But a lot of times, what sounds great on paper just doesn't work all that well when it's finally put on the screen.

In the end, a game design document is less like a blueprint and more like a movie or TV script. It's critical, and you need to evaluate changes carefully lest you succumb to feature creep, but you don't want to blindly treat it as sacred writ and risk producing a game that becomes a black mark on your company's reputation.

#19 I have never ever seen the waterfall model work for any software project. I hear that it works for some niche areas, but in general its doomed from the start.

Having worked 10 years in software industry (mainly as architect and manager), communication is pivotal in my experience, as is constant refinement of the design documents.

I have never tried extreme programming in practice, and I dont know if it works. What I've been successful in is your basic iterative process.

Start 1-2 ppl brainstorming and writing down the foundation of your design/architecture. This is like the constitution - description of main code modules, functionality seen from the customer/player side, technology choices - no details.

Then dig into each module one after one and do a analysis->design->implementation->test cycle, and then start over with the next module. If needed go back to old modules and change them as needed.

Projects in the Internet age _will_ change during the lifetime of creating it.

Just my 5 euro cents worth. (A bit off topic)

#20 Well, we've all basically established that communication is integral to development. It really doesn't matter how this is executed, as long as it is effective. Face-to-face communication is not a requirement, nor is it necessarily more efficient. If smoke signals work, then great.

To give an example, we completed our top-selling and award-winning mobile game within a 4 month window, with a 4 member team (1 coder, 2 artists and 1 audio technician). We were scattered all around the world and communicated strictly through MSN Messenger. Sometimes this required us to work for 24 hours straight, in order to communicate real-time with team members on the opposite side of the world. But that kind of dedication is normal in the software industry (the longest I worked was 36 hours straight)

In contrast, another high-profile company with a multi-million dollar budget created a game within the same amount of time, with about twice as many people and all were in-house. Their sales are dismal, plus they have the overhead of in-house development. In the 2 years since, they have not developed another title.

Also, EVERYONE should know their designated job, and stick to that task, and NOT try to do anyone else' job. That sounds like common sense, but there are numerous "jack-of-all-trades" type people that try to grab control of the project, and step on everyones toes. This should not be tolerated, and I have shit-canned numerous brilliant and talented people, simply because they were hindering the progress of other team members by trying to tell them how to do their job. (these people were the lowest-man-on-the-totem pole, but they felt they could secure a better position by throwing their knowledge around)