Game Dev Diary: The chaos in order(ing)

By X-51 | Game Dev Diary | 1 Jun 2020

Not the post I was planning to write tonight, but I've hit some trouble regarding ordering and perspective which takes precedence over the other stuff.


For those who know about such things I am talking primarily about z-index.

For anyone who doesn't know what that is, it is a term in web & software which determines which bits draw in front of other bits, where any higher number will draw over any lower numbers eg. z-index 0 will display behind z-indexes 1 and 2, 1 will display over 0 but under 2, and 2 will be on top of both 0 and 1. Or in pictures:



Normally this wouldn't be a big issue. For a true 2D perspective game such as a platformer or a top-down game there is no problem, you pick which layers should be "higher" than others, you set your z-index appropriately, and you'll probably never think about it again.

With an engine like Phaser you never even have to set any z-indexes - you just create your layers in the right order and it is done for you.


But for a 3D world rendered in a very 2D way such as with orthographic and isomorphic projections you can soon run into problems. Easiest to show in pictures.


Given the following map, what you would expect to happen in reality is that a person standing in the room will be visible in front of the wall, and a person standing outside the room will be (at least partially) hidden behind the wall.



But because this is fake 3D, the wall has no third dimension - it is just a flat plane - so setting z-index one way or the other will give bad results. Here is the same setup with two copies of the character added - one with the character layer over the wall layer (characters have higher z-index) and one with the character layer under the wall layer (wall layer has higher z-index):



As you can see, the left hand side has the guy in the room drawn correctly, but the guy "outside" the room looks like he forgot about the big step in front of him and is about to go for a tumble. Then the right hand side looks even weirder - if it wasn't for the shadow showing him standing you would probably think the guy in the room was victim of an inconsiderately heavy wall falling on him, but the guy outside the room looks perfectly normal.


So what avenues do I have to fix this problem? I know of two (but hey, there may be more! I am just a beginner at this stuff).


Firstly there is the "cheating" way of doing it.

If you think about it, the character will never overlap or underlap approximately half of the wall. With some strategic positioning of places the character is or isn't allowed to walk I can guarantee exactly where that will be - about 2/3 of the way up the door. So then I could build my 3D wall in 2D space by splitting it into two layers as below:



Now piecing it all back together with the lower walls at a z-index of 0, the character's at a z-index of 1, and the upper walls at z-index 2:



Yay! It works.

But did you notice something important - I left out the door here. Because now what z-index do I draw the door at?

If I put the door at 0 the character will overlap it when he steps into the top half of it. If I put the door at 2, the character will underlap it when he is inside the room. But more importantly, if the door does not fit the hole for it perfectly the top half of the door frame will disappear behind the wall (and it doesn't fit perfectly, the door overlaps the hole by enough to be VERY obvious).

Continuing the line of thinking and cutting the door in two parts is just opening up a world of additional complexity for myself. It will solve the z-index issue, but because that door is an animated object I would have to place two objects in my Tiled maps for every door, duplicate all variables set in Tiled, and then in-game I would have to handle controlling two animations any time the character interacts with (opens/closes) one of the two halves.


So what was the other solution I know?

I'm not sure if it has a commonly used name or not, but the process is all about changing an object's z-index based on their y-coordinate.


Going back to maths at school for a brief second, the x-coordinate is horizontal, the y-coordinate is vertical. In maths we would always draw a graph with the origin 0,0 at the bottom left of the positive quadrant so x increases as we move right and y increases as we moved up. However here we are drawing with the origin at the top left. The x still increases as we move right, but our y now increases as we move down the screen.

So for this I would need to set the character's z-index based on the inverse of their y-coordinate and everything would be perfect. Right?


Nope, unfortunately not 😂


I mentioned in my post about sprite sheets and tile sheets that my walls are tile sheets so nothing is evenly divisible in a programmatic way in the image, and so I am just drawing them as tiles in Tiled and not objects. Objects would have a distinct y-coordinate regardless of how big it is, because each object is anchored to a single tile. But as tiles every 16px square of wall has a different y-coordinate 😩


So no amount of calculations here will ever work, unless I do one of two things: either make each section of wall that should share a virtual y-coordinate into a separate layer in Tiled (with a variable to define the layer's virtual y-coordinate that I can read in Phaser), or I change my walls into objects, so each wall has that awesome distinct y-coordinate thing going for it.

One of these options is incredibly annoying, stupidly error prone, and will be even more annoying if I decide to move walls around. The other option is just plain annoying, but is the right thing to do.


So yeah, I just completely contradicted my last post where I said that having walls as tile sheets is not a big deal, and that just drawing them as tiles is fine 🤣 However it does support my idea that fleshing out the story right now is damned important!


Thankfully I worked out a process for brainstorming the story that just seemed to be magic for my often disjointed brain, so I've already made some great progress on the story in just a single day. My very loose collection of ideas now has a well-defined start, part of an ending, and a few middle details, so I should have something to write about my process behind that in the next few days.

I also have made the pretty impressive (to me, anyway) leap from an unmoving character to one who will move to valid locations on mouse click, stop on mouse click of an invalid location, with the correct animation based on whether he is moving or not and the direction in which he is (or was) moving, and also has full pathfinding capabilities for when obstacles exist!

How do you rate this article?



Software developer, musician, photographer, traveler, crypto enthusiast

Game Dev Diary
Game Dev Diary

A place for me to document the processes, decisions, challenges, and struggles of creating a video game.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.