207th day of development. Some cleaning up

The physical body will also change its shape, just could’n catch this moment for snapshot 8)

Didn’t have much time for my game this week, just tweaked a bit some old models, and considered to start maybe playing with Unity again. Also, cleaned up some of the mess in my code — let’s talk about that.

Right now, when a character collides with a platform (e.g. by falling down on it from above) — two things are happening:
1 — character’s display animation changes (e.g. from a falling sprite to a running one)
2 — character’s physics changes (I had some hacks to gravity and physics to get the right jumping trajectory)

Before I had both of those things happening one after another — the animation change function was being called by my gameplay package, and it would, in turn, call another function that would tweak the physics.

The problem with that is that it’s all time-based. For instance — every time we show “jumpStart” animation sequence (character pushes herself off the ground), we have to attach a jump-mode physics to the character, and then after some time — change it to “jumpUp” animation (character is actually flying up in the air), and finally after some time we have to change to “startLand” animation and add landing physics, and if the landing was successful — show the successful touchdown animation, change physics and go into running mode again. But if all of those changes, despite them being initiated by a player, are time-related, when something happens to the character — the sequence still completes because it hard-coded just based on timing.

Today I sorted out this mess by separating physics-related changes from animation changes and removing timer as being in control of animation changes.

Now at the beginning of the level, a periodical function is set up, that constantly monitors character’s vertical velocity.
If that function detected that the character is rising, but the character itself is still in running mode — it means that something has pushed the character up (e.g. player swiped up to jump) — and the monitor function just changes animation to going up one. If the character is falling, but its sprite shows go up sequence — it means that character just passed the top point of her jump, and started going down — so we change the animation to the landing one.

I still use time delays to have a touchdown animation on the collision event (because you can’t really manipulate physics of the collided object during the collision). But this approach is better because now most of the animations are decoupled from the physics-changing event, and the character just “reacts” to the external forces applied to it. Also, it allows for more variations in the animation sequence, and they are easier to control now.

Similarly, later I can implement in exactly the same way a special animation for when a character falls off a platform.