   Proper project planning techniques?
  Do you guys know any good techniques for planning projects in a successful way?One of the books I was reading had some good ideas- basically planning out all the screens in your game, and the classes and attributes in your game that you think you will need. But I am also not sure about how to judge where deadlines will be set and therefore what you can include in the game.Any good methods you use or know of?   
  I'm not really qualified yet to give suggestions about project planning, as I've just jumped into my projects in the past. So let's learn together :)I have started to discover the power of plotting out at least all of the main-features, and write as much as possible and then prune. Simply just typing away can open your mind and increase your creativity.A plan should just be something that inspires you (and your team-mates) to get to work really.What I will train myself to do is to always write about a single main-feature on an A4 paper and draw pictures to represent my ideas. And instead of listing features, I will always make mind maps. Just a way to keep focused, which is what we all want, right?Currently I'm planning a project that I don't really have a clear goal for, just fleeting ideas. There is a lack of focus. So the challenge is to find features that really inspires me, and just specify these features in ways that inspires me.About deadlines: for all my future projects I will keep to the standard of one main-feature in a day.So what does that mean? It means that you have to plan your project very well and try to keep things very simple. The games I have been planning recently have about 3-5 main-features. And you may split them up into smaller parts too, but the point is that you finish a feature in a day.That way you will feel like you actually achieved something! :DOf course I'm speaking about simple game projects here, not projects where you have to develop new engines and research lots of things.Well, now I have to get to work on planning my own project!   ;  Well the first step is determining how much the client is willing to pay.... :PProject planning is largely determined by the happy medium. A small project can be done with little to no planning but a major project will require a lot more planning and documentation before the first line of code is even considered.I prefer to create a list of features and any basic "assumptions" first. I also look for any relevant theories that I may need such as physics equations or referances on how the project might work. I frequently make a list of the major functions and use this as an initial breakdown. Beyond this point Data and access routines are determined.Once I get a good grasp on how the project might look I tend to build a prototype to testout any areas that I think will give me problems. Each step of the process often forces me to back up and adjust the design.For time and manpower planning I break the design down into small easily handled "modules" and then just guess-timate. I usually double my estimate for every layer of management involved....   ;  I also throw in an idea.Assuming your break your tasks down to hours, which I normally do. Don't assume you will work all 8 hours, or 10 or whatever a day. Also don't assume you work every day of the week. You might get ill, take vacation, etc.The biggest problem is judging what tasks are involved to make the game and then to actually give a good estimate on how long such a task takes to complete it.And in case you got a client you have never worked with before, it will be a fun experience to see if they actually consider your tasks approved. So while you might think you are done, they might think otherwise. :-);  No matter if you are doing a game, robot or small database application, ALWAYS have a worst case scenario in mind. And not only to cover the days you(or your team) are unable to work. At the beginning projects usually have lighting fast progress, but it gets sturdier as you move on. And if you didn't need the reserved time, then at least you can take a breath. Either way, making a somewhat accurate planning is a difficult job. Frankly, I don't thick you can make a proper planning unless you did the particular job (partially) before.When working on new/difficult/prototyping projects, bug chasing and trying out new techniques can cost you days, weeks or even months on big projects. With games, you'll likely meet a lot new techniques. For example, I'd like to add a clothing shader to my game. But never did it before. Maybe I'll find a good paper that helps me on my way within a few hours. Maybe it takes days before I finally understand it. Now a difference of just a few days isn't much on a big project. But if there is a lot of new stuff to try out... required time could easily triple. That's why experience counts in making a planning.Then you have these damn bugs. Again, it depends on experience of course. Like the others pointed out here, making an isolated module with a testing stub is likely to work smoother than implementing a new piece of code in an already huge framework. I often found new bugs weeks after implementing something new. Pull a string here, and who knows what happens elsewhere. Seperated modules and proper documentation can help you a lot though. However, doing so also takes time you'll need to plan of course.Even so, you'll most likely encounter bugs. Some are easy to trace, others almost make you commit suicide. Trying to figure out Multi-Threading bugs for example... I don't know how experienced you are, how big the project will be, and if yo work alone or in a team. If it's just for the fun, I guess you won't/can't spend lots of time in making a really solid documentation and framework first. Nevertheless, I would recommend to make a list of "Milestones". A milestone could be "Material system", "Entity system", "Shader library" or "HUD Menu's". Then make sub-targets. Physics --> Player movement, ragdolls, world collisions, rigid bodies, .... And give them a priority. That doesn't give you an accurate planning yet, but at least you can work on concrete tasks and review your own progress.You could write down how many hours/days it took after completing a task for the next time. Likely you will be faster when doing it again, but it gives you some sort of "worst case" time indication.Ow, and don't forget, game technology is very dynamic. While making your project, 101% chance you run into new interesting features you'd like to add. Sometimes you'll even want to rebuild entire modules to catch up.[Edited by - spek on May 11, 2010 5:46:40 AM]