Rough Animation Tests - Skid-stop

So now it's down to pixel animation basics. How, in this format, do you animate a classic "skid-stop"?

It appears to be about timing.

This is my surprised face.

In the above, my intent was to show the sprite skidding to a halt, flattening out as a result of that, and the tail flying past the sprite, stretching out to the right a bit, and then snapping back, like the ears on a cartoon dog flapping forwards when it skids to a halt.

The sprite skids to a halt, but then keeps going a bit. I need to make the halt more abrupt. The timing of the tail's expansion and inversion don't match up.

In the second video below, it's better. But still room for improvement.

The good: speeding up the braking helped.

The less good: need to work on the timing of the tail collapsing and following through.

It's too languorous, and the motion doesn't look linked to the bright lead sprite's sudden stop. The impression is not of mass moving with inertia, but a mechanical emanation.

The stop itself could be sped up a bit further, it's still a little slow.

The point where the tail starts going off to the right needs to be right as the bright sprite compresses and stops. Right there around row 14 or 15.

And the trailing lights need to shrink as soon as the brakes are hit and the sprite starts decelerating. So right there around 11 or 12.

You really have to go at this via trial and error, draw something that looks right, test it, and analyze where exactly it isn't meeting your vision. Writing about it here helps.

Animation Planning

So the plan is, create at least one intro (in this case "braking") animation, and one "acceleration" animation, each of which will have to also return an integer for how many pixels per frame the sprite is moving at the end, so that it can hand off easily to the standard "travel" code.

When the sprite reaches its designated target pixel in travel mode, it switches from "travel" to "scanner" mode. It then needs to run the intro animation, and then hand over to the loop animation, which will start and end on the same pixels as the intro and outro animations, to make life easier.

The loop animation will run a certain number of times (right now, we use a random number between two constant values defined at the top of the sketch), and then exit and hands over to the outro animation.

The outro animation will (again) start on the same pixel as loop animations end on, so will accelerate the sprite away, ending on a target pixel for hand-off to "travel" mode.

That's the rough plan, anyhow. We will see how it goes.