![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Work Post
7:48pm - Today's been kinda weird, but relaxing. I'm going to start working now, too.
I'm going over the logic for handling player input to see how I got it working before, and figure out how to move it into the AICore system.
It looks like right now in the _process function, it starts by checking if the action timer is stopped. That's a timer that runs after every turn to slow the action down to a speed the player can see.
Then, if it's not the player's turn, it pulls out the Actor on top of the actor_timing_list. It checks if that's a player controlled Actor and if it is, it sets the players_turn property to true, and updates the player's vision.
Then if it's not the player's turn after that, it runs through the current actor's on turn method.
If the current actor is still alive after its turn, it's put back on the actor_timing_list at the back.
Then if they're not still alive, and not the player, it removes them from the game.
Then it starts the action_timer, which counts down until the next turn.
So basically it just loops endlessly when it's the player's turn, until the player's Actor has less than or equal to zero action points.
That's not far from what I wanted it to be, but right now the _input function is setting properties of the Level class depending on what's recently been pressed or released, and then based on what's pressed, it runs a method on the player by a reference.
I want to get rid of that player reference since there is going to be potentially more than one player Actor. So how do I tell the PlayerAICore about input in order to get it to behave properly?
8:46pm - Took a short delay as our groceries were brought up, and read a bunch of documentation on Input in Godot to refresh myself.
One thing I noticed is that while I can handle input in the _input() function, I can also handle it elsewhere, like the _process function, by polling. So, I could make it so that when the player's turn comes up, it sends the input to the Actor, and the Actor can send it on to the AICore perhaps?
The way I've got it now I have to constantly change the state of internal properties for each input type, but I really only need to know the input that's being pressed at the time the process function is running for the Actor in question.
Heck I could put it in the Actor's process function; they're subclassed from Node, so they have one. But I don't think that's wise. I want to centralize my game inputs so I can see them all in one or two places. (Two if I've got UI elements)
So, what about if during the Level._process() function, I check the inputs, during the Player's Turn section? Right now it just loops until the Player's action_points run out. I could switch it from using the player reference to checking if the Actor has a PlayerAICore, and if it does, it passes that info up to the PlayerAICore...
Hmm...
Let's examine an example.
Actor List pops an Actor with a PlayerAICore!
PlayerAICore is detected, set players_turn to true!
Input detected "Move Left"!
Input value is passed to PlayerAICore?
...
Hang on. Maybe it IS a good idea to put the player controls in the PlayerAICore itself? Like, when the turn pump brings up an Actor with a PlayerAICore and runs its think() method, it tests the input in there. Then I'd have the input code localized in the PlayerAICore instead of in the Level, which makes a heck of a lot more sense. Plus, if it doesn't detect any input at all, it doesn't have to reduce action points, so it just returns to the player's turn again and again until they make a move.
That means I wouldn't have to make special exceptions for the player's turn in the turn pump, simpifying it a bit too.
I like this plan! I'm proud to be part of this plan. The part that came up with it and is going to implement it.
Hmm... Now that I think of it, when I implement SenseMap later on, I can use that to show the player what they can see through this system too. Everything is coming together.
Now I guess I just need to code up the AICore base class.
9:16pm - Okay base AICore class made. Next comes the AICore subclasses. But first, I realized that for the AICores to reference the Actions they either need class_name declarations or they need to be referenced in the AICore base class. So, I'm gonna do the former, and that'll take a minute or two...
9:22pm - Or six minutes I guess. Now onto the PlayerAICore.
Now the basic idea is that the think method will test each input action and output an array of Actions matching the player's input.
10:42pm - Well the guys call started suddenly while I was working, so I got in and that slowed me down a bit, but I managed to get the PlayerAICore made, I think. It'll require testing when all of this is ready. ^.^;;
For now I'm done 'cause the guys and I are gonna watch some shows together.
I'm going over the logic for handling player input to see how I got it working before, and figure out how to move it into the AICore system.
It looks like right now in the _process function, it starts by checking if the action timer is stopped. That's a timer that runs after every turn to slow the action down to a speed the player can see.
Then, if it's not the player's turn, it pulls out the Actor on top of the actor_timing_list. It checks if that's a player controlled Actor and if it is, it sets the players_turn property to true, and updates the player's vision.
Then if it's not the player's turn after that, it runs through the current actor's on turn method.
If the current actor is still alive after its turn, it's put back on the actor_timing_list at the back.
Then if they're not still alive, and not the player, it removes them from the game.
Then it starts the action_timer, which counts down until the next turn.
So basically it just loops endlessly when it's the player's turn, until the player's Actor has less than or equal to zero action points.
That's not far from what I wanted it to be, but right now the _input function is setting properties of the Level class depending on what's recently been pressed or released, and then based on what's pressed, it runs a method on the player by a reference.
I want to get rid of that player reference since there is going to be potentially more than one player Actor. So how do I tell the PlayerAICore about input in order to get it to behave properly?
8:46pm - Took a short delay as our groceries were brought up, and read a bunch of documentation on Input in Godot to refresh myself.
One thing I noticed is that while I can handle input in the _input() function, I can also handle it elsewhere, like the _process function, by polling. So, I could make it so that when the player's turn comes up, it sends the input to the Actor, and the Actor can send it on to the AICore perhaps?
The way I've got it now I have to constantly change the state of internal properties for each input type, but I really only need to know the input that's being pressed at the time the process function is running for the Actor in question.
Heck I could put it in the Actor's process function; they're subclassed from Node, so they have one. But I don't think that's wise. I want to centralize my game inputs so I can see them all in one or two places. (Two if I've got UI elements)
So, what about if during the Level._process() function, I check the inputs, during the Player's Turn section? Right now it just loops until the Player's action_points run out. I could switch it from using the player reference to checking if the Actor has a PlayerAICore, and if it does, it passes that info up to the PlayerAICore...
Hmm...
Let's examine an example.
Actor List pops an Actor with a PlayerAICore!
PlayerAICore is detected, set players_turn to true!
Input detected "Move Left"!
Input value is passed to PlayerAICore?
...
Hang on. Maybe it IS a good idea to put the player controls in the PlayerAICore itself? Like, when the turn pump brings up an Actor with a PlayerAICore and runs its think() method, it tests the input in there. Then I'd have the input code localized in the PlayerAICore instead of in the Level, which makes a heck of a lot more sense. Plus, if it doesn't detect any input at all, it doesn't have to reduce action points, so it just returns to the player's turn again and again until they make a move.
That means I wouldn't have to make special exceptions for the player's turn in the turn pump, simpifying it a bit too.
I like this plan! I'm proud to be part of this plan. The part that came up with it and is going to implement it.
Hmm... Now that I think of it, when I implement SenseMap later on, I can use that to show the player what they can see through this system too. Everything is coming together.
Now I guess I just need to code up the AICore base class.
9:16pm - Okay base AICore class made. Next comes the AICore subclasses. But first, I realized that for the AICores to reference the Actions they either need class_name declarations or they need to be referenced in the AICore base class. So, I'm gonna do the former, and that'll take a minute or two...
9:22pm - Or six minutes I guess. Now onto the PlayerAICore.
Now the basic idea is that the think method will test each input action and output an array of Actions matching the player's input.
10:42pm - Well the guys call started suddenly while I was working, so I got in and that slowed me down a bit, but I managed to get the PlayerAICore made, I think. It'll require testing when all of this is ready. ^.^;;
For now I'm done 'cause the guys and I are gonna watch some shows together.