Author: Jonah McConnell

So if you do half, and I do half, then half will get done, and the other half will also get done, which will mean we both only need to do half, meaning only half is required, so... Ok so while splitting work often brings complications, luckily that is not always the case in Unreal. My work as of late has been connecting the existing UI functionality to the saved data and other underlying systems for Planetarium. 

This week I got the chance to put a lot of polish on my changes to Hanna's existing UI. The text for the details is now derived from the information found in the skill tree data asset. This has contributed to my overall push for us to use data-driven design patterns. While we do not have the luxury of using purely Data Oriented systems (nor do I believe that I could pull myself to do so with how deeply ingrained OOP concepts are in me), the use of it where we can has done wonders to decrease our need to create more blueprint types or compile more often. This has helped the game feel cleaner in the areas that benefit from being data-driven.

While the data-oriented aspects help development on the skill tree to continue smoothly (and allow later polish to be seamless), my struggle was with the splitting of responsibilities between code, and blueprint. In the past, I've only thought about using blueprint implementable events to allow for extra extensibility without the need for any extra code or compilation. However, I took a different approach that posed an equally interesting design problem: using it to allow for specific functionality code could not provide. I tried to look for moments when I could use the flexibility and freedom of blueprints to quickly add functions the code could count on to allow me to implement my features without sacrificing the power of code. In the skill tree, this allowed me to slot the functional parts of the widget into the existing structure in the designer. However, my favorite use was to get the string value of an enum type. One of my biggest gripes with C++ was losing the functionality of enums that C# provides. While I know these niceties are largely superfluous, they were often useful, especially when trying to articulate the state of my code with enums. However, Unreal provides many of these same functions in Blueprint. While this is incredibly helpful there, the same functionality does not extend to "Unreal C++". To get around this, I moved some of the responsibility to Blueprint to allow for a quick function to do this conversion when naming equipment in our Loot Generator. This saved me anywhere from half an hour to many hours depending on how much time I would have had to spend troubleshooting a purely C++ solution. This isn't even touching on the fact that by choosing to avoid the switch statement, I also avoided having to write more code that would have to be maintained to add new Equipment types. While our time may be out to add more Equipment here in Capstone, I still like to practice these design considerations wherever and whenever I can.