My goal for this build was for programmer art; as in, not polished or final art assets, just some placeholder sprite animations to demonstrate the game's functionality.

For this build I focused entirely on the player controller and movement; particularly, the pedaling mechanic. By the end of this sprint, I didn't even get to complete the pedaling mechanic, but I at least managed to have something ready for others to play with and give feedback on.

My first error in working on the player character was trying to create the components of the player character while creating the game's architecture. In other words, I was trying to create a manager script that would allow other separate scripts responsible for individual mechanics to communicate with each other without needing references to each other. The separate scripts would include one for handling inputs, one for updating the animator, one for manipulating the rigidbody, one for the player's health, and one for storing variables that would be used to initialize the player character object. This method of architecture depends on something called Delegates, which are basically a variable data type that stores functions. Here's a little illustration to show what I was thinking:
Mechanic Scripts may have Public Functions and Public Delegates that the Manager Script has access to. The Manager can put Mechanic X's function into Mechanic Y's Delegate, so when Mechanic Y decides to invoke their Delegate, the function in Mechanic X gets called. This is a method of Architecture meant to relieve spaghetti code. I've used this previously in a different game that had spaghetti code, and it has made working on the game's mechanics much easier and straightforward.

While architecture is definitely important, I was quickly overwhelmed by the many different scripts and I was unable to continue working on these things simultaneously. Merely trying to test the relationship between different mechanics became such a hassle. I decided to focus on getting everything working first on one script, which I called PlayerTEST, and later duplicated and continued working on as PlayerTESTV2.

From here, I was finally able to start working on the inputs and combos, the movement, and the animator and animations.

Like I said, I didn't get to complete the entire player controller -- particularly, the sharp steering and jumping -- but I was able to get the pedaling and steering down. The first version looked like this:

I didn't like how the steering sprites would appear so soon into the steering, how they would continue appearing even while the X velocity slowed down, and how the beginning frames couldn't even be noticed. The box looked like it was sliding and slipping, not steering.

I replaced the steering sprites with the sprites of the left and right pedals being down, to see if the box looked more or less like it was steering instead of sliding:

It looked better, but only because now the steering sprites weren't there to make the box look like it was slipping suddenly.

The animator and the logic behind these animations relied on the Status of the bike (Idle, Pedaling, Steering, Sharp Steering) and factors like whether or not the pedal keys are down or which pedal on the bike was down.

For example, Player_Idle_Left would play if the StatusInt == 0 (Idle), and if LeftPedalDown == True. Because of these parameters, I could not easily control how or what sprites and animations appeared in between different states or statuses.

I wanted different sprites to appear during steering, and for them to depend on the player character's X velocity. This way, the appropriate sprites would appear relative to the player character's steering. To achieve this, I had to use a Blend Tree that would rely on a parameter that received the player character's X velocity, called HorizontalSpeed.

Mostly just the Steering parts of the animator had to be redone.

The blend tree contains Animations that each consist of one of the individual steering sprites.

Now the player character's steering animations are granular and reliant on the actual X velocity float values instead of a status and a bool.

The player controller still needs plenty of work, including the animations and mechanics, but at least now I know what parameters and logic to use to get a better animations from my sprites.