Polishing Player Movement - The *actual* time consuming part!

Hey everyone, Adam here with another update on my progress with Pik the Archon, my beat 'em up platformer game. Today, I'd like to share the intricacies of the polishing phase of my player controller.

There's actually quite a lot to talk about, I brought you 3 highlights regarding my personal experience with Pik. In case you're not aware, refinements usually take an overlooked amount of time in the development of a system. As a programmer, I keep noticing this more often than not with code too, not just visuals or design elements. Why is that the case? Probably because as you get closer to the final product, you start being more specific about your needs, once the groundwork is all done and you begin to envision the product further, or how you want to have it as "completed". I like to mention the 80:20 rule, meaning, "80% of your time goes into 20% of a feature". It's a bit ambiguous, but the 20% here is supposed to mean the "final sprint" -- sometimes adjustments and touch-ups you didn't think you'd need.

A very glaring gap in Pik's "fun factor" only became obvious to me when I sat down to play some Crash of the Titans again, one of my main inspirations. I noticed why I'm so fond of the way Crash performs his attacks: not only is he doing exaggerated swings, but he's moving forward! Having added this to the game, I quite like it over the previous, static versions. (I'm still new to animating so the animation is kinda quirky, but I'm working on it!)

If you boot a 3D platformer (specifically from the older era!), you'll also notice jumping is pressure sensitive, as in, if you just tap the jump button, you make a tiny hop, but pressing it completely for like 0.5s will accelerate you completely into the air. Unfortunately, the game engine I'm using, Godot, doesn't have the capabilities to measure how firm your key presses are. So the solution I came up with is, as long as you're holding the jump key, I add some vertical velocity till you reach a maximum. (Obviously, letting go will make you fall and you can't stack the velocity past that point.) This sensitivity is also a thing with simple movement on the ground. You have a few frames of "acceleration" to your maximum walk/run speed, meaning, if you just tap the right direction,  you won't move like 1 unit, you'll only move a tiny bit, let's say 0.1. And the code takes care of speeding up/down, depending on whether you're trying to move a particular direction or not.

For the last thing I want to show you, you should try a platformer for this too and notice what happens when you walk off a ledge and try jumping afterwards with a delay. Oh, you were able to jump?  This is called coyote time buffer. If you're somewhat familiar with programming, you've probably seen code where it just reads "if you're on the floor and you're holding the Jump key, you'll perform jumping". However, what you're seeing here seems to contradict it! Games often have a brief window of time after you leave the ground to still allow jumping. This makes the interaction more forgiving and accessible, especially if you're trying to reach another platform far away. The name of coyote time comes from the Looney Tunes character Coyote, who kept running off a ledge before falling. Not all games incorporate specifically the part where you're not pulled by gravity for a few frames, but the jump is very commonly possible.

The core logic is logging the last frame you were on the floor, and instead of using an "on floor" condition, you would see if that frame # + the time buffer is greater than the current frame #. For example, if I was last on floor on frame #100 and I have the time buffer of 50 frames, I can jump even if I'm mid-air till frame 150 ("current frame #").