To add to what @sixrobin said, one of the things you learn about programming is that to build something big, you don’t generally make one massive integrated thing, you conceptually break the big thing into smaller problems and solve those individually. Often the smaller problems can be broken into even smaller problems. A lot of getting good at programming is learning how to split things up into smaller problems, and learning how to solve them in ways that mesh nicely with each other.
Programming is composable; you can build systems of systems of systems, ad infinitum.
One of the things this means is, if you want to learn how to make a roguelike, you don’t have to go into this tackling the whole problem at once. You can tackle it in pieces, and each piece can be a standalone tech demo or experiment or “game”. Later on, you can take those parts and assemble them into your unified roguelike game.
That is, you can work on it piecewise, and learn while you do.
For a roguelike, you’re presumably going to have:
- a map and navigation
- some sort of combat
- a character sheet of some sort the player interacts with (leveling up, etc)
- some sort of inventory management
- magic or skills
- level generation (populating the map with stuff)
- dialogue and descriptions
- triggerable events on the map (step here, something happens…)
- loot
- &c, depending on what style of roguelike you’re making
Each one of those components is a simpler programming challenge, and can be made first as a standalone test. You can find your feet programming the parts, and you’ll learn a lot while you do. You’ll also have fewer and simpler problems to solve, since the scope of each individual part is much more contained.
It also means when you ask for help, you’re in a better position to ask specific questions; while we can try to help (like this) when people ask open-ended general questions, you’ll tend to get open-ended general answers because there are no specifics to address. Answers like that tend to be harder to act on. When you can ask specific questions like (say) “I’m trying to do mouse drag and drop inventory management, but my icons always snap back to where I dragged them from rather than settling where they’ve been dragged to, what am I doing wrong?”, you’re much more likely to get an actionable answer that solves the problem.
At some point during the process, you’ll almost certainly decide that you’re getting the hang of it, and will be able to start stitching the parts together. Godot makes this relatively easy with the way “scenes” and the node hierarchy works; you can just kind of drag them into the same project.
To start, you might try going through one of the “make a simple game” tutorials; that will give you some direction.