Small Changes: Beginning vs End of development

Author: Matthew Pacheco

Date: 01/27/2024 EST

This month, I have been working on multiple smaller changes for the defenses that will give them more life. Things like an idle animation, better materials, being repairable, having better SFX, and different lasers. The issues I ran into during these small changes, were mainly around the fact that changing one thing required many other things the get moved around. Adding certain components or blueprint visible variables, required me to reparent the blueprint if it didnt show properly. Doing this meant the meshes, sounds, templates, and everything else set in blueprint but declared in C++, had to be set again just as it was before. Though this was the biggest issue, there were other things that came up like naming conventions that only worked when there was one instance, and renaming things that had a change in functionality, but still had to be referenced in the same locations.

Fixing these issues is something that can better be done at the beginning of development with more foresight. Leaving room for changing things later, even without the foresight, is a good way to make sure these simple/ tedious issues dont come up later. Since getting the project to meet these standards would require more work than it would help at this point, I decided to rework only the items that needed to be reparented. Since I had to set the variables in blueprint again anyways, deleting everything, reworking things, and then setting it again. This made sure that anything referencing the reworked items, was properly set. This did cause an issue where an enemy was using something that defenses also used, but this was only one change that was needed, so not horrible. The project is in a better standing for adding these items to the defenses, since they can be re worked in an easier way next time.