Capstone Dev Blog 3

This sprint we got to actually tackle some of our tech debt. It was originally generated from quickly prototyping the project, and using blueprints. While blueprints are great for getting an idea implemented quickly, they are also the closest thing to pure spaghetti code I’ve ever had the misfortune of working with. To clean up our problems we’ve started moving code to C++ and implementing better blueprint coding standards.

The steps we’ve taken to improve the blueprints are using functions and local variables to reduce the long connecting strands. I’ve also proposed making use of the Pure and Const options that blueprint functions allow. Part of the previous confusion is that it wasn’t clear what functions modified what values

Using pure functions makes it clear what data each function accesses and avoids unexpected side effects from changing member variables other places in the blueprint.

Using const functions also helps avoid unexpected side effects by guaranteeing that the function doesn’t change any input or member variables. Interestingly enough neither pure nor const function nodes need to hook into the execution line which reduces a tiny bit of visual noise.

I worked on specifically modifying the player blueprint so that designers could understand it well enough to work on the jump and pvp mechanics. I started by figuring out what flags connected to what functions which was a mess and the main motivator for const and pure functions.

Each rectangle is a function, each oval is a member boolean

To simplify this I created a new blueprint on the frog player to handle jumping. This allowed our designer to work in that blueprint without modifying the player blueprint and creating merge conflicts. To simplify the jump logic I decided to just set up a general function that would check when the player had given input relative to what time the player had hit the ground. This allowed for the following structure to determine what sort of jump to do, without the mess of flags, and made it much easier to figure out what jump would happen.

By the time I had implemented the new jump system there were only a couple days left in the sprint and we wanted to have pvp mechanics in to test. Luckily it turns out the designer was happy with just a blank blueprint attached to the player to work in. This was a small breakdown in communication, because I thought he needed a more complex system to work in.

Overall I’m very happy that we got to fight some of the tech debt from prototyping. We’re also getting pretty good at avoiding merge conflicts which is an essential skill given that Unreal serializes almost everything to binary which doesn’t play well with Git.

Leave a Reply

Your email address will not be published. Required fields are marked *