Weekly Update #25 – 3D Is Hard to Fake
Welcome back to another exciting edition of “maybe we should have used a 3D engine for this!” This week I added in some furniture to make the rooms look less empty, but I opened up a can of worms by doing so.
Up until this point objects haven’t really had any height to them and have been anchored to the ground. With all these new destructible props being added in like tables and desks, I wanted to be able to stack lots of doodads on them. Now I didn’t think this was going to be a problem (I never do), but it turned out to be quite difficult to implement in our pseudo-3D setup.
To understand why this is so tricky you first need to understand how most 2D games draw their worlds to fake a 3D perspective. If you take a look at the old arcade game Final Fight, you’ll see that one character is closer to the camera than the other:
The game can fake this 3D perspective by drawing each character in order of their y-value, or in other words how far down the screen they are. It first draws the guy in the white shirt because his y-value is lower, and then it draws the guy in orange so it looks like he is closer to the game camera.
Cryo does mostly the same thing to keep everything in the proper perspective, and there were no problems with it until I added a dreaded THIRD DIMENSION to the objects. Because I wanted to put some objects on top of others, i.e. a computer on top of a desk, I had to also track their z-values or how high they were off of the ground.
In this picture, the computer is sitting on top of the desk, but if didn’t have a z-value (which I’m calling altitude) then it would be sitting on the floor underneath the desk. This created a new problem where I was now factoring in two separate dimensions when figuring out the draw order.
The problem arises because an absolute draw order can’t really be determined. Obviously the computer is drawn after the desk because its z-value is higher than the desk is tall. We also know that the desk should be drawn after the chair because its y value is greater (farther down the screen). However in this example the computer should be drawn before the chair because it has a lower y-value, and this creates an endless cycle of swapping draw order because the desk is drawn before the computer which is drawn before the chair which is drawn before the desk. That endless cycle looks like this in game:
The computer and the desk are constantly positions in the draw order.
I tried a lot of things to fix the problem, but it seems like no matter what your rules are for draw order you can find a scenario where three objects can’t resolve their ordering. I have a decent solution which works most of the time, but I still get he occasional flicker with the right kind of objects.
There are some more complicated solutions other than a flat, linear draw order, but I’d like to avoid them for now unless they become necessary.
Oh yeah we also added a new enemy to the game, but the animations are still rough so it’s going to remain a secret for now. Even though I had some frustrations this week, development is still coming along really smoothly for the most part. Look forward to some cool updates in the coming weeks!
Thanks for checking in with us again, and we’ll see you all next Saturday!