Author: Jonah McConnell

For this week my biggest task was creating a widget to allow the player to equip cores. While simple in concept (since the design behind it is basic and barely functional from a UX standpoint), making the widgets function was a bigger task than I expected. While the information existed, finding ways to pass data around without causing circular references created quite a headache. But even once these design issues were tackled, I had issues with the persistence of these changes, even after saving.

The solution I ended up coming to involved doing as much of the referencing to other classes as high up the chain of references as I could. Since all of these blueprints are only used here, this approach made things much easier. My regret with the widget blueprint as it stands is, the above section is highly repetitive. In a blueprint, this takes a long time to write, is very error-prone, and is highly resistant to change. The only way I could think to fix this would be to make an array of the widgets, however, with the widget editor I was unsure how to go about it.

Much like last week, a good chunk of my solution came in the form of changing how I deserialized the information. The difference this week was I also had to change what I was serializing, and even the serialization order. To serialize the pointers, I had to serialize the ID of the pointers rather than the pointers themselves. This was an elegant solution that worked well with how the rest of the serialization was set up, requiring only one small change. Because the cores rely on the runes, the runes had to be serialized first. This meant the collection of runes was recreated first so that the process of rebuilding the cores could get the pointers from the runes collection. Other than this, the process mirrored a simpler version of the maps from last week. With a known size, and no relations to recreate, the array was easily serialized, and deserialized.