Re: The future, and our plans. Gathering interest.
Since when do we count our source code in characters? Is that with tabs or spaces (I don't know if BGT has indentation)
I don't even like counting code in lines either, because people space things out differently and there's always boiler plate code.
@20, no, setting a release date is the best thing you can do. Because it sets a target. If you have no key dates like that, you don't feel any pressure and you start working on things that are cool but doesn't make the game progress.
Now at both of you, take it or leave it, but here are some advice on project management based on my experience as a team lead. I'll keep it simple:
1) Divide your project in milestones.
This is easy. Just sit down both of you an afternoon and write down all the features you want the game to have. This can be for instance:
- Character moves
- Character doesn't pass through walls (collision)
- Skill - Attack
- Skill - Fireball
- 1000 levels
- Actions trigger sounds (this can be further divided)
etc. An afternoon is usually enough, you should leave features as big chunks or you can further divide them. This is not set ini stone either, it will evolve with the project, you can add new things, remove things, detail things, group things, etc.
Then you take features of that list and put them into milestones. For instance:
Milestone 1: proof of concept
- Character moves
- Character collides with walls
- Level 1 (partial)
Milestone 2: it lives
- Levels 1-10
- Ennnemies in maps
You must choose a cool name for every milestone, it's mandatory. The number of milestones is up to you and depends on your project. It's reasonable to have a milestone every month or every two months, you don't want them to be too big nor too small. This is flexible, you can have milestone 1 taking up a month and milestone 2 two months, usually you want the proof of concept as soon as possible.
2) Work
Ok, so you created your feature list, milestones in about an afternoon, now it's time to work and start with milestone 1. This is also easy. Break down the features in the milestones in tasks. Tasks should be a day worth of job, you don't wanna start and create tasks of 30 minutes worth of job.
The key difference here is that tasks are sometimes not directly related to the game. Say you take feature level 1 for instance, then the tasks could be:
a) Basic level editor: I can place walls, start of level and end of level.
b) Design level 1 in the level editor (depends on basic level editor): make and test the level.
You must scope the tasks, you don't get started and write the fully featured level editor right away, you just do what's needed for level 1. You do the minimum. You'll come back to it later for features that requires it. Otherwise you end up doing work that will not make the game progress.
It's handy to write when tasks depends on other tasks, because that mean you usually cannot parallelize them, you have to do one then the other after. You can create the tasks for the whole milestone, or about a week of work at a time.
Ok, so you've got your tasks, you can get started. Pick a task you wanna work on. one at a time, Now is the most important part, guesstimate how much time that task will take you. Make the basic level editor ffor instance, say you think it can be done in 8 hours, then put the guesstimate to 8 hours. Then do the task and measure roughly how much time it took. Say it took 12 hours. When the task is done, mark it as done and write how much time it really took (12 hours).
Doing the estimate and writing the actual time it took is the most important thing, because it allows you to:
- See if your milestones are reallistic or not
- Give you better guesstimate skills for future tasks in the project as well as future project management
3) At the end of a milestone
Test out your milestone, very important. See if you met all the features. Try to find bugs and put them to fix in the next milestone.
Then, reajust the planning. If you notice you are late compared to the schedule, you can reajust by:
- Removing features in milestones and in the final project or
- Work more hours to compensate or
- Push back the release date or
- Outsource work / hire new people (probably not applicable in your case)
And there are other things you can do about it, but those are the main ones. Generally, you will want to take those decisions at the end of a milestone.
Conclusion:
Project management is often overlooked. But it can also be dangerous, don't fall in the trap of planning too much. Planning should take between 10-20% of your time. You shouldn't plan in details things too far away time-wise, go in details for the week or the milestone. Every project is different and everyone works differently, you can adjust this method, these are just tips and of course there is much much more in project management than that.
Projects with no planning often will not ship or will take 5 years. Projects with too much planning are too heavy and you waste way too much time planning versus actually doing it. This is why this approach here is light-weight and I think it applies well to a project of 2 people like yours. To sum it up:
1) Feature list and milestones with cool name and key dates: one afternoon
2) Divide milestone features into tasks, can be 2-4 hours a week
3) Take tasks, one at a time, guesstimate it, do it and write the actual time
4) End of milestone, testing and planning the next milestone, 4-6 hours
Having a milestone centric mindset is great because every task you do is to make the game progress in some way. Plus, every milestone, you see your project evolving into the real thing. This is good for motivation. Don't fall into the trap of making every block of the game and wait until the very end to assemble everything, it just never works.
And that's pretty much it, remember that nothing is set in stone.
Advice over
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
