As we have an influx of new blood to the various courses I thought I would take the time to offer a bit of advice (as I see it) in terms of setting up a group, being realistic in your goals and what to expect. Most of what I am about to say comes from my personal experiences in this area.
Setting up a team
First and foremost, donít even consider setting up a team until such a time as you have a firm idea as to the kind of games you want to produce. Also, be realistic at this point. There are precious few people around with the skill-set to be able to code the next GTA or WOW. Whilst there is NOTHING wrong with being ambitious you need to temper this with a large dollop of ďreal worldĒ mayonnaise. It takes thousands of man (or lady) hours to produce a game to these standards and whilst we can all debate where they go wrong etc. the reality of the situation is that at this level of development (for us all) we simply arenít ready to produce something of this ilk. By all means designers work on documentation for these games, but donít expect us Developers to be in a position to crack on and get it all coded.
Secondly, you donít need lots of people, quite the opposite in fact. The more people you have, the more difficult it is to maintain team cohesion. If you have 5 designers, 10 developers and 3 artists then things are going to get fractious very quickly and people are going to fall out. Also, give consideration to how you are all going to work together. What collaboration software are you going to use? If you are going to have 10 developers working on a title, then simply ďusing MSN/IRC/random chat clientĒ isnít going to work. Trust me, things will get messy and disorganised and the project will end up on the scrap pile. Have a look around, look at software, decide what will work for you and do it. Whilst there are lots of free bits and pieces out there they are usually pretty poorly supported so expect to spend a little cash at this point if you want to do this properly (but donít go spending £1000ís until you are making money Ė remember, you still have to pay the bills)!
Thirdly, itís crucial that you get to know the people you will be working with. At the end of the day you will be spending a lot of ďvirtualĒ time with them and you will need to ensure that you get on at the very least! I guess at this point its worth saying that you should really vet the work of the people you take on too. Make sure that they are able to work to the standard you expect and will contribute to the cause!
Finally (and arguably the most important) remember, until you are paying someone a wage, no one is the boss. There is a difference between leading and dictating. Itís important that EVERY member of the team has a say in everything that you do. Whilst a leader will ultimately make the decisions itís vitally important that each team member has their say and input. Donít gather a team together because you want to be able to order folk around. They arenít being paid and will disappear (good people are INCREDIBLY hard to find). On the flip side, people will come and go due to personal circumstances. You should wish them well, again, Ill reiterate, you arenít paying a wage, so the only control you have over the team is that you are working on a fantastic project and people WANT to hang around.
Making the Game
I guess the most important thing to decide here is what engine/environment you will be developing in. Most of the people you recruit will be looking to practise their skills in the disciplines they have chosen to learn Ė so again, be realistic. Donít expect a fledgling Developer to want to code entirely in C++ with an engine they have designed, likewise donít expect a ďSection 3Ē developer (sounds like a prisoner LOL) to want to use GM. Look at the resource you have and decide how best to make the game. There are no right or wrong answers at this point, but itís something you should discuss with your team rather than state initially (see leader vs. dictator above).
The most important thing for the team is to get a feel for the game you want to produce, so Id strongly suggest knocking out a very rough prototype (be that in GM or whatever) so the team knows what the game is and what the game does and they can work on fleshing that out. A prototype speaks a thousand words (I think thatís right). Sometimes its hard to understand how a game will operate by just reading a document.
Once you start working on a project there WILL be ups and downs. Whatís crucial is that everyone knows where they stand and what stage the project is at. By all means tweak the game as development progresses but donít get half way through a project, get bored and change the game entirely (common sense, but I know it happens). Good use of collaboration software is crucial in maintaining both morale and a sense of direction.
Keep the public informed as to the progress of the game Ė keep the game in peoples minds, keep interest in the titles you are developing Ė its encouraging for the team and also gives you renewed focus when you start to get positive (and negative) feedback.
My final point on all these topics is addressed to the numerous individuals who read the forums and may feel a bit daunted/pressured. If you are new to the courses then find your feet before looking for a project to work on. There will ALWAYS be groups looking for members and donít feel like you are lagging behind because you arenít working on a game. If you get involved too early in your course then you will likely feel overwhelmed and disillusioned as to the whole process. Take your time and when YOU feel ready, look around. Look at websites, look at past (or current) projects being undertaken and then YOU decide which group you want to be a part of.
Here endeth the lesson
Seriously though, I hope this helps. My inbox is always open for a chat/advise (not that I'm setting myself up as an expert, far from it, but I can offer the benefit of my experiences).