Sprint 2 370 Video Game Development

Sprint 2

Development for sprint 2 has been a huge learning experience for, me to go from paper concept to real working concept. Getting to work respawns was a fun venture, tracking large amount of float values for different uses and also making sure it works not for me but as a tool for my lead to design with was a new process. I was thinking ahead of time for what floats would be public for the lead to use. Things like speed values but also respawn vector settings and remembering to find what would be needed but hide away things that would just clutter up space and make thing difficult to edit. 

Cards

Managing cards was process that I had to swing into, managing to get myself out of a finish 1 thing then move to the next mentality I discovered halfway through the sprint I had been focusing on other classes and had no work done for my cards yet because I had been completing other assignments. Managing my time more effectively to have time to get smaller cards out of the way while preparing for the main tougher cards would be a better way to manage myself. As of now I have a habit of taking the hardest card first and then doing the other right after once I'm in the groove of things. This further creates a problem of me giving the lead 2-3 cards to verify in a single night. 

Communication

Communicating with the team on various things that come up to make sure I have a clear understanding of what the lead and other developer are working on to make sure the direction of what I am doing in my cards checks out with what currently is being worked on. Listening to what the lead is saying and understanding the best way to translate that into solid working tools is important for the group as a whole.

Accomplished Code

Main things for this spring were backend coding. Getting respawns working was a fun venture with various float value being recorded to reset on death. I'm thinking to improve this the values may be added to a list so it can be used with checkpoints later on. This would involve a list that can be checked to see what float values were at which point in the list depending on what checkpoints have been passed. And then resetting to the start. Next up would be working burning speed increase that would reset down to the original speed. Getting it to reset fully requires saving the initial set speed by the lead and then storing it at the start as a private float reset value. When burn speed is initially set it changes the current set values, so this reset speed value is needed to return it to the set starting value. Next up respawning at first was simple just with a spawn point at start that could be referenced when the player falls below a certain Y depth however with speed values and collectable codes this also needed to reset these values to have a properly resetting game (also HP of course). Slight problems came up of in which code (stats or controller) to actually call this function and whether it would call its own functions or reset factors on other classes. Managing how it all came together was the more difficult aspect of this card.