Here you'll find some advices based on my experience as an indie developer. These are just advices, and not a manifesto on how to work, but it will hopefully help you develop your projects.
Table of contents[Show/Hide]
Planning is a quite important part for every project. You must make decissions based on this planning, and not letting chaos control your development. The idea is to look at this as a code formatting guide, but covering the whole development aspects.
One of the important parts is the whole project planning. This document should have the following sections:
- Introduction and goals: Here you describe your project's purpose, what it does, what it's for... It's important as you will need a reminder of what you're trying to do. It's quite easy to lose focus on the main goal as the time goes by.
- Requirements: Things like acceptable performance, supported platforms... go here.
- Estimation: This part is not very important here, as most of you will lack of experience in this field, so telling how much time something will take is too much tentative at first. I would suggest to re-estimate as the development advances. <u>However</u>, here you can write down the estimation method for the future tasks based on the previous history.
- Risk analysis: What to do in case something happens (and what indicators you'll see before it happens)
- Development process: If you're going to use a certain methodology, how long iterations will be, when to do regression tests...
- Technology: Tools and libs you'll use, why you'll use them and not other ones, and what benefits you take from them.
- SCM and backup plan: The software configuration management (CVS in this case) and backup policies. How often to upload to the CVS repository...
- Quality plan: Maybe the most fun part of the document. You tell your naming standards, code formatting standards, file structure... In my case, the elements I have here are: Requisites, tasks and issues naming standard; Version naming standard; Coding standard (C++ with "warn all" and "warnings as errors", for instance); Code formatting standard; Code commenting standard; File system structure; Testing (unit, regression and acceptance). Existing Ogre standardshttp://temas.obelisk.net/ogre/CR/docs/howto.htmlhttp://www.ogre3d.org/phpBB2/viewtopic.php?t=5818 are a must here, so make sure you pay them enough attention!
This goes for the project planning document. However, it's important that you know what your client wants most and what you'll have to do to accomplish it. Keeping a list of prioritized tasks, with their estimated duration will be helpful; something like an enhanced to-do list. You might find rather helpful to add some extra info such as task type (implementation, documentation...) and task field (resource management, tests, prototypes, core engine functions...), as well as the time it took you to finish them. This will let you know how deviated you were on your initial estimations for a certain kind of tasks, and thus re-evaluate the earlier estimations for the "still to do" ones.
If you go for some agile methodologies such as Scrum or XP, that are iteration-based, tracking the iteration process is helpful as well. This lets you know how much time you invested each day, if you're on time or delayed for the scheduled release... or even the time use ratio (between the estimated time and the real invested time to decrease the remaining time).
It's important that you try to predict which file structure you'll need. Where source code will go, where resources will do so... So define a file structure first of all (the one you wrote down on the project planning). Indeed, you'll be punished by the ancient Lovecraftian ones if you break your file structure in the repository. Just kidding :P but that would be a very tough work to do, with its respective data loss...
Organise your SDKs, libraries... everything. If you need to set up environment variables or similar tasks... write that down: We developers are tendentious to forget to tell everybody (including ourselves!) to do that in order to get it running.
Choose a building method. Makefiles, Visual Studio scripts... anything is fine, but let everyone know that (remember the project planning document? ;) ). My personal favourite is Premake. If you're developing under Linux/UNIX, autotools are the de facto standard, though if you don't have the time to learn how to use them, don't do (in my honest opinion). You've signed a contract and your client wants your work done. Maybe he would prefer autotools rather than code::blocks scripts, but better having your work done and the scripts fixed later than losing a month learning redundant stuff.
It's been stated that the code you submit should be rather stable. You're submitting to the main repository, and the codebase is specially sensible to changes if you're playing with core code.
Write down a testing plan and follow it. I've found myself that test-driven development/design helps improving both the quality and stability of your code, so I would suggest you to do it. Test as much as you can, and automate the tests when possible. I know this is a graphics engine and a computer can't tell if something looks good or not, but I'm sure you can write some unit tests for things such as instantiating, default parameters, and other under-the-hood things ;)
Nevertheless, Boost::Test has also been suggestedhttp://www.ogre3d.org/phpBB2/viewtopic.php?t=29968&start=32 and is probably the best choice as Boost will become a dependency in Shoggoth (Ogre 1.6).
It's important as well that you do some regression tests before submitting your code (and specially if you're doing a task-based development). Believe it or not, two things that work separately might not work together. Regression tests (these can be automated too as a set of unit tests) reveal most of these issues early. I've clashed with some of them, and knowing what have you done lately that might make this happen is priceless to find the bug.
And not to mention about the acceptance tests importance. You'll have to periodically show your mentor and the whole community how it's going. This is a crucial part for the development. You can't come out one day and tell your boss "Look how cool is what I did along this summer" and him saying "What the... What's this?!". You get the idea ;)
If you've chosen to follow the Premake+CxxTest path, here is some code for your Premake script that will allow you to automate the testing process.
First, you'll need to add an option to the script:
addoption ("gentest", "Generates (but doesn't compile) the specified test(s). Use \"all\" to generate all the tests, and the regression tests runner.")
Then, add the stuff of what the new option will do:
function dogentest (cmd, arg) if (not arg) then print ("A test name or pattern is required!") else -- Find and create specified tests print ("Building the test runners:") os.chdir ("source/tests", "source/tests") if (arg == "all") then tests = matchfiles ("include/*.h") testscollector = "" for index, value in ipairs (tests) do dopackagefortest (path.getbasename (value), value) testscollector = testscollector.." include/"..path.getname (value) end dopackagefortest ("RegressionTests", testscollector) else tests = matchfiles ("include/"..arg..".h") for index, value in ipairs (tests) do dopackagefortest (path.getbasename (value), value) end end os.chdir ("../..", "../..") end end
The os.chdir part depends on your file structure.
Anyways, what this does is to create a new package (a project in Premake) for each individual test suite. If you use all as the test name, it will create all the unit tests, plus a huge test runner that will run all the tests (called RegressionTest for a reason ;) ).
The dopackagefortest(name, value) function just creates a new package for the test suite value, and output name name. The Premake documentation already talks on how to manually create these packages.
Example calls to this functionality are
premake --gentest WhateverManagerTests premake --gentest Cmd* premake --gentest all
The first creates the runner for the WhateverManager test suite. The second all the test runners for the suites starting with Cmd, and the latter creates all the individual runners plus the regression test runner. You add the --target <targetPlatform> at the end, and it will also include them in the building process.
The main goal is not you getting money, but becoming part of the open-source community. Or at least that's what Google pretends from you, and you don't want to have them mad at you!
One great way is to talk often in the forums. Ask there, tell us your progress, let us know what's going on... Indeed, this year backup mentors are a requirement from Google. Making your ramblings, documents, progress and all the development stuff helps that not only your mentor knows what's going on. If your mentor is not available for some time, we will know what you need and how to help.
Cool, isn't it?
Planning, estimating, documenting all the process... All this is meaningless if in the end you don't test, don't pay attention on what you upload to the repository... If you've done some planning documents before, then you should follow them as your bible, and trying to fix those documents the least possible.
Having good habits is priceless for development!
Take note that most of this comes from my own experience, but I can assure you that, at least the general parts, are important in real-life development.
Don't forget this project will help you integrate a community, learning about wild-life development, and become more experience in general. These are key elements of the GSoC and you should keep them in mind along this summer.
Maybe all this documentation stuff sounds boring and ugly, but it's a key part. I've found out this not long ago, but I'll for sure follow these practices in the future. You still have time to carefully elaborate this stuff, no matter if you're willing to use the tools I suggested or not. The program starts on May/June, and you still can play with the tools, libraries, think the document's content...
And... I think nothing else to tell. Good luck, and see you on the community!
JesÃºs Alonso (Kencho)