Welcome to the game development community! This is a place to talk about and post anything related to the field of game development.
I think it's fine to engine hop a bit as long as you actually build something interesting in each one. Even if it's the same game every time, you're still learning different ways to do something. That's not a waste.
If your goal is to finish a game, you should maybe take notes about the engines you've tried and set yourself a deadline for choosing your favorite.
Every engine is going to come with engine specific problems. You will also come against many general game development problems, for which the engines have come up with many different creative solutions.
I can't make it any simpler for you. You will waste a bunch of time learning stuff. The only way to avoid that is literally building your own engine that conforms to your expectations and assumptions, because noone else can do that.
There are so many invisible boring-ish problems. Ui, scaling, networking, instancing, level changing, loading screens, even scheduling etc. You need to learn to love the boring stuff, because it comes at a 10-1 ratio towards the fun-ish creative problems.
However it's best to start wasting that time today than next week.
I completely understand where you're coming from because I very much used to be very much the same way. Problems like this can be frustrating because you feel like you're wasting your time, youre telling the engine the right thing but its not working and you feel like it's taking time from other problems you could be solving.
My advice: go easy on yourself. Write down all the other stuff you have to do so you dont forget it, and give yourself time to focus on that specific problem to see how you can solve it. Dont look at it as something blocking the other stuff that you have to do, look at it as just another task in your project.
In the case of the Z axis issue, take a step back and start reading about the Z axis and how it works. Create a separate project and start playing with it to see how it works for yourself. Convince yourself that this feature is not broken, and if you still can't make it work on a simple project at least you'll have reduced the problem so that if you ask for help online, it's more likely someone can spot the issue and tell you where you went wrong. If you do manage to make it work, at least you'll have something working to compare your original code with and make it more likely to spot the problem.
What differentiates an experienced developer from someone who's learning, is that an experienced developer has already ran into and solved a ton of small problems like these. It's a hurdle you need to overcome if you want to become effective at developing games.
Your Godot problem sounds like you might have ordered your scene tree wrong. The scene tree reads from top to bottom, so if your interface elements are further up the list than the map, they draw first and then get covered up.
Isn't there a node that will order its children by ZIndex or somesuch? I haven't really used Godot much, but I remember that being a useful thing.
There is a node for Y-sorting in Godot 3, is that what you're thinking of? Y-sorting was rewritten for 4.0, so that node doesn't exist in the latest version.
That sounds like it, yep. It's been years since I used it, so that definitely tracks.
AFAIK, the Z index was supposed to be the definitive thing defining what shows on top of what.
There was also a weird problem where my map would display on top of characters if I moved to tiles in the negative position (x < 0, y < 0), so I had to make the whole map within positive values.
Choose Rust. Problem solved.
/s