Interactable: Operational State Planning

Let's Work

Late night again last night due to meetings. Then, as usual, an early morning due to noise. Add a day of frustrating work on top of it and I'm not sure I'm really wanting to work much on the game. But then I remember that if I don't work on it, nothing will happen and my overly ambitious dream game will never be built. So here I am, doing at least something once again. Where to begin? I guess I need to analyze exactly what my interactable is doing to figure out what exactly I need to move into the state blocks. 

So, the interactable has a "state" already which determines the interactability of the object. That needs to remain in the base object. So does the function that actually determines the state. Although I probably need to move a portion of the interactivity state check into the operational state. I can foresee making a portion of my interactability reliant upon different things depending on the operational status.

Obviously, I need to keep my ready in the base object, I think all of the stuff that kicks off there stays there. No need to move any of that to an operational status. There's a function to control the interactivity indicators. That should stay as part of the base object too, no need to move that. Same goes for the helper functions related to showing and hiding the indicator.

Interact, that's a big one. I think I should probably move that whole thing to the operational status? Maybe keep it in the parent and have it call a function in the operational state? This is one I need to think about, what does it do, exactly? First, it makes sure the interaction limit hasn't been reached. That interaction limit will be defined by the operational state. Although, all the data surrounding it will be in the main object. Then it plays a sound and drops its item. That call, to play a sound and drop an item, should be in the operational state, even if the actual function to do the drop is in the main object. After the drop, it re-evaluates it's interactive state and forces a targeting recheck. Both of those can remain in the parent.

Then there's my "reset" triggers. I think those should probably be moved to the operational state. I feel like I may have different reset timing on each state, such that maybe the "broken" state has no interaction limit. Well, not having an interaction limit is different from having a reset trigger. It makes sense to tie those two together though, the reset trigger and the interaction limit. I think the actual function that resets the interaction limit should be in the operational state, maybe working through a helper function in the parent. I think the functions that connect to signals for interaction state (such as listening for tool level changes, or being told to "update") should stay in the parent. 

Then there's the changes to the functions, beyond moving them. Things like the function that drops the item will need to change to receive a parameter. Since each operational state (Oh, a dictionary! I can change my variables to be a dictionary with the state as a key!) may drop different items, the function will need to know which item to drop. Although, if I do use a dictionary, I would be able to just rely on the current operational state to pull the right data.

Maybe I'm thinking wrong and shouldn't contain all the data in the parent and instead define the specific parameters in the operational state itself. Then I'd just have the same variables on the operational state to check and work accordingly (as well as new variables as needed for independent processes). So, like I'd have different reset triggers, item drop info, interaction limits, etc defined on the operational state. The parent would be able to read that data  or maybe it would call a getter function in the operational state, or maybe just only let the operational state use it's own data? Ugh, so much to think about.

I decided to do a little exploration of this with Gemini to see what I may be overthinking or not thinking about. So far, the idea of moving specific pieces of the interaction itself to the operational status is a good bet. Let the parent handle the checks, but the actual outcome is handled by the operational state. As for the data surrounding the individual states, putting it on the operational state itself is the best way to go. It'll make the data cleaner and clearer. With that in mind, I would need to update my "drop" function to accept data to know what to drop. This also means that my "interactability check" will have to make a call to the operational state to validate things like the interaction limit and tool level.

Next Time

This all seems pretty doable, although not today. I've barely enough time to even write out this dev log before I have to go to the mall (again!). But that's okay, "Happy wife, happy life" they say. I may have time later to actually put in some work, but with my current mental state (so drained) I may not get anything done. Hell, I might even waste time trying to nap (naps don't usually work for me). At least I'll be prepared when the time comes to actually make changes.

Still Learning

Here I am, waiting for a seat for lunch. I decided to spend more time planning since I had nothing else to do. The idea of requirements for interactions was in my head. I may want to specify multiple things before allowing interaction, but how do I define that in the data? The idea of a dictionary came to mind, and it occurred to me to use an enum as the key. I only just had this idea previously for this new operational state, but it really feels like a good approach. It will allow me to define a finite number of options, prevent accidental typos, and force me to plan for new additions. I wish I had thought of this approach sooner, I can see so many places I should have done dictionaries this way.