Well, I always come up with some basic idea, and then start programming without planning
First I program the engine and then all the stuff around it like menus and highscore.
And yes, I don't plan at all

I usually get the basic idea for a game, then I get all the low level stuff finished. Input handling, audio, drawing to the screen. Usually I'll import an engine I already have done though. After that I work on bits and pieces starting with the maps and movement, then to more high level stuff.

Edit: To expound a bit, I always try to do one thing at a time and work linearly. I try not to do >9001 things at once. Also, whenever I see a bug, I work on it until I fix it.

I pick up a piece of A4 paper, and a I write everything I should do. Before that, though, I choose the tools and libraries I'll use to make the game. It's also good to make a quick prototype before. For example, if I plan to make a 2D game, I could make a very quick prototype in Python (faster to make) to see how it feels, and then rewrite it using the final language and tools (for example Vala with OpenGL).

I also make some drawings on the very same A4 piece of paper, like sprites and levels. I scratch out things I've finished too.

Not sure whether this has really been discussed before, but I was just interested to see how people get their projects finished, how they plan them out, what order they complete the various parts in (i.e. title screen, physics, sprites, etc.)

Thanks!

It really depends on the genre of the games. for example, RPG can take a lot of planning process (>30 pages of papers)

when working with a big project, planning things out beforehand will almost always save you having to rewrite everything once or twice. also, saving fun bits like titlescreens for last and getting main game engines out of the way first will help to keep you motivated. however, too much planning things out and not enough actually writing will demotivate as well, as it pushes back the yielding of visible results. it's a difficult thing to balance, which is why so many projects get dropped.

It depends of the type of game, but I always found out that having the title screen and copyright year too early seems to be some sort of a curse or something, as every project where I did that never got completed, but otherwise, in the case of an RPG (role-playing game):

1) Planning stages, where the story is written.
2) Planning stages, where the game variables are planned, along with other mechanics
3) Writing menu engine (in-game), except saving/loading.
4) Battle engine+magic/attack animations, using test monsters
5) Walking engine (with test maps)
6) One test event, for example a boss fight or NPC, to make sure transition between walking and events is going well.
7) Village shops
8) Saving/loading, to make it easier to test the game as you progress into development
9) Make more maps and implement the game story with intro and everything
10) Once you are comfortable with the maps, add events
11) Makes more map, events, shops, etc, until the game is done


NOTES:
A) During the entire development phase of the game, including planning stages, progress is backed up on the computer or a different hard drive, or as soon as I got a lot of progress done in a short period of time. In my case, if it was a calc game, I did a backup on a second calc via the link port every few hours.

B) ALWAYS Work on the game code in solo! Otherwise the project will fail, even with Github and co. You can get help on forums, though, but for safety reasons (ie. making sure you can still read the code), get the game optimized only at the very end. For team projects such as RPGs, teamates should only work on planning, design (sprites, storyline, names, maps, etc)!

C) Watch your RAM to ensure you have enough left, to not hit a wall like I did many times in Illusiat series. Notice how most Illusiat games ends abruptly after the final boss: Not enough RAM was left for the ending.

D) Avoid rewriting your project constantly. Falling under that endless rewriting loop will cause the project demise. I saw many TI projects die in the past 11 years because of that. Only do so as last resort, and to prevent it at all cost, always plan before coding!

Yeah the rewriting part is quite nasty. It seems people will rewrite for optimization purposes, but then they fall under an endless rewriting loop (see E:SoR for example), where they eventually lose interest and the project stalls.