This post picks up where the last one left off. Fair warning: this has been the toughest post to write so far. I changed the implementation several times while writing it, so even I’m a little lost at times. Bear with me and try to keep up.

Hanaa is one of the rare racing games where you can actually deadlock yourself. As we saw in the previous post, the car’s drop height is only determined at the start of a step, and physics are turned off while aiming. So if, say, a giant placeholder cube happened to land on top of the car, there might be no valid position left to place it. In that case, your only option would be to give up.

Luckily, unlike certain adventure game designers, I’m not a complete monster — I didn’t do this on purpose. In Hanaa 0.1.0, there’s a workaround that explicitly allows positioning even in these edge cases. That said, it’s more of a duct tape fix than a real solution. It’s likely to mess with physics and cause other headaches down the line, so a more robust fix was definitely needed.

My first instinct was to simply let the player adjust the car’s height freely. That would make deadlocks a non-issue. But of course, if you can raise the car too high, you’re just opening the door to a whole new world of problems — and some pretty juicy exploits.

To limit how high the car can be dropped, I replaced the initial box caster with a polling system that runs the cast once per second. This way, the height detection responds to dynamic collider changes and smoothly adjusts the car’s height so it always stays on top of everything. Unfortunately, box casting is a pretty expensive operation. When it runs regularly on the main thread, it starts eating into the frame budget — and things get messy fast.

I tackled this by making the polling asynchronous using BoxcastCommand and Unity’s job system. I’d already dipped into jobs when working on the track splines (more on that in a future post), but this case was way simpler — no need for a custom Burst-compiled class or anything fancy.

Automatically adjusting the car’s height brought its own set of hilariocities. Since the car was being lifted above all currently falling objects, it could end up perched in some truly absurd spots — like on top of a tree. To fix this, I had to exclude dynamic objects from the box cast while they’re still falling. Hits are only enabled once an object hits the ground, which is basically just a layer switch on collision. It’s probably not a forever-fix, but if it blows up later, I’ll cover it in another blog.

The more I used the automatic height adjustment, the more annoying it became — so I scrapped it and gave control back to the player. Now, the poller can only raise the car’s ceiling height, never lower it. That means you’ll never get stuck unable to return to a higher spot you just came down from. Cars can always be lifted above whatever’s in the way, and the logic stays as unobtrusive (and unconfusing) as possible.

So once again, the feature turned out to be more complicated than I expected. But based on my own testing, altitude issues seem to be sorted out. I’ll be removing the old workarounds in the next release — fingers crossed it doesn’t lead to an emergency hotfix.

Now that the car is properly aimed, dropped, and pushed, we need a way to detect when it’s come to a stop. More on that in the next post.