Here's the first docs of the "How To Start" section. Go and rip them apart ;) index.html and website.html are the versions from the old site with just minor changes. general.html is completely new. -- Drive A: not responding...Formatting C: insteadTitle: How To Start
This section gives help on starting a new project, including:
A decent website is a must-have: it allows you to inform the (potential) users of your project about your goals, new releases and practically any news item related to the project. Also, it allows direct feedback from the users.
Your website needs to be hosted somewhere. Not everyone has their own domain or even web account. We recommend a two-step approach:
In general you should always prefer one of these big hosting organizations over your own computer at home, as they have a fast internet access, much disk space, professional system administrators, are very reliable and make backups on a regular basis.
Go for simply, classic, readable and not for high-tech state of the art. First of all, you want to put most of your efforts in developing a game, and not in creating a superb website representing a vaporware project.
A few items your website cannot do without (in random order, some apply to open source projects only):
And always remember: A website needs to be maintained, the information on it (most notably the status information and news list) has to be up-to-date. If people see a website that hasn't changed in months they usually take it as a sign that the project underneath has died.
Title: Generic Project Management TipsThis is a loose collection of Pieces of Wisdom that don't fit in any of the other categories. The list is completely unsorted.
If you have some tips you want to share with other developers, please mail us. If you in contrast look for more tips, the Debian project has an excellent Collection of those.
Do not say things like "We'll have this and that great feature, our stuff will be much better that everyone else's" etc too early. You won't be able to keep all these promises.
Keep copies of your data (website, code, images etc) at multiple places. Every core developer should have a complete copy of all data on his very own computer - and update it regularly. If your graphics designer works for months to create hundreds of beautiful images, but has his connection cut off shortly before he can give them to you - then you're back where you started. With nothing.
And don't be fooled - such things happen more often than you think. This project, the Linux Game Development Center was set back for many months because key people disappeared, had email problems they didn't notice for some time etcetc. I can remember at least five such cases.
If someone comes up with a cool idea - even if it's completely unrelated to your current work-, if you decide something or if someone starts planning on some issue: Write it down!!
Have some "List of cool ideas" where you collect those things or else they will get lost for sure. Even if your mailing list is archived. Ever tried to find something in those 800 mails of the past month?
Most projects start with the "Why rules? We're all friends, we will just discuss the minor conflicts coming up - and most of the time we'll agree on everything anyway." attitude. This is perfectly ok at the beginning, but as both your developer group and the code/data/goal complexity grow, you will run into trouble with this approach. Not because all of a sudden everyone disagrees on everything, but because there is no written set of specifications to adhere to.
Coding standards are important to ensure that everyone in your group can read and understand (and thus modify) every piece of code.
Documentation standards make sure that visitors and later users get a good, comprehensive and homogenous (and thus useful) set of docs.
There have to be people officially in charge of the different parts of your project. Both because you won't make good progress if everyone tries to do a bit of everything and because outsiders have to know whom to ask their special questions.
If you have your plans, design documents etc on the website for everyone to read, have a public mailing list where averyone can join and have your code open at a public place, so that everyone can have a look at it, then you will be criticized. People will find weak spots in your designs, bad and inefficient code, problems with your project organization etc. You will get mails ranging from nicely written advice to rude flames.
Be glad about that. Ok, delete the flames, but be thankful for everything else. I know, if you don't have experience with open projects it will take some time to get used to that. But it's worth it. This criticism is perhaps the best thing that can happen to you. The more you get, the better.
First, it helps you to make things better. If you started writing a game you sure want it to become as good as possible, and the criticism is helping you by finding weak spots, collecting advice and bringing in fresh ideas. And second, it shows that people actually care about your project, that they are interested in it. Nobody spends much time writing long mails about things he doesn't care about.