WARNING: this answer can be depressing. It can be depressing in two fronts: A) Our tools and data on software (size and time) estimation are not that good, and B) It probably will take longer than you think.
Positive aspect: expending extra time studying and familiarizing with development tools is probably always a good idea. Up to what extend it is unclear. Yet, one of the best ways to do it is by using those tools, for example to develop a game. If you do not expect this game to be your final game, but one you do to learn, you will be good.
I will take for reference the case of a single developer working on Underrail engine and alpha game: Dejan Radisic. This was from 2008 to September 2012, at which point it went on steam early access (there were a few prereleases before), which game him money to hire some help, and the final version was completed on December 2015.
Therefore, Dejan Radisic worked for about four years alone, and then there were three more years working in a team. It is unclear how much it would have taken him to complete the task alone.
Consider that new people on the team would have required Dejan Redisic to teach them how to work with the engine and familiarize them with the code base, during this phase we would expect his output to be lesser because he is giving time to train the other developers. After this initial phase (which I have no idea how much it took, or how relevant was its impact) we would expect the team to have some level of synergy, meaning that their output would be greater than if they were working on it independently. Furthermore, some tasks cannot be broken apart, and adding many developers will not make them any faster.
See: The Mythical Man-Month.
Next, we know that the output of a developer is roughly stable in terms of lines of code per unit of time, regardless of language. It can be improved by incentives (although the effect of incentives plateaus) and better tools and training. This is good news for high-level languages and tools, because using high-level languages will allow you to finish your work in less time. Furthermore, we know that number lines of code is the best predictor for software defects. Thus using a language that allows you to accomplish more with less lines of code (or an engine that allows you accomplish so much, with even less) are good in terms of software quality and developer output.
Of course, everything is a tradeoff… using high-level tools means that you will have less control over the performance. As a result, you may end with a game done in less time, with less defects… but that runs too slow.
See: Making Software: What Really Works, and Why We Believe It - see also: Greg Wilson - What We Actually Know About Software Development, and Why We Believe It’s True.
Note: We do not know how you compare to Dejan Radisic. Assuming that you are as bad (or good) as Dejan Radisic will result in a wrong estimation. Yet, I cannot control for this.
Addendum: We also do not know how many hours per day did Dejan Radisic put into the development.
Considering all that. Creating a game like Underrail, for a single developer should take somewhere from 4 years to 13 years (at the end Underrail was a team of 3 people for 3 years, plus the 4 solo years... 3*3+4=13; and I know that estimation is wrong because of The Mythical Man-Month).
Do you know Hofstadter's law? - The truth is that the majority of software development projects fail their estimation. We know that agile methodologies are arguably better; we can attribute this to the steady adjustments they do to their estimation during development. A common practice in agile teams is to multiply the estimation they get by some arbitrary factor... because It always takes longer than you expect (see Standing Group's CHAOS Report). In fact...
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Therefore, I may pick the arbitrary factor 3 and multiply our estimation to get a total time of 12 to 39 years. Then Hofstadter's Law.
On the other hand, most of that time is expend into creating a custom engine. If you use an existing engine instead, it will probably save you around 3 to 9 years of work.
If you use free art assets, or can get somebody to work on the art assets (sound, music, graphics, etc...) I would expect it would save you... ern... some time. It is hard to compare making assets with programming; also, the amount of work depends on how heavily your game depends on art assets. Let us say it is 50% of the time, just to be politically correct.
Now, if we start on 39 years, we take 9 years off, and half the time, we have: (39-9)/2 = 15 years.
Note: I base the above on what we know about software engineering and a single data point: Dejan Radisic working on Underrail. Do not consider this single data point statistically relevant. We also know that software estimation is susceptible to psychological anchoring (that is, given a guess estimate, even professional and well-trained engineers will yield estimates that approach the guess estimate given).
Finally, consider the Wait Equation[1]. We are steadily getting better developer tools and reusable software that will allow you to develop a similar product in less time. Therefore, there is an ideal wait time that optimizes the total time to finish a development task by taking advantage of the improvements in the technology.
It might be the case that it took Dejan Radisic three to four year to work on the game engine simply because the tools available at 2008 were not as good as those you find today. I do not think we have enough data to calculate the how much time you will save by just waiting to start your project (and taking that time to study software development and familiarize yourself with a variety of tools) by merit of improvement in existing tools and you getting better as developer.
[1]: The Wait Equation is the formula for the wait calculation proposed by Andrew Kennedy in his paper Interstellar Travel - The Wait Calculation and the Incentive Trap of Progress. The underlying idea is that given the improvements in travel technology, for a given arrival date to a destination there must be an ideal departure moment. Since tha article in Wikipedia has been proposed for deletion since I wrote this answer here a mirror, and two YouTube videos that mention it for context: The Race to a Habitable Exoplanet - Time Warp Challenge | Space Time and Will We Ever Visit Other Stars?.
Addendum: If you did pay attention, I told a lot of reasons why these estimations are wrong.
