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

CAGD 370 Blog Post 2 - Thunder Vault Movement Prototype V1!

  The game has made a great deal of progress in our second sprint! With the unreal project and gthub set up, it was finally time to start programming the movement. I started with the Unreal Third Person Template, because it comes with a functional player character using Unreal’s Character Movement Component, as well as a nice level to play around with the movement. I began by tweaking the parameters of the Character Movement Component. The Lead Designer wanted the player to build up speed on the ground that can be translated to the air using the pole vault, and so I raised the max speed on the player and lowered the acceleration, which made our character control not dissimilarly to how Sonic The Hedgehog might. The next tweak I made was greatly lowering the jump height. While we still wanted the jump to be an option, we want players to rely heavily on the pole vault for moving vertically. With the basic movement configured to how we liked, now it was time to start with the pole...
Post a Comment
Read more