Start with specifications and a plan.
I start with the comments first. I'll start each section of code with a short "header" description of what that code is supposed to do.
I leave a few comments here and there to describe what I'm doing... never specific enough...
Then, I'll add detailed comments (perhaps a little less formal than psudo-code). If I can't figure-out the flow, or details, I'll make a mini flow-chart for this section of code.
After I have the section of code documented, I'll start adding real code. Each line of code should relate to a comment. As I add code, I'll edit the comments to make them more like normal comments rather than psudo-code. When I'm done I usually end-up with about one comment line for every 4 lines of code.
THE BIG PICTURE
Before you start, you need a specification... A description of what the program is supposed to do. For a simple program the specification might exist in your head, or it might be an assignment in a few sentences from your instructor. For a complex game, a complete specification would be several hundred pages of text and diagrams.
That's a good way to start. You need a "big-picture" view of what your program is supposed to do. You need to document the flow of the program... how the different parts relate to each other. For a game, it might help to make a storyboard. You could even use 3x5 cards, with different major sections of the program/game/story on each card. You can then arrange them to see how they interconnect.
...little pictures of how my game works, just so I can fit the general idea of it into my head...
In your case, I'd suggest you (at least) make a list of the things that the program must do, and another list of things that might be included. I assume that you don't have a complete spec, and that you will figure out some of the details later... this is OK for a hobby project, but a disaster for a commercial program in the "real world" of bosses, customers, budgets, schedules, and multiple programmers. :)