So I usually plan out quite a bit before I start a project, and so far I've never actually finished anything beyond simple utilities. But now I'm working on a roguelike which is nearing public testing and balancing. Without any planning whatsoever. Aside from some notes I wrote for ideas when I wasn't at my dev comp,that is. How does it work for you, do you prefer tons and tons of plans,diagrams and notes before you create that project or do you make no notes whatsoever until writing the readme for 1.0?

don't be afraid to work iteratively. you (the general you, not the poster) are not so smart that you can foresee every possible benefit and flaw of an implementation. get something working, then refactor. take the successful stuff and move on, drop what didn't work.

also, this is a great tip (at least i think). Design your data first. Figure out what you need to store on disk to define what the program will do. figure out how to load it (a generic json or xml parser is fine for this). iteratively implement more and more of what your data defines. for instance, if you were writing a renderer, figure out how a scene would be laid out in the file. iteratively implement more and more of the functionality. this seems to work best for me.

^ the above are my thoughts, and may not be true for you in general

Funny you mention this. I overplan, mostly because I frequently can't get a feel of the big picture and how all the parts will come together. This leaves me feeling that I haven't done enough-- which causes more planning and little getting coded.

Recently I got sick of that whole hamster wheel and started coding modules with only the thinnest design. I've got something that's playable but it feels exactly how you're NOT supposed to make a game.

ibebrett advice on refactoring is nice to see, though.

Pre-planning works if you are not alone on the project. As a team, you need to have some defined goal or nothing will ever get done. For solo projects, the design will most likely be thrown out a few times because of overestimation or a plain bad idea nobody noticed because you are the only brain on the project and never saw it coming. Since you're alone, a few napkin notes are good enough because you don't need to share the project ideas and they are quick to write. You don't end up losing weeks of documentation efforts because you had a better idea. The ratio of documentation time to coding time is too high to be worth it in my opinion.

My pattern so far with projects that have been in uncharted territory for me:

Start project, reach a point very quickly where I'm unhappy with the structure.
Start again, progess much further, but still reach a point where I feel the structure is a mess.
Start a third time. This time I usually understand the problem well enough that mistakes can be corrected with refactoring rather than a clean rewrite.

Planning becomes a problem when it gets in the way of progress. Planning is just fine. But don't worry so much about making it perfect. It's better to write imperfect code rather than spend so much time trying to come up with the perfect way to do something that you write nothing at all. And even if you can come up with the perfect way, you'll be wrong. It won't be perfect, and you'll find a better way to do it.

It's a simple philosophy. Your code is going to be wrong the first time no matter how much you plan. So why worry about it? Just write it. And as soon as it's good enough, move on to something else.

Human psychology comes into this. IF you are working in a small group (5 or less - due to the psychological group size of 5) then the communication between all the members can be high and any ideas or changes rapidly pass through the group.

This means that decision made by any team member (designer or coder or whoever else) can easily be known by anyone in the group.

When you get to larger groups, it becomes harder to get knowledge through to everyone who needs it. This means that if an issue comes up (eg: How much damage is the phaser supposed to do?), then the knowledge of the issue can take too long to get to whoever it needs to get to and this slows the project down (and can cause it to loose momentum and stall - or go over budget/time, etc).

A solid design allows a team to communicate beyond this threshold and gives a clear map to who needs to do what in the project. So spending time on the design is important.

However, with smaller projects (and smaller teams) there is still a problem with momentum, but it is the opposite. If too much time is spent on the design, then the project does not get enough momentum to "Get off the blocks" (so to speak) and the project stalls before it really begins. So much time and effort is spent designing that the goal of the project is lost.

Think of it like this: If you are trying to drive from one place to another and you don't know where it is, do you start by making choices to turn left/right at intersections, or do you first look at where you need to get to.

When designing a game you might originally start off by looking at where it is you are going to (your vision of the game), and then making the decisions to turn left/right at the intersections you come to (the choices as to how to implement your idea).

However, when doing this, you will find that a road (a solution to a problem or a feature you would like to have in the game) you thought would lead you towards your goal is a dead end or a one way street and have to back track (discard that feature or implement it in another way). Because of this, you have to find a circuitous route to your goal and because you get caught up in the minutia of these decisions, you can become disoriented and loose track of where you are going.

However, in a large group, because you can't communicate where you are going and what roads you are going down (the solutions to any problems) to everyone quickly enough, then the group breaks apart as each tries to follow the road they think is best (implement their own solutions to the problems).

Although there are exceptions, they are, well... exceptional. I have seen small teams (not just in IT or games) break apart (and this can be traced to the lack of communication - which mirrors what occurs in large groups) and I have seen large teams succeed (and this can be because communication was very controlled and everyone knew who was responsible for what and who to go to for the answers - and the groups weren't much bigger than 5 anyway).

So I think group size is an important consideration as to how much design is needed. The design is a plan of action for when problems arise. If the problems are going to be easily solved and communicated to the rest of the team, then holding the design in your head is acceptable as it helps to keep you focused on the end goal and deal with the problems as they arise. But, in large groups, the propensity of them to fragment (due to human psychology) means that a plan of action is needed in case the group splits up (implements their own solution to a problem).

I guess I use that iterative approach that Ibebrett mentioned.

I found that it works best for me if I write notes while I'm creating the project (not to be confused with commenting code). When I try to write notes before hand there's always situations that I never expected. And when the project is done, I don't want to write anything anymore. By writing notes as I'm coding I make short explorations into design decisions and get to see the results quicker. Also, I'm able to go back and review why the heck I thought going down a particular path was a good idea.

I usually start coding with only a rough idea of the game in mind (since I've been programming since 12 I've got a good sense of where I'm heading), and then develop the design doc along side the code. So I start by thinking about rough engine requirements, implementing and refining them, and only after that start refining the game idea.

I've found that planning too much early for me is just throwing work into the lake... Because I'll start thinking about cool features I'll never have time to implement, or that won't fit with the rest of the design. Adding features iteratively works better, as long as I've got a general sense of direction.

I might add this only applies to my solo games. If I were to work in a team I don't think this would work as well.