Software development plan for games

Hi /prog/. I've been trying to make small games for some time now, but even though I make some good progress, it always ends in a clusterfuck. I'm never sure what to do next and code is everywhere and totally out of hand. I'm pretty sure it's because I just start coding randomly without planning anything.
I was thinking that there must be some well tested development strategies for game making or small software development in general. I'm looking for something not too overly complicated, but that will get me a solid roadmap with attainable milestones and easy to calculate progress into my daily routine, but I don't know where to look.
Basically, I want to structure my approach in an orderly fashion, and if it can be oriented towards game development, all the better.
What do you know about the subject? Enlighten me please~
(bonus points if the strategy is scalable from 1 man projects to 2-3 people)

Yeah, we all know that feel.

That's why I switched to Haskell which instantly solves all my problems.

i guess you would need to start by really spreading your code out into lots of different files / modules. create a separate file in which you describe your directory structure and what every file is for.

i'm not sure what kind of software development strategies your talking about. if you're talking about things such as TDD or Agile XP SCRUM i think you're going to waste your time. Just document what you want, document your design and document your code. that should be plenty.

Well in Computing we have to flow-chart, document and pseudo-code all our projects before even going near programming anything. How much time do you spend designing the game? If you just jump right in, you'll end up changing things all the time which will cause a cluster-fuck of a design and software.

http://www.joelonsoftware.com/articles/fog0000000036.html
http://www.hungerinteractive.com/articles/blogs/Writing-a-Game-Design-Specification.html
http://www.sloperama.com/advice/
http://games.chuckbolin.com/summer/GameDesignSpec_BattleForKursk.pdf

>>5
This is the kind of stuff I was looking for. Reading it warmly now...
If you have more, please share.

It is good to keep things as modular as you can, as described by >>3-san. I always make sure all of the code in a module is correct before moving on to other modules, especially when there are dependencies. It can be good to have a test file for each module, that runs through all cases you'd like to verify. This takes a bit of time in the short run, but it is a huge savings in the long run, as you otherwise end up hunting down the bugs in your application, which is much more complicated than a simple test function.

For design, I think about what I'm trying to make, and what are the basic subcomponents that will need to be implemented. Once I can determine that something will be needed, and I have a way of directly implementing it, I implement it, and test it, and then move on with the design. I can use the working implementations of the subcomponents to test out possible ideas for the next layer. My first implementation of the next layer is a very cludgy thing thrown together that uses to lower components. Once I get results and know that the scheme will work, I rewrite the implementation in its own module, and test it. Holding off on the actual design until results are found can save times when trying out approaches that end up not working out.

You need to think more about design. The design of your code. How are you going to separate it? Is it a good idea to keep the application code separate from the presentation logic? Does that need it's own logic, function, namespace?

Just pay attention man, it's not hard. Audit your software's code and rewrite it if it's shit.

Why aren't you using engines?

>>7
This here is a programming board boy, not a Computer Science board, you best mosey on out of here.

>>9
This here is a programming board boy, not a Computer Science board, you best mosey on out of here.

This is also the SICP fetish board.

>>9
This here is a programming board boy, not a Computer Science board, you best mosey on out of here.
Change name to /compsci/, we are here. That is all!

I guess it just come to you after a long time of trial and error, after a while you'll be able to say "i'm gonna make a parser, libs loaded on demand, following this contract, this and that" even if you have never studied the design patterns formally. From there you can really separate your code in a number of layers, one very common for simple games is to make a very simple ASCII front-end while coding the bulk of the game and later on implement the rest.
But this comes with a lot of trial and error so expect lot's of rewrites and abandoned code.