Blogpost 5, Postmortem

    Sprint 5 concluded a week ago, and we were fortunate to present our completed prototype to our class a few days ago. We have yet to receive feedback from our classmates on the written forms, or a grade from our professor, but I believe we were very successful in what we had set out to do.


We had completed Bedtime Climb with the majority of what we wanted in the game. Features and levels had to be scrapped due to time restraints, but the completed prototype thoroughly showcases the main mechanics and potential Bedtime Climb could have as a complete game

As a team, for the most part we did all levels of work, as in we all did some level of scripting, UI, or modeling; though we still had our specialties. I mainly focused on level design, modeling, and the rotation scripts. And as the lead, translating my vision to the group for what I wanted the game to be. Tony also did a lot of modeling, completing the other half of the main levels and the scripts regarding vertical movement. Kylien primarily did the scripting, the Status UI, and the tutorial level.


Regarding how many levels we originally planned, we wanted to at least have 3. Our goal was to increase it based on how fast we were able to complete the previous levels at a quality we found acceptable. We eventually had a total of 8 unique planned levels, but ended up scrapping the Space and Mineshaft level due to time restraints. From day 1 we also had a concept of a "Nightmare" mode. In which you would replay a level after beating it but at a high farther difficulty. Instead of starting from the bottom and going to the bottom, the level would be inverted. 

This was by far the largest content idea that we would have eventually of scrapped, and was in strong consideration all the way up to Sprint 3. Once we had 6 levels it no longer made sense to double them, and since we scrapped having enemies for the most part, the Nightmare levels seemed even less useful. It would also take a large amount of effort from all of us, and we decided the pay off simply was not worth it.


Lets talk about the most unique part of our game, the movement system:


The jump was originally nothing special, but to resolve some glitches later on, in sprint 4 we changed some major factors. We increase Unity's gravity from -9 to -20, and doubled the jump force accordingly to keep the same jump height while giving the player far less air time. We also ended up giving a constant downward velocity to the player at all times, this resolved a levitation glitch that would occur on moving platforms due to a lack of player updates.


This gif looks super simple, and well, that's because it is. This single script is responsible for player "movement". The secret to our movement system is that our player does not actually move on the X or Z axis. Instead the entire map rotates around a stationary player. To help hide this, we also added rotating backgrounds along with moving props to help sell the illusion.

Having moving objects in the midground, like clouds, fish, or witches, helped greatly in giving the level a sense of depth.


This was very important because at the end of the day, every level was really just a stack of cylinders being encompassed by a large cube. We don't want the player to have that perspective, so it was important to vary terrain and colors when plausible to make the level seemed for fleshed out, despite still being a prototype.

This brings up a important argument, "why does your game have art and props if it's meant to be a prototype?". Because of our unorthodox movement mechanic, which has the player not actually moving, its the background that illustrates a sense of movement. Even with the props, if all the objects were grey, it becomes very apparent to the the user that they are not moving. If the player becomes aware that they are not moving, the whole illusions that they are playing a platformer is gone. Level 1, its props, and its background, was completed while being completely grey, and our internal playtesting showed that it simply did not work.

Here's a example or a rotating map, midground, and foreground used on Level 1 to fake player movement. You might notice the red player in the bottom right corner, completely stationary:


Once you have a fixed camera on the play though, the illusion is sold, and does a great job of making it look like it is the player who is navigating through the map, and not the other way around


We also wanted to give the player moment particles that would appear on the left and right to further this notion as well as slightly rotate the player based on their direction, but the idea was scrapped when it was considered too correlated too art for a prototype. Regardless, It's my main regret, as I believe it would perfected the movement illusion. In the future I would of stuck to my belief that this type of "art" would of been very beneficial to prototype, and would of followed through with making it an addition.

This biggest issue we hit was near the end of the final sprint. It was based on a member wanting to make the fireball mechanic higher quality. In fact the script to make it better was fully completed and present in a version of the game.


For whatever reason, this script failed to work once we compiled all our separate versions. We spent a hour so trying to fix it before I was ready to compromise the fireball and make it simpler. The member who originally made the script was of course frustrated that his work on the fireball would not make it into the final build. Because of that they insistence that we continue to try to fix the issue. We spent a additional 6-8 hours trouble shooting this singular issue before I made the executive call as the lead to scrap the mechanic entirely, and make the fireball act as lava. This frustrated all of us of course, especially the member who originally made the fireball mechanic, but it a choice I was forced to make due to time constraints.

In the future, If I again the lead on a project, I think I would of been more stern and made the call far earlier, it wasted a significant amount of time and caused unnecessary stress for a feature that wouldn't of even changed our grade, let alone me noticed by the majority of players.

To conclude, development across the 5 sprints went smoothly, we completed 122 points over a 10 week period, and our final prototype was well received by the people who played. It was a success in hitting the categories on the projects rubric, but also seemed to genuinely make the people who played it happy, which in turn made us, the developers, feel very proud and accomplished with the work we had completed and presented.




 

Comments

Popular posts from this blog

Blog Post 1, Sprint 1

Blog Post 4, Sprint 4

Blog Post 3, Sprint 3