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