I’ve been absent for a little bit. I got back to devvin’ and discovered that I was having some trouble getting back as I had prototyped a lot of functionality with blueprints and I don’t find them particularly easy to grok. So, I’ve done a couple things today: - Changed how items are designed so that I no longer have a unique blueprint derived from a base item blueprint for each individual item (no Carrot blueprint, Turnip blueprint, etc.) Items are now just created from an Item class and, if there’s something special about that particular item (Ham Sandwich being Food, for instance) then it uses a Food class which derives from Item. This is a pretty basic design mistake that was resolved and wasn’t immediately obvious to me when I was lost in trying to make sense of the blueprint system. I would have done things much differently from the beginning if I was just working straight in C++. Everything is much cleaner now and my asset folder isn’t an absolute disaster. - Replaced a lot of blueprints with equivalent C++ classes instead. I have a much easier time of understanding code at a glance than I do of trying to follow node graphs. I’m also more confident that I know how my code is interacting with other parts while I often would just throw a Hail Mary and hope for the best in the blueprint system. The attached image is an example of a chunk of a blueprint replaced with the C++ equivalent. Don’t get me wrong, the blueprint system has been fantastic for quickly wiring up behavior for the UI and hooking UI events to game code which I’ve written in C++. But, I think the problem was that I was leaning too heavily on the blueprint system, which I knew next to nothing about, and was too busy just trying to get my node soup to work to really worry about the bigger picture in properly designing things so that I wouldn’t be presented with a huge headache in the future if I wanted to make any significant change.