After releasing The Onion Knight
this past weekend, I learned something about wrapping up the first game using the Hondenkat Engine
. I did not like being constrained to using 64x64 sprites when dealing with the main character or moving entities (ex: guards). It made everything feel tiny. The main reason that simply making larger art didn't work is because of something called "z-sorting". This is basically figuring out the depth of which sprites are drawn.
When you just implement it at face value, you start to see sprites overlapping each other when they "shouldn't be". By shouldn't be I mean if a sprite is higher than the sprite below it, it should be behind it. But since these things are layered in order of when they're first rendered, it becomes a problem. It becomes a bigger problem when you have tons and tons of sprites trying to figure out where they should be on the z-index.
Fortunately, the Hondenkat Engine
basically only cares about sprites that are on the main 9x9 grid. This allows me to employ the z-sorting forcibly. In this case, I simply render 9 sprites after everything else has been rendered. I know then that these 9 sprites will be the last 9 sprites created and will always be in the right layer order. The 9 sprites correspond to the y-position of the grid and I can assign the game sprites to the same z-index as the last 9 sprites I rendered based on their y-position.
So if I have sprites where their y-position is 3, then I will assign them all to the same z-index as the 3rd sprite I rendered at the end (those z-index sprites). That way they will always be in front of the y-position 2 sprites and behind the y-position 4 sprites. It works well because of the 9x9 grid makes sure that at any given moment I will have to apply this, at a maximum, to 82 sprites (9x9 + 1 player).
Is there a more eloquent solution? Very likely. For me? This is an example of "great usage of coding duct tape".