Custom Classes: Always Learning

Yawn

Another late night, super late compared to before. Last meeting ended at around 3am. Luckily I was able to sleep in until around 10, although I definitely wasn't sleeping the whole time. I've got more late meetings tonight (11p-1a and 3.30-4.30a). All of this is to say I'm still pretty exhausted, and will likely remain this way until my time off for the holidays. Add on top of that an extra-heavy load at the day job, and you can guess I'm not really feeling like doing much on Xenodochium.

Something

Even so, I need to maintain my momentum by doing something, anything really! So, I start by reviewing my dev log from yesterday to pick the low-hanging fruits. I'm going to start with creating a new enum on the parent interactable. This will be used to define the interaction restrictions on the different operational states. I have tool level and interaction limit, but another that comes to mind is skill level. I can create that key here, but how do I properly define the actual skill it relates to? I don't feel like I should include that in the this enum as that's going to complicate things when it comes to interaction restrictions.

It occurs to me that I can just define a "related skill" for each operational state. Then I can use that with this "skill level" restriction, as well as for what skill to grant experience in upon successful interaction. Discussing it with Gemini wasn't helpful, it suggested three things that just seemed more complicated than what I was thinking. Even after describing my design in more detail, the AI still didn't quite get it and gave me a more complicated approach than I felt I needed. So, I went with the operational state based skill choice, while defining the skill level in the enum for the interaction restrictions.

After a bit of thinking, I felt like there were things that were going to be duplicated between my different operational states. I really didn't want to just have two scripts that were nearly identical but carrying different data and having some different inner workings. So, a new-to-me concept is being put to use here, custom class! I can create a class, without attaching it anywhere, to contain the things that will be the same between each operational state. Then the operational state can extend that class, and they both have access to the same "features"!

I'm not sure how this will work out, but I'm seeing so many different things I've previously done that should be refactored to use these new concepts I'm learning. Oh well, in time, maybe. The biggest one I see is the use of enum for skills, I really should have done that up front, but it's too late now (sorta) and I don't feel like doing a major refactor surrounding that while working through this other major refactor. 

So, with a small set of interaction restrictions defined, I've also added my dictionary to house the related data. I've added a simple string to hold the information regarding the state-specific related skill. And I need to move my reset trigger enum to this base class along with the reset trigger variable and the interaction limit (but the current number of interactions should stay in the base object). I need my interaction sound over there, along with the item information (how many of which item) for successful interaction.

Still learning so much! Now I'm learning about "super" and inheritance of classes. See, I feel like I should define all the functions I need (even if they're blank) in the base class. Then I can define the actual working functions inside of each state as necessary. Again, really wish I knew this stuff sooner, I'm sure I could have done a lot better in other areas. Some of the stuff surrounding the state pattern confused me, but mostly it was due to the way Gemini explained it.

Next Time

I've now got a new base class for my interactable operational state, and each state has it's own script to "augment" the way it works as necessary. I have my variables setup and ready to use in there, as well as a couple of placeholder functions for entering and exiting the state. No actual changes to the way the interactable works yet. And no functionality in the base class or the individual operational state scripts. I guess that's where I begin in the next session, figuring out how to move the functionality around. I guess the first step is going to be to move my existing interaction functionality into the base class.