>>12375296Not to be mean, but this is really more appropriate for /vg/agdg or /sci/sqt/. But I'm an amateur gamedev and I like answering these questions so you get lucky this time, punk
So the important thing here is fundamentally you don't change anything, the physics of a Zelda game are exactly the same as a top-down game. The drawing of the art assets on the screen, however, is quite different.
To explain, first we talk the physics. Link's bounding box is at the base of his feet. This is not quite his hit box: Link can be hit at the top of his head. But look at the black pixels that pool around Link's feet, that black oval, his "shadow." That's his actual bounding box that determines whether or not he's colliding with "walls" or generic barriers in the game. This shadow is drawn in game and gives players a convenient visual representation of what Link actually looks like from a gameplay perspective, and as players walk around the game world they become comfortable with the idea that Link's bounding box is at his feet and not the entirety of his body. This kind of thing applies to ALL objects in the game
Okay, the bounding box is a "squashed oval" so when Link collides with walls on the left and the right there's no issue since he doesn't intersect with these objects at all
However, Link can walk in "front" of objects and also "behind" objects. This causes an issue for the program that draws the scene: does it draw Link's sprite on top of the sprite of the object, or below it? The reality is that without defining some value, some kind of function, very carefully, you'll just get "bad" drawing behavior, or undefined drawing behavior more specifically, where whenever Link's visual body intersects with a visual object in the game world it will flicker back and forth between them.
The answer to this is not too hard: depth checks. Every object in the game has some kind of depth in proportional to its -coord.
