Author: Jonah McConnell

This week I focused a lot on the stat generation and modifying of our weapon stats. Being a looter game, having a large system for modifying the stats of our equipment is a must-have. In the case of our game, this comes in the form of cores, and the runes you attach to them to combine to some stat total. On paper, this isn't a huge task, but I wanted to make sure that we could modify every aspect of it and tweak it as if we were going to change things far off in the future. My goal for this week was to build a future-proofed system that could in theory be usable for months more to come with little to no upkeep needed. Now of course my hubris got the better of me, and what was a small visualization side project turned into a day-long task, but there was a very valid lesson to be learned in that.

When working I estimated a large amount of time for this generation system. After all, in order to generate the stats, I needed to clearly define all the ways modifications could be stored and applied. While I'm able to currently avoid the intricacies of persistent data, serialization, and applying the new stats, all of these things were still things I needed to consider when architecting my code. Because of the rather grand scale of what I was working with, I found myself spinning my wheels often, usually at a loss of what to look to next. This led to me vastly overshooting my initial time budget, and having to leave a number of bugs in my code which was highly frustrating.

However, because of the approach I took to building out the system, despite bugs being present, they are all handled gracefully and logged in the editor with an error. I won't say that my error checking is perfect, and it certainly leaves something to be desired, but it will continue to keep potential crashes from occurring at runtime once the bugs are fixed next week. However, these bugs are a symptom of another issue I ran into this week which was not progressively testing my work. I am usually very good about working in such a way that I can test each new addition or step in a process to ensure I'm getting the result I expect, or at the very least one I understand. With such a large scope this week, however, I lost sight of this incremental testing. I did tests here and there in isolation, but I could have done a better job of testing vertical slices of the system as I went to catch some of the bugs that remain currently.

Next week I'll be working on a few shortcomings this week before moving on. Firstly I'll be trying to make my graph tool shown above more usable. While someone more used to entering values to change a result may have little to no trouble using a tool, I was not making the tool just with the current team of programmers in mind. I built this tool as practice for creating something usable to a non-programmer, ideally with as little friction as possible. With the majority of the math either figured out or now smaller trivial additions, I hope to leverage other aspects of this graphing calculator to respond to feedback I've received about the visualization to make it more user-friendly. Besides working on the graph, I will also be spending time fixing the bugs in my code. While my current error checking is keeping the bugs from crashing the game, it also keeps my system from being able to be interacted with. While I feel the end architecture is a good result, I know it's not perfect. Good architecture is valuable, but going so far over budget on hours is a drastic oversight on my part. Next week I'm going to try to look to how to better break up large system tasks like this one in order to better track, and budget time. This will also help me to feel less lost in my upcoming tasks providing a great benefit overall.