So, lately I've been busy. It's true, but also I've been banging my head against a fundamental problem with the interaction actor. One that lead me to build the whole thing a new. Instead of having interaction buttons, which were in and of themselves their own class, I've elected to have possible actions represented by meshes that will fire event dispatchers on clicked to the level Blueprint.
This isn't as elegant or scalable as I'd originally designed, but it overcomes some immediate hurdles that had become something of a time sink.
For example the old button class was a devil to get any kind of recognition on mouse over events. Easy enough with the trace function but when the button is assigned as a child actor component of the Interaction Actor getting it to register events and communicate, became problematic.
This may be a problem I'll go back and revisit at some point in the future, but for now I want to advance the prototype and circumventing my lack of experience with Actor/child actor class communications seems like the best way forward.
Of course this also has me thinking about storing player/story variables. As variables will need to be checked to gate, and fire events.
I'm starting to realize that this project, being an adventure game, is going to lean heavily on Level Blueprint scripting instead of just making beautiful, elegant classes that do everything I could hope for. Is there any reason it can't be a little bit of both?
Either way you learn something from every project you work on.
Expect an update on the 28th to show you what I've got.
