Sprint 3: I'm not a fan, but the kids like it.

 What a playtest! This sprint was a big come-to-jesus moment for the team; essentially, the focus was on tightening what we wanted from the game and develop towards something meaningful. We acknowledged what wasn't working and what was too vague and attempted to remedy it. We met three days in a row, drafting new cards, figuring out what we needed, and focused on strict prioritization. Everything we needed for the playtest was given its own separate category and prioritized first as a 'mini-sprint'. All of these were completed in time, and it paid off. 

 

The mini sprint label we used to tasks that needed to get done before the playtest.

My focus for this sprint was to further tighten up the controls, revamping everything so that the player felt good to control. I made it so that the fruit always moved in the direction of where the camera pointed, making it feel more organic. I set up the camera to pan in and out when the player was ready to jump. I also added a 'slam' that allowed a player to come down to the ground with rapid force, keeping them from overshooting their jump. Finally, I tried to code in a launch arrow to show where the player was going to go This was.. Less successful. I believe that the reason why the arrow turned into, as per my github commits, 'a giant piece of shit that doesn't fucking work', was because I set it up as a child of player, which meant I was working within the players coordinate space and inheriting its rotation, which is bad news since it:

 

1) Made rotation math way more complicated than it needed to be since it was using the players coordinate system while being pointed by the camera's coordinate system, effectively turning a straightforward UI element into some complicated linear algebra nightmare extremely fast.

2) Inherited the players rotation coordinates (our player is a ball moved through AddForce() calls, which means its ALWAYS rotating), which meant that any effort to turn it involves fighting whatever the hell the player ball is doing at that particular point in time.

3) At the time our player camera had a not insignificant amount of drift, which means that between player controller rotation and the camera jiggling around everywhere like it was trying to ape the Blair Witch Project's cinematography resulted in a distracting, inaccurate, and misleading arrow.

Some tweaks to the movement and camera controls.

So if you see a big red point of failure swirling around our grapefruit in any of these gifs, that's because I made a relatively small screwup and got myself into progressively larger screwups trying to keep the small screwup in.

 

Despite my apparent best efforts to kneecap this game, the feedback we received from the game was that it overall felt good to play. The rolling felt smooth, the jumping felt great, and we were left with a few criticisms that were not an issue to implement. 

First was that the axes felt inverted to players. This was a subjective issue. While me and Andy were playtesting the build, it felt great to us; it made sense. When other players got their hands on it, the response was mixed. Some people felt that the camera controls were totally inverted, some felt like only one axis was inverted, some people thought it was fine. It likely depended on the types of games people played beforehand, but either way, it was a sticking point that we didn't want players to 'just get used to'. 

The code added to support menuing and axis inversion.

Camera speed was also a major sticking point; people felt like the camera speed was too rapid on the horizontal axis and too sluggish on the vertical; another quality of life thing to fix. 

 

The controls were a little uncomfortable too. The way we mapped the controller, players had to use an uncomfortable crab-claw grip on the right side of the controller to jump, which obviously felt bad. A suggestion was to change the switch to jump mode as a hold button on the left trigger, allowing players to cancel mid charge if they felt like it; our previous system made players fully commit to each charge. 

 

Finally, there was no useful visual feedback for charging; a charge meter was probably the number one most requested thing. 

 

Overall, this seems like a lot, but the group (and myself) were really pleased by the feedback we got. Nothing with our overall control scheme was broken, nothing felt bad to use. Buttons needed to be switched around, UI needed to be created, and more feedback needed to be given. That means we did something fundamentally right; we had good bones and all feedback was to essentially polish and give people more information. My job for the sprint was to respond to the player feedback.

Camera tweaks were the first thing solved; I created a rudimentary menu system and an option to invert both the X and Y axes in a settings menu. I tweaked the camera, resolving a well-known bug with cinemachine that got rid of camera jittering and adjusting the speeds so the vertical axes did not feel so sluggish. Finally, I changed the control scheme, binding a hold button on both action maps to left trigger, which turns launch mode off and on. Further troubleshooting was needed to keep players from switching to launch mode midair and to make sure that they didn't have to swap. 

I did not have the time to add a charge meter, but arriving at Sprint 4 with a nearly finalized movement controller feels great. It gives me plenty of space to work on coding hazards and puzzle elements that can be playtested with something that we put our best effort into. Now we know exactly what our player will move and act like, which is the one thing we need to create levels with any kind of precision.

I was also tasked with creating the burndown chart for this sprint, and seeing the results made me a little worried. Our velocity overall is very, very, low. It feels bad seeing where we're at versus where we need to be. We may have to leave a lot on the table in order to release a polished game, and it seems like my groupmates can't stop getting sick or finding reasons why their work can't be done. I am determined to do as much work as I can in order to make this game work.