You have to be eficient. If you can’t do this quickly and easly then you rpobably don’t know very well what you are doing. I sugest you put your team talking together and creating a good UML documentation. Most of the time this is also the leaders fault because they are never satisfied with one solution and nobody can understand what is going on in their minds. That and leaders also have to be coerent with what they say. That is don’t ask for something absurd that will then force you to backtrack and throw work away. When we are dealing with open-source free projects we must be even more cautious because people don’t have a contract binding them to a project.
I have a good example that is www.startflightcentral.com. This project has more than 8 years now and is still alive. It’s just than nobody has yet been able to do more than 50% of the game. Lately we have spent almost half a year documenting the damn thing and making the project more friendly to contributers.
This is sort of the track record of the project. In 2004 the main coder who has build the first functional demo with modern graphics stoped posting in the forums and was never seen again. ;D
Before that there has been several engine shifts from DOS to win32 and later to Allegro. The organization was allways the same. One coder dude with all the code in his head and other people trying desperatly to read his mind. There is a lot of great contributions that are store in our databases, from art, music, writings, etc
When I joined the project in 2005 together with other coders we realized that most important than continuing that mess of more than 1000 c++ source files without any documentation was to ensure that future contributers would have an easiy time geting in the project and knowing what is suposed to be done or knowing right away they don’t have the skill/experience to do it.
So we decided to build a doc section in the svn depot and document everything to the minimum details we could get. We also tried to change the engine and game data to be data driven and independent. Game data formats are the most common possible: obj models, xml files, pnjs and jpg images, ogg and midi musics, wav sounds. On the engine side we are planning to implement all the game behavior using a scripting language that can be easly modable. When we want to test combat algorithms for example we firts create a prototype and only when we are sure about the algorithms and interfaces to use we code it into the engine.
At the moment we haven’t been doing much more than documentation, prototyping and game data conversions. But there is already a big difference. We are getting more experienced code contributers and they stay for long and actualy contribute with something being design docs or proto code instead of being completely in the dark and having to browse trough a wall of code to be able to just figure out what they are doing in there.
And since the engine is planned to be completely independent of the game we now can acept propositions for different kinds of engines. We have one persons interesting in doing an Allegro c++ variant that runs on linux and im doing a combat prototype in jogl. We could have a full jogl engine if someone would be interested in doing, since the game is data-driven and engine independent this would not be a problem.
This is one good thing about open-source or free projects is that we can’t be relaxed with docs and planning because we aren’t paying anyone and if someone just finds it frustrating he just leaves.