Author: Jonah McConnell

Have you ever spent hours of work for it to end in what feels like very little given the time put in? This was the crowning experience of my week, and it was purely for one reason: templates. Unreal is beyond particular about their templates. They don't allow any UObjects to be templated, so I made the foolish choice to try to make a class not registered with Unreal, but used by an actor in Unreal. After days of battling linker errors and other compile-time issues exasperated by Unreal's build process, I was finally left with scraps of what I had built.

I ultimately was forced to pare down all of my work to what you see above, a shell of what I intended it to be. To avoid two classes being dependent on one another, I attempted to have the enemies indirectly reference their manager through an interface. This interface allowed the enemies to register themselves with the manager without knowing about it directly. However, this ultimately failed because I tried to make it templated to allow for registries of any type.

While it is of course incredibly frustrating to have to throw away days of work for a much simpler, more limited outcome, I cannot deny that I have gotten valuable experience from the endeavor. My head is spinning with ideas of alternate ways I could have attempted to implement the same process while adhering to Unreal's strange ways of writing code. For example, I could have the registry take in only instances of IRegisterable, which could have a function returning a TSubclassOf object to determine their type the way Unreal intends and have another TSubclassOf value in the registry to determine if the IRegisterable instance is a valid addition or not. While this adds some extra overhead in the code to adding or removing items, I believe it could have achieved in spirit what my failed attempt did not.

However, despite my 20/20 vision in hindsight, it does not change the fact that I let my stubbornness influence my choices in how to solve an issue, and cost myself a great deal of time for it. Staying late to get more hours in to make up for last week does little to help mitigate lost time when those extra hours are burned by a choice to do things in a way that is hacky at best, and broken at worst due to the constraints of my environment. While thinking outside the box is a great exercise for creatives and non-creatives alike, as programmers we must straddle this line to accomplish things seemingly only possible out of the box within the context of the box. Our job is to do the most with the constraints we're given, so while our goals can expand beyond the box, our solutions must be within the box in the end. We might do what we can to stretch the box or put another box on the end of a particularly long portion of or solution to make it mostly fit in the box, but we can't ignore the box. Even when we think outside the box, we don't pretend it no longer exists. My mistake this week was pretending my box didn't exist, and I paid for it in spades with my time.

Going forward I will be sure to remember this and focus on getting better results with my time. Adding more time to a task like this one yields diminishing returns, so I need to shift my mindset to avoid losing time like this. While in the past I could push the envelope in strange ways like this under the guise of using it to learn more about my environment, on a project like this, or especially in the real world, I can't burn so much time to be doing so. While my pursuit of learning will never stop, I'll be doing my best to cut out this untimely method from my approaches in order to continue to contribute in the best ways I can.