My excuse
The one thing I needed to make my game complete was to be able to tell when you’ve hit an obstacle or thing.
Pretty simple, right? Add a collider to each thing and then check if the player’s thing is touching any other thing. Unity’s physics engine makes this as painless as it can be.
But that didn’t work for me. Even when my objects were touching one another, they still failed the collision check every time.
Can you guess why? I’ll give you Unity pros a second to figure it out.
Yes, all the objects had proper box colliders.
Yes, the collision areas were overlapping properly.
No, they weren’t on separate layers.
The problem is that colliders are not updated synchronously.
They only get updated when the physics engine does its thing; that is, on FixedUpdate(). And my game doesn’t use FixedUpdate() or even Update(). It’s turn based; all iterations of the game loop are triggered by the Next button.
So when you click Next, the mule moves forward, touches the obstacle/relic/whatever, and the game immediately checks if they’re touching; but they actually aren’t, because even though their positions have moved, the colliders haven’t yet.
I don’t know what the right thing to do is in my situation. Maybe I should store the locations of the obstacles in an array. Maybe I should use colliders and refactor the game logic to run in FixedUpdate. Either way, LD36 is over.
What I learned
- unorthodox gameplay mechanics means you’ll end up spending more time on design and iteration
- simulations are a terrible idea for game jams — good thing I discarded that idea early on
- I’m a million times more productive outdoors, with no chores or cat to distract me
- (from looking at other entries) having unique art is wayyy more important than having unique gameplay
- stick to a color palette dammit
- work with your engine’s strengths
- some bookbinding trivia
