Ludum Dare 50 entry at here.
Play in the browser itch.io.
Game source code at here.

Froggy Thunder: Toad-al Recall is perhaps our most polished game jam entry to date. There were some flaws, and this is represented by our performing worse in the final rankings than Ludum Dare 49, but I hold that artistically and technically, it has the most to show. In Ludum Dare 48 we explored the use of GANs for generating images. Although I’ve been pushing to trickle more and more machine learning into each game project, this time I decided to not let it be a driving factor for the game design. Instead, for this Ludum Dare I ended up focusing on some technical animation skills. Something I haven’t had a change to mess around with for a while was procedural animation. In my head procedural animation just makes sense, especially when you don’t have an animator on your team and you are under time constraints. If done right, it can provide free imersion and good replayability value by removing the repetitiveness of things like character movement.

I’d seen a few examples aroung the indie game community for how to do procedural walking motions. I really enjoy the caricature of the walking animations in the Sok Pop games. Looking at their animations, they seem to involve a kinematic layer that positions the feet around a supporting convex hull and then a physics layer that tracks the kinematic animation. This is the approach I went for. The rules were that if a character’s foot was too far from its center of mass or if there was no supporting convex hull below the character, a new position was reflected across the character’s facing direction. A Bezier curve then smoothly transitioned the foot to the new position. To then make the character physically interact with the environment, I added a physics layer on top of the kinematic motions of the foot. This used a PD controller to track the motion of the foot, meaning that if an object was between the foot and the new target, the foot would be stopped.

The nice thing about the way I set up the motion controller was that it was generalizable for arbitrary numbers of feet. To make the monster, I then just changed the foot parameter ot 50, scaled up some of the parameters related to randomness and distance of the foot placement, and I had a pretty convincing tentacled monster.

There are some flaws with this approach, such as the character’s physical state not feeding back to the kinematic motion. This means the character can’t do things like be pushed over. Also, when the new positions of the feet were selected they don’t change until motion along the Bezier curve has completed. This means that if the character is moving very fast, the legs will lag behind as it moves. The solution here is to pin the target positions of the feet to the reference frame of the character so that the foot motion curve is stretched to accomodate for the forward motion. Something to work on next time.

A common trend that is showing up in my games is the use of physics. I truly think for small game development teams, utilizing physics is a great way to shortcut development time and introduce game feel without needing a dedicated artist or to spend extra effort on VFX.