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 373 Blog Post 4

This sprint I was assigned a modular set to create the basic interior rooms out of, with three different textures for the walls. (a Square Brick Texture, a Cement Texture, and a Metal Wall Texture) The actual modeling itself was as basic as it gets, I just made a few different shapes and sizes of wall along with a doorframe, with a couple floors and ceilings to complete the set. The interesting stuff this week was the textures, all of which I made in designer! The brick texture was probably the most complicated, and the one I’m most proud of. Starting with a brick generator, I used some gaussian spots to add some variance to the shape of bricks (using the spots to “cut out” chunks of the perfectly square bricks) and that worked pretty well! After that, I used a grainy looking noise map to fill in the black part of this mask to add in the noisy texture of mortar between bricks Next, to add some color variation to the bricks, I used a flood fill node, which was able to identify all the...
Post a Comment
Read more

Video Game Production Sprint 1

  After a long time spent away from Unreal Engine, I’m getting my hands dirty once again as a programmer for the Kill Everything in Sight team! KEIS is an endless action FPS roguelite where you play as a killer robot tasked with exterminating the remains of the human race. Despite your incredible movement and combat abilities, you are severely limited by a timer ticking down during the entirety of your run. Killing enemies will add precious grains of sand to your cruel hourglass, so the player must focus on speed just as much as precision! I was brought on the team as a programmer, and I started off very nervous since it's been a while since I last programmed in Unreal. On top of that, my first task was to create the foundation of our enemy AI, probably the most critical gameplay element after the player and level design, and I haven’t touched AI in Unreal outside the absolute basics! However, I was determined to make my team proud and confident in my ability to learn quickly...
Post a Comment
Read more

Idle WitchCraft Sprint 4

  This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line. Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm! This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate inf...
Post a Comment
Read more