There is no good way to estimate this.

It is hard to come up with accurate estimates for another person. Programming time required depends on the individual developer. What may take me 30 minutes may take you one week. Something you may do quickly I may do slowly.

I recall reading that estimating software development times is a lot like measuring mountains that you are unable to climb. You can either compare it to other mountains of known size, or you can take apart the mountain and measure the parts.

The second half of larspensjo's reply above is actually pretty good on that:

To make a good estimate, you need to subdivide the project into small enough parts. The parts should be small enough to make it possible to estimate each of them with confidence. If there is a part you don't know enough about, then you have to revert to the formula above.

When you have a few years of experience you can estimate by comparing against other mountains. "This thing is like that other thing I did, and that took three months."

I wanted to know if anyone here had experience making a game on their own and how many hours would you estimate for its complete development (programming, sound, sprites, etc.).

For one, I have very little programming experience and have never completed a game in my life. I also know that other things like fidelity of graphics, sound and overall size and scope of the project could determine length as well. As such, I will give a clear vision of my game with regards to those parameters.

[...]

I plan to make a 2d action adventure game.

First congrats, you are asking an excellent question that most new game programmers do not ask.

Personally, for someone with limited programming experience and no completed game experience, I think you should walk before you run. Start with things like Pong and Chess first, then start moving onto isolated features of your game (each as their own mini project initially) like a simple 2d Tile system with arrows moving, etc.

Trying to jump right into something like Zelda is way too ambitious. Beginners often believe it is a short-cut to jump right into a fairly complex game since doing things like Pong would be throwing away code as they don't intend to sell it, but that is not true. Jumping into a project far too complex for your skill level (as Zelda is for you with limited programming experience) is not a short cut, it is a long-cut. You start trying to juggle far too many concepts that way without having the basic skill foundation, and you will inevitably see an exponential increase in bugs as the lack of understanding in the isolated areas cascades as the different functional areas interact. That causes a game so buggy that it either takes forever to make progress or more likely is so frustrating the code base gets abandoned and restarted from scratch. It's far better to first gain a lot of confidence and skill via tiny projects of increasing but feasible difficulty.

Switching to C# / XNA meant my productivity quadrupled, sometimes it attacks the 10:1 ratio. It's THAT different.

[...]

Of course, if you want to do C++ profesionally later on, then you just gotta get burnt, there is no real substitute for that kind of an experience. Reading about a bug fix on a forum and spending a day (or evern a week for that matter) under the debugger are two drastically different things...

100% agree. I'm using Lua and Go instead of Objective C or C++ and the difference in productivity is massive. I'm working on a 2-3 year project, that would instead take 4-6 years had I worked on it natively using Objective C / C++.

Not only that, but many professional studios these days are switching away from C++ anyways to higher level languages for the majority of their game programming, so even on the job front it is losing some of its luster and I expect that trend to continue as studios increasingly see less benefits in reinventing the wheel when excellent SDK's such as Unity and Corona already exist for cheap.