On "Bouncy" Animation

On some occasions people have commented on the character animations of the original Pullfrog. Saying how they look very bouncy, and asking how many frames we were using to get them to look so smooth. This used to throw me off-guard because the answer is one frame, or more like, as few as I can possibly draw.

https://media.amano.games/devlog/bouncy-animations/01-bouncy.gif

This is probably something that’s been talked about a million times, but here’s my take on the subject. To me, character animation is not about how smooth the movement is, or about trying to get in as many frames as possible to really make the character feel alive. It’s quite the opposite actually. I want to convey the action in the least amount of frames possible because I’m lazy, animation is a lot of work, and most people don’t really care or notice. Let the player’s mind fill-in the blanks. Well, those aren't the only reasons. See, I’ve worked in animation before, so while economizing is important to get work done, I like the challenge of getting an action to come across with very few frames. It feels elegant. It feels like I solved a problem.

So why DO these animations feel “Smooth” or “Bouncy”?

The most important thing to keep in mind are the key poses of an action.

A key pose is THE most essential frame of an action that the viewer needs to see. That single pose should be clear enough, that even without in-between frames the viewer knows exactly what action the character is performing.

https://media.amano.games/devlog/bouncy-animations/02-bouncy.png

Another Equally important decision, is choosing which poses you want to emphasize in order to get that reactive feeling when a character interacts with the world. So in the case of Pullfrog, I wanted to really emphasize the jumping part because, well… frog.

So I determined that each step pf the jump needed to have an impactful pose. These steps being:

1- Going UP  (Exaggerated stretch pose)

2- Coming Down (Frog curls into a ball)

3- Landing (Super Squash)

A simpler version of this goes into the walk an idle actions. Since I’m working with a n 8x8 grid there’s not a lot of room for detailed poses so the walking cycle is just a body squash and the legs opening and closing in alternation more like a “shimmy” than a walk, but it works!

So it’s not about how many frames I’m using rather, what actions I’m deciding to pose.

All this talk about economizing on frames does not mean that I don’t embellish my animations with extra frames for smoothness. I might if I can afford the sprites and have the extra time. Which is exactly what I chose to do in Pullfrog 2.

https://media.amano.games/devlog/bouncy-animations/03-bouncy.gif

Since the Playdate doesn’t really have any limitations to the amount of sprites, I decided to get a little fancy and add some extra frames to every action. These are just simple in-betweens where I’m using some animation principles like smears and anticipation to convey fluidity in movement. I also don’t want to over animate because this is still a game and reaction times are still more important than animations.

https://media.amano.games/devlog/bouncy-animations/04-bouncy.gif https://media.amano.games/devlog/bouncy-animations/09-bouncy.png

Another advantage I now have is that I'm making the character on a 16x16 grind instead of 8x8 so that gives me a lot more room to really explore the strectchiness of the character.

https://media.amano.games/devlog/bouncy-animations/05-bouncy.gif https://media.amano.games/devlog/bouncy-animations/10-bouncy.png https://media.amano.games/devlog/bouncy-animations/06-bouncy.gif https://media.amano.games/devlog/bouncy-animations/11-bouncy.png https://media.amano.games/devlog/bouncy-animations/07-bouncy.gif https://media.amano.games/devlog/bouncy-animations/08-bouncy.png

Anyways. Once we start adding new mechanics and movements I’ll post about them too. And maybe talk about some cheating techniques to convey anticipation without hindering reaction times.

That’s all for now. Thanks For reading!

Comments

Other Posts

Archive

You can subscribe via RSS or follow us @amanogames_

Making a pinball game for Playdate: Part 07, the debugger

Making a pinball game for Playdate: Part 07, the debugger

Searching for a debugger on Linux

Making a pinball game for Playdate: Part 06, the profiler

Making a pinball game for Playdate: Part 06, the profiler

Learning how to use a profiler

Making a pinball game for Playdate: Part 05, the spatial partition

Making a pinball game for Playdate: Part 05, the spatial partition

2 Bits image formats.

Making a pinball game for Playdate: Part 04, the image format

Making a pinball game for Playdate: Part 04, the image format

2 Bits image formats.

Making a pinball game for Playdate: Part 03, the first level editor

Making a pinball game for Playdate: Part 03, the first level editor

How did we choose our first level editor for the game?

Making a pinball game for Playdate: Part 02, the physics

Making a pinball game for Playdate: Part 02, the physics

Let's talk about physics.

Making a pinball game for Playdate: Part 01, the language

Making a pinball game for Playdate: Part 01, the language

Welcome to this December adventure, where I will try to write about the process of our last game, Devils on the Moon pinball. Today I will talk about our choice of programming language for the game.

Let’s finish this

Let’s finish this

We are back working on Pullfrog! What happened?

Let's talk about Don Salmon

Let's talk about Don Salmon

Don salmon, a new platforming game made in Godot and a small update on Pullfrog

Spooky eyes and level editors

Spooky eyes and level editors

Last year we made the decision to take a break and focus on a spooky game around the spooky season.

This kills the frog

This kills the frog

After rewriting the physics system for the third time, it was time to start working on more fun stuff. The frog death system™.

On starting a game

On starting a game

A couple of things I would recommend when starting your first game on the Playdate.

How to correct a corner

How to correct a corner

There are many techniques that you can apply so that a platformer game feels good. One of those is corner correction.

The collision stair case

The collision stair case

As stated on the previous post, updating all the pieces all the time was a bad idea. We needed to figure out a way to update only the ones that needed to be updated after another block got destroyed. The quick and dirty solution was to check all the pieces inside a bounding box on top of the piece that got destroyed.

About Amano & the collision conundrum

About Amano & the collision conundrum

So, a couple of months back, Mario and I were happily working away on The game, finding out the workflow and working out the kinks of developing for the PlayDate. We laid down the main mechanic, blocks were falling and colliding correctly the character was moving alright but we were doing everything on the simulator, NOT testing on the actual device. so when we decided to take it for a spin…  it crashed.

Pullfrog postmortem, Long Live Pullfrog 2-Bits

Pullfrog postmortem, Long Live Pullfrog 2-Bits

So towards the end of the year, Mario managed to get his hands on a Development console for the handheld "Playdate" and we decided to attempt do make a second version of Pullfrog, this time featuring a playful little crank and seemingly less restrictions except for the apparent ones like the black and white color of the screen. Oh the naivety.