[quote:21iwyttg]1. How do I do ... a simple pathfinding?
For example: I have a "Game Over" screen where I want the "Game Over" sprite simply to move from one position (y coordinate) to the other (from below the screen to the middle). Some easing would also be nice.
At the moment I am either using the bullet behaviour on the object and set speed to zero if it reaches a certain point/coordinate, or to do a "simulate up" on that object.
However both methods seem fairly unsophisticated to me.
I don't think there are anything wrong in the way you do it, using path finding for this would be a bit "overkill" as it would be required to calculate a path there. But since you already know exactly where it is going and is going there each time, starting to calculate a path just doesn't make much sense.
It might be unsophisticated, but its a simple and effective way of doing it, there are no reason to make things more complicated than they need to be in my opinion, the simpler you can make something that works the better, as there are less chance of bugs and it will make you develop faster. And ain't that what is most important.
[quote:21iwyttg]2. How do I ... work with Layers correctly?
Same example as above: The game ends and I want to bring a "Game Over" Screen. I know I could make a Game Over - "Layout" for it however it feels better to me using "Layers" because first of all I don't want the music to stop and want the background to keep moving. It simply feels good I think, if a few things stay but just the layer changes.
That's why I make certain Layers (Game Elements, Player, Score etc.) invisible and another Layer (Game Over Screen) visible. But: Even though a layer is invisible you can still click on items in that layer. (for example you can still click the "invisible" Layer's Game elements). For a workaround I am now using global variables (game_element_layers = false, game_over_layer = true etc.).
But still that way doesn't seem so intelligent to me.
Making UIs are on the very top of things I don't like making, it takes a long time and is really boring And one of the reasons are as you mention, they require a lot of uninteresting coding.
I normally do somewhat like you, when creating layers, probably not as specific as you seem to do, but a normal structure for me is something like this:
Optional:
Depending on the game im making:
Collision (Will hold any collision elements that are invisible. And not part of an object in one of the other layers.)
Markers (If I want to make a more sophisticated building system where markers would be needed, then ill put them here)
4. UI (Will hold all UI elements that requires a parallax of 0)
3. Game high (Flying units, clouds, tree tops, and pretty much all objects that should give the impression of being above the player)
2. Game (All characters go here. Player and enemies a like, exception might be flying units and structures that the player can walk around in)
1. Game Low (All objects that needs to be on ground level, such as rocks, objects that can be collected, but in general objects that can be interacted with and ofc aint suppose to be above the player.)
0. Background (All background stuff, that normally cant be manipulated, exception might be Tilemaps, depending on the game)
But as you said you need some way of detecting whether something should be clickable or not. In your case you don't need a global variable you could just check whether the layer was visible or not. But in the end its pretty much the same, you need to check vs. something no matter what.