Blog Post 4, Sprint 4

    This sprint went quite well, and we did not stumble on any major issues. There was a concern pointed out by our professor which I will be going into detail and exploring near the end of this post. The majority of the work done on this sprint was improving upon existing assets. This ranged from everything from level, to scripts, mechanics, and even our entire scene loading system.

Because of this, there's no fancy level to showcase in this sprint. Despite not all our work being clearly visible this time around, take pleasure in knowing we spent the same amount of effort and work on changes that improve the game. 

The first of the major mechanics we changed was regarding the player movement. This was pretty scarry as we already had six levels done, so altering anything regarding movement significantly could prove to make some of the levels unplayable and in need of a complete restructure. The reason we were looking into changing the movement system in the first place was that many (5) of our play testers in our first digital prototype voiced concerns regarding the jump. The word the majority used to describe it was "floaty".

Example of the new movement system:

Tony mentioned the idea of increasing the gravity throughout the game. I loved it so I ended up roughly doubling the gravity, by changing its value to 2.25. I had to increase the jump force from its original value of 250 as well, to give the player the same jump height so they were still capable of complete all the levels. Most levels I changed the jump force to 650, but on the Aquatic Level and the City Level, I changed it to 725. And on the Lava Level, I made it 750. The reason I did this was to help scale the difficulty. Since the player now had half the airtime due to the increase in gravity, these harder levels became much harder. By increasing the jump force on the levels that had tight moving platform jumps, it helped curved the difficulty.

Even with this curve the Lava Level, level 4, proved to be far harder than we initially imagined. It's nothing to the point where it became unplayable or anything, but we made the choice to rearrange the levels to help alleviate this spike in difficulty. Since the two levels that originally came after it were arguably easier, we now reordered them to make the Lava Level the last level in the game. While we're on the topic of difficulty, I got Kylian to make a timer script, which I incorporated into all of the levels. Besides the 2 levels with rising dangers, none of the others really had a true sense of urgency. Well, now they do! You have 2 minutes to complete the level, if you fail to do so in the given time, the level and player are reset.

We also had a player state that some of the platforms on level 4 and level 1 were not the easiest to make out. I resolved this by giving an outline on the tree platforms and giving an orange emission square on the lava ones.

Lava level with the now increased difficulty and more visible platforms. Also note the timer that can now be seen in seen in the top right corner, which resets after level switch:

I did fine tuning across the game to mechanics like hitboxes and platform spacing as well. After the first digital playtest we had many reports regarding the lack of need to use the Dream Dash ability, especially early on. I re-did the first level, so it is no longer possible to beat without using the Dream Dash. They also commented on an issue which we noted all the way back on day one. Because the player is actually frozen on the X and Y axis, when they collide on the edge of a platform, they have no choice but to phase through it, assuming the player is telling the map to rotate. We have come up with and implemented three unique solutions to do this, but none of them have alleviated the issue. On the upside, the increase to platform hitboxes and increase of player gravity seemed to have cut the rate off this issue from happening by almost half. We had far less people mentioning this issue in our second playtest, though it is still sadly prevalent and easy to recreate.

I bring this bug up in particularly because it's our primary goal to solve for our next sprint. The short but game breaking levitation glitch it causes is rare but quite abrupt and very immersion breaking to the character. We have fixed it the point where a player seems to have a somewhat rare chance of encountering this issue if they don't have the knowledge, experience, and will purposively cause it. Be our current largest bug though, it's our top priority in what we want to squash before the game gets fixed. Much as last sprint, our next sprint we will not be adding any new content (potentially a ultra-short tutorial level), instead focusing again on improving existing content and mechanics, alongside resolving that one bug.

Updating velocity graph showing Sprint 1-5

Regarding work done this sprint, we complete slightly more points than we had the previous sprint, slightly improving our projected velocity, which is still currently projecting us to finish near sprint 5. As the lead, I will be continuing to be adding new cards, primarily focused on editing and improving preexisting systems as I do not want to be adding new mechanics this late into development, in order to push our projected completion time to the end of sprint 6 or further. 

We completed 21 points this sprint, with all of us doing 7 points worth of work, equating to about 1 a day. We need to be averaging 27 points in order to meet the velocity determined above or continue our current level if we want to finish around week 5.5 instead of 5. I hope to increase the points we do next sprint but will be cautious and weary regarding increasing effort and scale while asking our team how much work they have in other classes. As it was midterms in other classes that caused our dip in week 3. On do not wish to repeat an even because of upcoming finals.

Alright, time for the elephant in the room, ART! 

When presenting this week's sprint report to the class, I saw what I would have perceived as a forced smile appear on our professor's face when we switched to the slide showcasing the two gifs you have seen above in this post. I noted the reaction and knew I would need to confront it later on and continued with the rest of the presentation. This is a game design class with a heavy focus on prototyping, with no grade given for art. Our project very clearly has art, ranging from colors and materials, all the way to background props, which is in strong contrast to many of the other games in development by the other groups. When I ended the presentation and my groupmates had already walked off, I stood in the same spot as it was clear the professor was going to confront me regarding the art heavy pictures in the slides I presented. 

He voiced his concerns and skepticism regarding if we were using our time wisely, reminding us that art does not count toward our grade, and that we should be basing our time and work on the project's aspects that are listed on the rubric. He stated that he hopes our game would have a playable and functioning build by the time we turn it in. He stated these concerns in a manner which to me implied that our game was not fully functioning and that we had potentially allocated our time poorly.

I want to address clearly that we already had the majority of a completely functioning and playable build by the end of Sprint 1. With the scene switch and menu GUI, finalizing it, by Sprint 3. Our team has 3 scheduled meetings a week, and we are very thoroughly communicating outside those times as well. The art we have in our game was going an unnecessary extra mile and we did it knowing it was not worth any credit, because we were enjoying making our game. Art, if present at all, was only added after we already spent the allocated time and effort to thoroughly complete the listed cards. If I'm going to spend 5 hours making, playtesting, and balancing a level, I'm also going to spend the measly 10 minutes required to color it in, and additional 10 to make some basic props.

I understand the concern that it might be inferred we are prioritizing art. We aren't, and if we do end up adding art anywhere, it's after everything else regarding the component has already been completed and finalized. We are not dividing or poorly allocating our time when doing art, as we do it in our own free time as a passion project, once we have already completed the work needed to finish the card. The time we have spent on any art in our game is minimal and insignificant, with no points whatsoever being allocated in our backlog towards it. The free time we put into the game to make it look visually appealing does not at all conflict with our mandated effort we agree upon in sprint-offs for the work we plan on completing.

Regardless, it became clear to our group that having any art in our prototype seemed to of raised a legitimate level of concern in others regarding the quality, legitimacy, and functionality of our entire build; so, we added a strict policy not to add any art going forward for the remainder of the project. Hopefully this explanation and our new policy has alleviated any concerns that our minimal art might have caused.