I will gladly share my previous experiences in game making. Most is about how to fail, fast, but that is important knowledge too. Most of you might already know a lot about this but some tend to plunge themselves into the euphoria. Here's my bag of cents,
First; Write down a short description that defines the game you are making. A common goal that says 'this is what were doing' to look at in hard times. It should be just a few lines in length, but really fire you up when you read it. Why is this game fun/rewarding? What kind of control over the game does the player have? Stuff like that. This is important so that you all understand what it is you're about to do. Keep it short. A page is too much. People tend to spend a few weeks at projects like this before they transfer to more prioritized things. But if 100 people spent 4 weeks each this could get pretty far
Of course, the goal description is essential in this case.
Secondly; Keep it open source and very available so that anyone can pick up when you get tired or just simply can't continue. I suggest setting up a CVS before the actual coding begins. And keep your documentation freely available. Why keep something you share with a 10000+ community secret? This way people like Sander can go in and criticize on stuff you did wrong.
Plan ahead. Know what needs to be done. Scetch out how the engine should work/works on a piece of paper. Class diagrams, rule set, anything that's complicated, so that you know how it works before you realise you have to redo core elements of the engine, again. Example: If you choose Ogre 3D, start scetching out the story or gameplay first, instead of thinking about the engine restrictions. It is very flexible and has a huge, hard working community. When you know how the user interaction should be handled and what type of perspective you want etc. Write it down in your design document, and then find the right parts for your engine. (Ogre 3D is NOT a game engine. It is a rendering engine, but with a lot of extensions making it exceptionally fitting for game production. Thanks to a dedicated community)
When you have decided on
what type of content you need in the game you can start working out the engine. Even if you don't really have any content yet, you can make room for it, using replaceables. As long as you don't "hard code" anything (which is bad anyway) and keep it flexible you should be fine. Put someone at coding at this point, because otherwise you will have to wait for that guy to catch up with you.
Small tasks! Divide the tasks into SMALL portions, and maybe announce a new thread for it in your forum, so that anyone with talent can grab it and complete it. And having a thread for it would let us all judge the results. A small task could be 'create that asset' or an open call for concept art for specific things, or several. The core team should announce tasks like these when they really need them to be done, or you'll get an overwhelming load of data to sort out = Extra workload.
Deadlines! And people who follows them. Set a date on anything that can have a date. (It is not the end of the world if you miss a deadline when there's no money involved, but if people starts bending the dates, others will loose interest.)
Team building!
I know it might sound silly, but you must be able to reject a proposal, and know that the person doesn't take it personal. More honesty, or the game will fail. And, constructive criticism people!
Forget about making money. It will destroy you. People must be willing to do this for free, and for fun. Keep it simple. People may want to donate money, but give it a hard though before you let them. Who is going to manage those fundings? Can we trust him with that job? Can you trust yourself? Getting money to do something really becomes something of an obligation to finish it.
Also, I recommend reading up on game design. It is always good to know what you are up against. And make sure to read the Van Buren design documents. Awesome stuff.
Anyway, good luck!
