I am using Visual Studio 2005 as my development environment and C# as my primary development language, on a Windows XP Pro with IIS 5.1, .Net Framework 2.0 and WinFX SDK Jan CTP installed.
I start off with a mind map of the game features, using the tool: Free Mind. The mind map should be sufficient enough to serve as an overview of the game components.
Next (which is the current stage), I would outline the application components/architect/flow. This would again, be a high level outline. A short description of each component would be written as well.
A simple schedule, or roadmap would be then produced. This will be a form of progress indication for the project.
The follow up process would probably be slow and iterative. I would pick a particular component, do a more detail design (in terms of gameplay, application flow, communication, etc). After implementation, I would follow up with a journal entry, and the process would repeat until the game application is complete.
Depending on cases, I would employ unit tests/test-driven development on the component. The choice of unit testing tool would most likely be NUnit.
Subversion repository would be set up locally (though ideally it should be remote), and check-in performed after each milestone of the component schedule (be it minor or major). At the very least I would have a roll back capability of source code if required.
And finally, on the code documentation aspect. With C#, the most logical choice would be the xml commenting feature it supported. I could either externalize the comments of have it within the source.
On the issue of externalizing the comments, I might stress that it is NOT a good idea. First, having comments in another file can easily cause inconsistencies. The comment might, at a later date, no longer reflect what the method/field/class do. This is mostly due to neglience, and is pretty common if the comments are just not at the place where you change the code.
The xml commenting feature, however good it may sound, might prove excessive in cases. Unless you do wish to generate a help documentation out from code, they are not necessary. In my case, I do not intend to generate the help documentation (or at least not one that is as comphresive), so having the xml comment reiterating what the method does even though the method name is clearly explainatory is... excessive. As such, comments would only be used in places to furthur describe the internal workings of a method (though in such a case, one should always consider renaming the method to be more self-explainatory, or if it gets too long, consider refactoring it into multiple smaller methods).
Taking a step furthur, I create addition attributes to furthur help in the commenting. NotNull, ValidString are examples of attributes I can apply on parameters (ideally it would be good if they can be enforced as invariants, but I believe I need to use Spec# for that feature). Additionally, Document, Summary, and ToDo can be applied on classes, methods, events, etc. In this way, the comment are 'embedded' into the code, and even read when the final product is reflectored. Of course, I have to agree that these could be excessive baggage to carry around...
I hope I can get around to posting the application outline in my next post.
