I wish I could type this dev log with an accompanying playable beta build of Bike Un-Friendly. Unfortunately, my time this past sprint was mostly used up by a different game project where I work as an artist on a team. Long story short: I had to create environment tile sprites as part of a mod for a pre-existing game. Because the game has pre-existing requirements for its art assets, my environment sprites had to match them, and the requirements were pretty extensive and unlike what my game art tends to be, so I didn't have a  good idea of how much work would they would take to create. As a result, I underestimated the amount of work I would need to do, and ended up spending too much time on those tile sprites. I suppose that's expected when one of the learning goals is to work within sprints and a scope. I still have more environment sprites I need to create, and I'll have to cut corners too, but at least I have a better idea of the workflow.

Still, I was able to work on Bike Un-Friendly for a couple days, and I made a valuable discovery that is going to change a lot of the design of my game.

Instead of trying to work on the other aspects of my game that is required for it to be a complete game -- a main menu, a game loop, scoring system and high-score page, a pause menu, art assets, and sounds -- I continued to work on my game's core mechanic: pedaling. The whole game depends on that mechanic; I can't properly assess my levels and obstacles when the player mechanics are still subject to change. Especially following feedback on my "Programmer Art" build, where a player told me the pedaling felt awkward to control, or like it was better suited for a snowboard and not really a bike, I knew I had to get this mechanic down and done.

While I wasn't yet ready to adopt suggestions for separating the steering and forward movement that the pedaling mechanic marries, I did agree that the feeling of pedaling in my game felt awkward for what was supposed to be a bike. I decided I would continue working on the original concept for pedaling until I reached a point where I could decide for certain whether or not to drastically change that mechanic.

I began with addressing the feedback of the awkward movement while pedaling; specifically, the large lateral movements that would accompany the desired forward movement from pedaling. I hoped the smooth damp on the horizontal acceleration would solve that issue, so that unless the player is holding down a pedal key, they will only accelerate in the respective horizontal direction a little bit, but either the player was moving too fast horizontally while pedaling, or steering felt too sluggish.

I duplicated the player test script and started a new iteration that would make steering and moving forward more of a  distinct decision. For this iteration, I decided to reintroduce friction into the physics materials of the floor and player objects. Basically for this iteration, when a pedal button is pressed, the bike would be slightly impulsed laterally in the respective direction of that pedal for one frame, and would stop very soon after because of friction. Simultaneously, a boolean activating a steer lock would be engaged to prevent update calls for steering in the pedal's respective direction. The lock would disengage only when and as soon as the player stops holding down the respective pedal key. As a result: pedaling would still have some lateral movement, and steering could only happen once a pedal is pedaled -- meaning, the bike is propelled forward and laterally for one frame -- and the respective pedal key is pressed again.

In this new iteration, I also finally implemented the sharp steer mechanic, which uses a button combo, and I got rid of the animator events, and had all movement function calls occur within the script.

Before:

After:

The result:

This new iteration seemed promising. Steering was no longer getting in the way of moving forward, and moving forward felt more responsive and intuitive.

Still, more bugs were introduced with the sharp steering.

I don't want to bloat this dev log explaining each of the bugs and my solutions or attempted solutions and further iterations on the script, so I'll summarize it by saying I was able to patch 1 of 3 bugs that sharp steering introduced -- all of which have to do with the button combos -- and in the process, I simplified the animator logic to one parameter per animation transition, and shifted the logic to be handled all inside the script. The bug I patched isn't shown in the GIF, and the solution is showed instead -- where the "bike" is sharp steering before steering the opposite direction -- but the other two bugs can be seen.

All this to say, that in the 5th iteration of the player script, while trying to patch these other two bugs, I accidentally created a broken script where the player was only ever in a state of steering left or right, and could only steer left or right.

When this first happened, I was disappointed for a second before finding myself idly ping-ponging the "bike" against the walls on the side. I then started imaging obstacles slowly moving in the direction of the player, and I challenged myself to keep a still position by rapidly steering left and right. I realized this mistake was actually more fun to play with than my original design. 

I thought about why this accidental mechanic felt better than my original design, and I think that is because of the rhythm it introduces. When I imagined scarce obstacles in the play space, I noticed a slow and constant beat whenever the bike would move from one wall to the other. When I imagined an obstacle with a challenging narrow opening, the beat would suddenly pick up as I had to challenge myself to keep a still position while rapidly pressing the left and right pedal keys. Then, when I imagined an easy to dodge obstacle, I could just press a pedal key or two, let go, and watch the bike steer on its own through an opening. The (imagined) obstacles demanded a percussive beat from the player that corresponded to the level of difficulty they posed. There seemed to be an intuitive sense in the action of "pedaling" with what was happening in the game. At least, from what I imagined.

I decided to ditch my original pedaling mechanic for this new one I happened across. The action in this new version may be more abstract from pedaling in real life than my original version, but it definitely feels closer to the biking experience where the rider could cruise along an arch to avoid an upcoming easy obstacle and enjoy the brief lull in the street, but will have to expend more effort and concentration during moments when more dangerous and challenging obstacles present themselves. In my original version, the player would at least always be tapping the left and right pedal keys constantly at a relatively quicker pace to keep themselves from falling behind, leaving hardly any room for "breaks" in the game's level's pacing.

Other benefits include:

* Less finger fatigue, which was a piece of feedback in the game's prototype.

* Cut mechanics like having a constant velocity pushing the player backwards, and braking.

With this new pedaling version, I'm more confident I'll have a solid core mechanic done soon, and I will begin working on the other aspects of my game.