![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee1:54am - So my TTRPG game was postponed this week since one of my friends and players had family problems. That led to the night ending relatively early, but I'm still up and active. It's hot and my computer's having troubles dealing with the heat and playing video games without locking up, I still don't know if that's really the problem but it seems like a lot of coincidences so far. ^.^;;
Anyways I was saying earlier that the next thing I want to do is the AI scripting.
The idea is to have plug-in scripts for the AIs. That way, I can put in a PlayerAICore that takes its commands from the input and puts them in command stacks, and a BasicMonsterAICore that generates command stacks and returns them... And I can make more as needed. There'll be AIs for all the actor types. But I still need to figure out how they'll work logically. I've got a pretty general idea and I don't think it'll be a problem, but I want to make sure I do it right.
So! In order to be a pluginable AI script, there needs to be a base class for each of the AI scripts to inherit from, thus making them interchangable. The most basic thing the base class needs is a method that all the kids will overload, which returns an Array of commands.
Should it be called think() or get_commands() or what? I'm not sure.
The other thing I'm thinking about, should it directly access the Actor it's connected to's properties, or should it be passed a bundle of info? I know I was thinking of having the AI take a sort of SenseMap from the GameMap that showed what it could see. But I don't have something like that implemented yet. Well, maybe I could make a basic one pretty quick by just giving it a rectangle or square mini map version... Anyways I'm not entirely sure there.
The point is that the AI needs to analyze things outside of it.
I think that means I should pass it the Map that the AI haver is on, at the very least. And maybe a reference to itself as well. That way it'd have access to all the properties of the AI haver...
So it might be like, aicore.think(self, map) and that returns an array of Actions.
I think that's all it would need. Now let's go inside and see how it works...
In the case of the BasicMonsterAICore I think it would start by analyzing the Map to choose its action.
If an enemy is in sense range, attack or move towards them. If an enemy is not in sense range, random wander or idle.
In the first case, it returns a melee_attack or move action in an array.
In the second case, it returns a random move action or an idle action.
And now it occurs to me that these actions are going to have to have an action point cost as well, since that was how the energy system works. I'll have to figure that out as well.
Hmm... I suppose when the Actor runs its action methods, they'll have to include action point decreases.
Alright, that all makes sense. Now what about the PlayerAICore? It's not too hard to change where the input source is for the Monster AI, but the Player's input comes from a whole other system.
Hmm... Part of the reason I'm doing this is to open the game up for the potential of controlling more than one character in the game, so I should reconsider how input is handled.
I'm not really fond of the way the input works right now so I'll probably end up changing it too. It was kind of a kludge.
So let's see. There's a few ways I could make it work, but what's best? I want it to be reactive, but not do the wrong thing. Ideally the player should be able to hold down a movement key to move on subsequent turns. They can do that in the working version I had before, but I don't think that will work with the new Action system, and the AICore system.
Basically when the PlayerAICore gets its think() function run, it should wait for input, unless there's one already waiting, and there should be a delay on how fast it can take a new input. I've already got a Timer for the input like that, it shouldn't be hard to connect. Basically the tricky bit will be looping without locking the program while waiting for input.
I think this part I really need to look at the code for, but it's getting really late and my friends are chatting again, so I might stop here for the night.
3:03am - I think I've got some good ideas in here so far. I should be able to implement something next time.
Anyways I was saying earlier that the next thing I want to do is the AI scripting.
The idea is to have plug-in scripts for the AIs. That way, I can put in a PlayerAICore that takes its commands from the input and puts them in command stacks, and a BasicMonsterAICore that generates command stacks and returns them... And I can make more as needed. There'll be AIs for all the actor types. But I still need to figure out how they'll work logically. I've got a pretty general idea and I don't think it'll be a problem, but I want to make sure I do it right.
So! In order to be a pluginable AI script, there needs to be a base class for each of the AI scripts to inherit from, thus making them interchangable. The most basic thing the base class needs is a method that all the kids will overload, which returns an Array of commands.
Should it be called think() or get_commands() or what? I'm not sure.
The other thing I'm thinking about, should it directly access the Actor it's connected to's properties, or should it be passed a bundle of info? I know I was thinking of having the AI take a sort of SenseMap from the GameMap that showed what it could see. But I don't have something like that implemented yet. Well, maybe I could make a basic one pretty quick by just giving it a rectangle or square mini map version... Anyways I'm not entirely sure there.
The point is that the AI needs to analyze things outside of it.
I think that means I should pass it the Map that the AI haver is on, at the very least. And maybe a reference to itself as well. That way it'd have access to all the properties of the AI haver...
So it might be like, aicore.think(self, map) and that returns an array of Actions.
I think that's all it would need. Now let's go inside and see how it works...
In the case of the BasicMonsterAICore I think it would start by analyzing the Map to choose its action.
If an enemy is in sense range, attack or move towards them. If an enemy is not in sense range, random wander or idle.
In the first case, it returns a melee_attack or move action in an array.
In the second case, it returns a random move action or an idle action.
And now it occurs to me that these actions are going to have to have an action point cost as well, since that was how the energy system works. I'll have to figure that out as well.
Hmm... I suppose when the Actor runs its action methods, they'll have to include action point decreases.
Alright, that all makes sense. Now what about the PlayerAICore? It's not too hard to change where the input source is for the Monster AI, but the Player's input comes from a whole other system.
Hmm... Part of the reason I'm doing this is to open the game up for the potential of controlling more than one character in the game, so I should reconsider how input is handled.
I'm not really fond of the way the input works right now so I'll probably end up changing it too. It was kind of a kludge.
So let's see. There's a few ways I could make it work, but what's best? I want it to be reactive, but not do the wrong thing. Ideally the player should be able to hold down a movement key to move on subsequent turns. They can do that in the working version I had before, but I don't think that will work with the new Action system, and the AICore system.
Basically when the PlayerAICore gets its think() function run, it should wait for input, unless there's one already waiting, and there should be a delay on how fast it can take a new input. I've already got a Timer for the input like that, it shouldn't be hard to connect. Basically the tricky bit will be looping without locking the program while waiting for input.
I think this part I really need to look at the code for, but it's getting really late and my friends are chatting again, so I might stop here for the night.
3:03am - I think I've got some good ideas in here so far. I should be able to implement something next time.
