What are some methods that you've used to determine what game you're going to make (and eventually release)?

My main concerns are the following:

1. Over scoping the project and asset requirements (specifically things I cannot do: art, music, and sound effects).

2. The project ending up being too similar to a game that's already been released.

There are quite a few games that I've played where I would love to take the core gameplay concepts and greatly improve upon them, but this comes back to #2 as a potential problem, and I don't want to simply clone a game or have it labelled as such, but I'm also not confident enough in my design ability to take something and make it truly unique (yeah, I know, "unique" is being used loosely here).

I do have some self-imposed constraints to keep the scope reasonable (2d, no online features, no major story), but this hasn't helped me really narrow down what I want to make. I'm stuck in a limbo of "I'd love to work on a game, but what the hell should I work on?"

Thoughts?

Or am I missing something? What is your purpose for making a game, and why don't you already know what you want to work on?

The main purpose (aside from the obvious enjoyment) is to see through the entire development cycle of a non-trivial project where I'm the only programmer on the team (both for learning purposes and because it's a major goal I set for myself since I graduated from school). I should probably have rephrased the last part to "...what the hell should I work on, taking into account points 1 and 2?" I think I know what I'd want to work on if I stopped worrying about #2 so much, though I'll admit it's been hard to get over that so I'm looking for some advice so I can make sure I take a step in the right direction.

With that update, I'd say the answer depends entirely on the reason you are making the game.

If you are trying to do it because you want to get rich and make millions, both are wrong. In that scenario you need to do market research and figure out what games are likely to make money based on the investments you can make.

If you are looking to make a spiritual successor to a specific game then neither particularly matters, your scoping matters only it making it a size that you like, but being too similar or too different is irrelevant.

If you are making a game because you want to learn how to make games, then it is better to do a different pattern; do as much as you can in one month and call it your completed game, and repeat for several months with a different exploratory game, at the end of each month declare that you learned what you could in one month, are done with that experiment, and are starting a new one for the following month.

If you have some other reasons for the project you are working on, those reasons should guide your goal.

You state that your reasons are to see a product through the entire development cycle. So do that. Figure the smallest thing that you can think of that qualifies as a "non-trivial project". Your non-trivial project is likely different than my non-trivial project. Build up a concept and a pitch, experiment on paper until it is tuned and minimal in scope. Then implement it, write tests for it (automated tests unless you plan on hiring someone to test it for you), build whatever deployment system you want for it. Then make sure people can deploy and run it. When you're done, give yourself some kind of certificate or reward saying 'good job on doing the entire cycle', because an appropriate-sized shipping party is part of the cycle. Finish it off with a good old-fashioned post-mortem so you can solidify what you've learned, and then move on to the next project.