Planning Is Work

Thinking Ahead

It's Sunday where I am and there's a typhoon bearing down on us, so I'm using those excuses to not actually do any coding. That doesn't mean no work though. My next target for work is going to be surrounding the player's ability to eat. This means working on the inventory along with other systems this will touch. It's going to be somewhat complicated, so I'm taking the time now to try to plan how I want it to work. My first step was to lay out the entirety of what I'm trying to accomplish along with what is already in place to prepare for this.

So, I started up a chat with Gemini and wrote it all out. This served multiple purposes, it allows me to brainstorm, but also allows me to step back and look at what already exists. The first thing that jumped out at me is that I my item definitions already have a "use_effects" variable. Originally, I was planning on using "attributes" but that just doesn't seem appropriate at this point. After realizing this, I'm already planning things!

Use Effects

This is where I'm going to do the behind-the-scenes definition of what consumables do, and not only that, I can tie them into the playerstats manager's active effects system. This means I'll need to expand my existing effects, and I may actually need to modify the system that's already in place. That's a good start, but that still doesn't actually allow the player to consume anything. I guess that's the next thing to think about. . . 

Consume

Where to begin, literally? Which system is going to be responsible for actually consuming the items? I think the best place will be in my inventory manager. This way, the central resource for the player's inventory is the one actually dealing with the item. It can run any necessary checks (does the item exist, is it actually consumable, etc) and then make a call to the playerstats manager to activate an effect. But, this still leaves one big hole in the design, the method by which the player interacts with the game to tell it to "consume" something.

So, I feel there needs to be two different ways to allow this to happen. The first, and most obvious, will be in the inventory screen itself. I intend to have an "item details" panel that is filled when the player selects an item, and part of that will be contextual buttons, one of which will allow them to "consume". The other is a bit more tricky, a way for the player to "quick consume" something without the need to enter the inventory. The reason I say this is going to be tricky is because I don't plan on having a traditional hotbar. Or, at least, I didn't originally intend on it.

Quick Actions

So, this gets me thinking of adding a more simplified idea of using a "quick action" system. Four buttons, on screen, but also tied into key bindings. In the inventory I can add the ability to assign an item to quick action 1-4, and the player will then just be able to hit the appropriate key (or on screen button) to use the item. This could work for things not related to consuming too, any item that has a "use" could be assigned there.

Brainstorming

With all of these ideas thought out, I began my conversation with Gemini. It seemed to agree with me that the best starting point for consuming items is in the inventory manager, so that's a win for me! It also seemed to agree that tying the actual "user effects" into the existing active effects system was the way to go. That's two points for human ingenuity! And it didn't really seem to find any fault with my "quick action" system idea, so that's wins on wins on wins!

Beginning to End

The next thing to figure out is the order in which to make the changes. I think the best approach will be to start in the actual data, the item and effect definitions. Can't apply an effect that doesn't exist yet! Of course, that will require some small changes in my playerstats manager to deal with the new effect definitions. And not only that, but due to the way I've built my debug system I can quickly and easily test the functionality without having to actually add the rest of the functionality.

Once that functionality exists and is tested enough, I can venture into the inventory manager. The changes there shouldn't be too much, just a few checks before doing anything, a call to the playerstats manager to deal with the effect(s), and finally removing the item from the inventory.

It is at this point where things will probably become more complicated though. Next up is going to be changes to the inventory screen itself. This means adding the ability to select items from the inventory screen and the addition of the item detail panel. But the biggest part of this will be the need to add persistence, I don't want to force my players to reset their quick action buttons every time they start the game, so the inventory manager will be the "owner" of my quick action system. There's also going to have to be special checks in the quick action for when the player runs out of an item.

The final piece will be the actual UI design for the quick action system, but that shouldn't be too difficult if all the previous steps are built properly first. This will simply be a display of data from the inventory manager hooking back into function calls housed therein. I'll have to include some signals and update checks for when the player makes changes to "equipped" quick actions, don't want to display stale data!

And as I brainstorm all of this with Gemini, it again decides to hallucinate and come up with concepts I have no intention of implementing. All of the quick action system is going to live in the inventory manager, but for some reason Gemini got the impression I'm going to build out a whole new system instead of just adding the functionality to an existing system. That's okay though, because I think I've laid out a pretty good plan of attack here. I have a starting point laid out, I have a specific course of action, each step is decently defined and the specific changes to each have been identified well enough to implement them.

Next Time

So, with this planning out of the way, I'm ready to dive right in. I have a specific starting point, so there's no ambiguity that allows me to hem and haw about what to work on. This is a very important implementation, so I'm going to be taking my time to do it right. There will be multiple systems touched by this, so I have to be very thoughtful about the changes I make.