Slight issue I'm hitting: I got messed up from doing foolish stuff like "being outside", and in the state I'm in, I end up much more inclined to code, than to talk about the stuff I'm coding. I'll try, though.
Basically, for the past few days, I've been refactoring code. As before, just rearranging things and looking at them from a different perspective can yield shocking amounts of order that I feel the original presentation obscured. What I'm currently trying to work up to is this:
- Given that the game-state controls the choice of input handler
- Given that the choice of input handler controls the possible input events
- Given that the act of processing the input events requires knowledge of both the game-state and the input event
- The third given makes no sense, and we should instead be focusing on giving each behavior in the main function a distinct input event, so the relevant logic can be moved out of the function.
Still more work to be done on this stuff, but I think it's possible now for me to start breaking out methods, and then look into moving them around more.
I got inspired by this post to do another related simplification, and that bugged the game up until I remembered one thing about Coconut that really bothers me: data classes with no fields have falsy instances by default. That kind of thing has me thinking that I'll want to revisit Structured Data later, because there are various ways that, after I've worked so long on Structured Data, Coconut violates the "Principle of Least Astonishment" for me. (See also "I'm pretty sure you can't use dotted paths in a match".)
Hopefully, I'll make good progress on this big refactor, then figure out whether I want to make any changes to the storage and invocation for "Items", then I should be good to start on part 10, and wire in my own serialization logic.
For now, I extremely need to get to sleep. Good night.