I usually start by writing a task requirements document, which is basically just a list of all the things my code should be able to do. The requirements almost always change before the project is over, so I try to keep them flexible.

For Pac-Man, my task list would look something like this:
- Draw maze
- Draw characters
- Draw dots
- Draw score, etc.
- Move characters around either by AI or user input
- Pacman "eats" dots as he moves
- Ghosts follow Pacman
- Die if eaten by a ghost
- Progress to new levels whenever one is cleared
..etc.
The task requirements list is usually pretty long. Pacman would probably take around 25 or 30 entries, while a more complex game might take 5 or 6 pages.

Once I have a basic set of requirements, I run through each one and write down all the things I can think of that I need to do for each task. For example, my requirement of "eat dots when pacman moves" requires the following:

- Track where dots are
- Track where pacman is
- Track score
- Get movement for pacman (keyboard input)
- When pacman moves, test for dots in his position
- Increment score and remove dot if there is one

Naturally this can be quite a process. I usually call it the Analysis phase. It is very wise to get into this habit for design because it will make your life much easier when you get around to coding. It will also make your fingers very strong from typing 30 pages of analysis.

Once I have my analysis, I remove all the duplicate or very similar items, and start grouping them together. Everything related to the keyboard I put in one group, everything for drawing into another group, and so on. Then I look at each group and use it to create an OOP framework.

By this point I''m usually half insane from wanting to code, so I go ahead and code a loose version of the OOP framework. I put class definitions in H files, and implementations in CPP files. I usually have ProjectName.cpp as my entry point, general mess collector, and so on, while ClassName.cpp and ClassName.h contain pretty much all of my other code.

I also like to use Common.h or other similar files for stuff I put in every file. This means I rarely have more than one #include per file, since I just #include common.h and all my project''s headers are right there.

I keep all my projects in my \programming folder on my data hard drive. Each project has its own folder, and then several subfolders. Generally I have Assets, Docs, Code, Archives, and a handful of other folders for each project. I''m an organization freak -- but you''d never know it my looking at my office

I split classes into sub-systems and add a prefix to filenames that corresponds to it, e.g. a graphical user interface hierarchy may contain:
GUI_Widget.h, GUI_Widget.cpp, GUI_Button.h, GUI_Button.cpp, etc.

Instead of having a huge list of files ordered alphabetically you can create folders that correspond to systems and sub-systems and drop files into them, e.g. my current project is split into the following systems:
Console, Game, Renderer, Support, and System (these correspond closely to the systems suggested in an article on flipcode here)

Those systems can then be broken down further into sub-systems:

Support

• Collision


• File IO


• Math


• Patterns


• Utilities

System

• Config


• Input


• Message


• Platform


• Sound

So, as a final example, I have a System folder, which contains a Platform folder (amongst others), which in turn contains the following files:
Plat_Application.h, Plat_Application.cpp
Plat_Interface.h
Plat_Timer.h, Plat_Timer.cpp
Plat_Window.h, Plat_Window.cpp

pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code