When it comes to "copying from others", well most people hate the "monkey-see-monkey-do", but the reason this was named after monkeys is because monkeys copy each other in order to learn. So especially in experimental work it can sometimes be the way to go in order to discover what suits you best and to have a bit of practice in coding ("The only way to learn a new programming language is by writing programs in it" -- Dennis Ritchie). All that can be important before you actually start a serious project.
My advice is always:
- Lean from the masters. They faced the same problems you did before they became great
- Expect your first production to be crap, but don't let that let you down as what may be crap to other can be a good school for you to learn.
- When it comes to engines/programming languages. I know when I began, all we had was BASIC (and it cannot be compared to BASIC today). These days we got an overload of stuff. Nobody can advice what is "the best". You'll have to discover that for yourself.
- "Debugging is twice as hard as writing the code in the first place, therefore if you write your code as cleverly as possible, you are by default not clever enough to debug it". You're gonna hate Brian Kerninghan's word but unfortunately they are true, and it doesn't matter if you use low level languages such as C and C++, or high level stuff such as Game Maker or Godot or even codeless engines such as ClickTeam fusion. Debugging will always be the least satisfying part of the job. That is something you will have to learn to deal with. Although debugging has become easier thanks to many debugging tools and loads of engines/languages even offering those by default, but it can still be a chore. I don't want to discourage you, but it's part of the job.If you can get up a good way for yourself to handle debugging, then you are well on the way.