Skip to main content

CAGD 370 Blog Post 5 - Final Sprint and Postmortem

  The Final Prototype is officially done! And this final sprint has definitely been the most intense yet. While not perfect, I’m very happy with the game that me and my team have made, and I feel a lot of motivation to start a brand new project! But before I get ahead of myself, it’s a great time to reflect on the last two weeks and this project as a whole.


To start off our final sprint, I once again made adjustments to the pole vaulting. I made the impulse of the vault scale with how close you got to the pole, which meant that not only could the player not get an immense movement boost from a standstill, but also that there was now a “sweet spot” to aim for to get the most vertical height out of the vault. To help players seek out this sweet spot, I also took the time to create a charge-indicating progress bar next to the player that would fill up the closer they got to the sweet spot.


The bar progressively fills as the player approaches the sweet spot


After this, my lead designer asked me to re-implement the wall vaulting that we had in the original iteration of the pole vaulting mechanic. This would be tough, because it meant that I would have to sort of frankenstein the old and new vaulting systems together, but it would also greatly increase the opportunities for variety in level design and player skill expression. Thus, I set out to bring the monster to life.


I began with an if-statement that would use the old vaulting system if the player was airborne, and the new one if they were not. This proved to be a good starting point, but still had some gaping flaws. For one, it was possible to use the old vaulting system by just jumping before planting the pole in the ground, and the issue of infinite wall riding was reintroduced. To fix the “floor wall vaulting” as I decided to call it, I added another condition that the surface normal must have a Z value that is not greater than 0.1 (negative values were made positive to cover those cases). 


The next issue to tackle was the infamous wall-riding that had plagued the wall vaulting mechanic its entire life thus far. My first solution was to implement a cooldown on the wall vault, something short like 0.2 seconds that would hopefully give time for the player’s momentum to carry them too far from the wall to vault from it again, but any cooldown I tried was either too long to the point of awkwardness, or too short to solve the issue. My next and final solution was to store the surface normal of the wall the player last vaulted off of, and allowing the player to wall vault only off of a surface with a different normal vector than the one they last vaulted from. This still allowed for many wall vaults in quick succession, between two different walls for example, while also preventing the dreaded infinite wall-ride. The stored normal value was also erased after 1 second, so that if the player wall vaulted, landed on the ground, and tried to vault again off the same wall, they could.


Now with the wall-vaulting complete and ready to go, the majority of my work for this sprint was completed. All that was left was to assist the other team members and finalize the project for building!


Reflecting on the project as a whole. I feel like a lot of time was lost to github, with merge conflicts that would take up to two hours to solve, these issues ate away at our time, especially during the final weeks. Being the programmer, and the most experienced with github, it usually fell upon me to solve these problems, but I had little experience with github myself. Over the course of the project though, by necessity, I got a lot better at solving and preventing these merge conflicts, and I feel much more experienced in both keeping good github practice and untangling things when issues arise. Despite all the frustrations it took to get to this point, I’m now glad that we had struggled so much with github, because I wouldn’t have improved so much without those challenges. 


I think if the project were to continue, I would uninstall github desktop entirely and start working exclusively in the github console. I don’t think that there’s anything wrong with github desktop, but I think that by forcing myself to use the console I would develop a better understanding of github as well as expand my toolset when it comes to problem solving with it. This final sprint provided both the most frustrating challenges and triumphant victories yet. And the teamwork and camaraderie that my group experienced in the last couple days made me wish that we had more time to work together on the game. All in all, making the prototype for Thunder Vault was a great experience, and I can’t wait to jump into my next project, whatever it may be!

Comments

Post a Comment

Popular posts from this blog

CAGD 370 Blog Post 1

  In CAGD 370, my new group and I have just started working on a new project currently titled Thunder Vault! It’s a 3D Platformer where the player has to rely on their pole vaulting skills and momentum-based physics to clear levels as quickly as possible! Andrew Kostlan is the Lead Designer, Anish Neupane is the Producer, and I am the Programmer of this project. In our first 2 week sprint, We’ve set up our backlog, developed and tested our paper prototype, and created our Unreal Project File and set up Github Version Control from within the project! As the Programmer, I was the one to set up the Unreal Project this week. I chose Unreal Engine version 5.5.3 since it’s the latest release, so that we’ll have access to all the latest features during development. The next thing I did was set up Git Version Control within Unreal. I recently purchased a new computer, and didn’t move over anything from my old machine so that I could have a fresh, uncluttered start. A consequence of this th...
Post a Comment
Read more

Treats and Trials: Postmortem!

  Game Info Group Number 2 In Treats and Trials, Players build their own haunted houses out of trap and candy cards. Then, the exploration phase begins and players explore each other’s haunted houses by turning over cards! Candy cards give you candy pieces, but trap cards raise your fear level and can force you to leave without collecting all the candy! The Player with the most candy after three rounds is the winner! Target Audience: Director, Explorer, Competitor, Achiever The Pitch This time around, we were pitching our own original game ideas to the class! This assignment was due on halloween night, and since halloween was fresh in my mind I was thinking about halloween games that I could create. I recalled how when I was very young, my grandparents liked to set up a haunted house in their front yard for trick or treaters to explore. (It terrified me when I was 3!) With this on my mind, I thought of how I could bring the experience of exploring a haunted maze to a card game, o...
Post a Comment
Read more

CAGD Blog Post 3 - Thunder Vault Kinesthetics Playtest!

  Sprint 3 of Thunder Vault’s development has ended! This sprint has been a pretty exciting one, with our first digital playtest, some good feedback, and a lot of big changes to come! Starting with the playtest, we had the player set up in a simple level with some obstacles to vault over and walls to bounce off of. I wanted to give the player some kind of goal, so I made an enticing tower in the middle of the level that required 4 increasingly hard jumps to ascend. This proved pretty effective! All of the playtesters that I watched tried multiple times to climb the tower, although I think I was the only one who was able to reach the top sadly. This indicated to me that while the mechanics felt comfortable to me, they were not nearly as intuitive for our playtesters. We also lacked any kind of tutorial or how to play section, meaning we had to explain the controls to our testers verbally. I would like to somehow design our next level in a way that encourages the player to explor...
Post a Comment
Read more