![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee7:14pm - I'm feeling kinda sick with some sort of stress today, but I find I'm wanting to work anyways in spite or because of it, I'm not sure which. Maybe both. I'm a push and pull at the same time kind of person.
Anyways I've got my sprite sheet done and I want to see it in action, so I've got to put together a Player in my game, with animations and stuff.
Of course that brings me back to my problem from before I started doing the art to distract myself...
The Actions system. The last remaining element from my Roguelike project.
I need to figure out if I'm going to keep it or not.
The way it works is the AICore returns a list of Actions and each Action calls a method on the Actors involved. But what about collisions?
The Actions system made a lot of sense when I was doing combat and things outside of space, but with the actions happening in virtual space, with colliders, I'm not sure how it'll work. Let's think about it for a bit.
The user presses the attack button. Player_1's AICore intercepts the input and returns an Action list with an Attack action.
Right there it's a difference from before, because it's not melee attack or ranged attack, it's just attack. It would use whatever was the equipped weapon/item, probably a sword, and swing it.
So, the action pump calls attack_action() which plays the attack animation, which includes a hitbox. When the hitbox collides with Enemy_1's hurtbox, what happens there?
Player_1 and Enemy_1 both register the collision, which cause their signals to go off. Who is listening to the signals?
If they're listening to their own signals, they could react by running a method on themselves, but that would go 'around' the AICore system. They could set a property on themselves that they hit something, and the AICore could react to that on its next run. Or there could be a third party that all Actors register with when they are instantiated, which informs the AICore. Or I could make the AICore able to take input somehow.
I feel like, on a better day, I could figure this out no problem, but today it's being really taxing.
Let's look at how this would go if I got rid of the Action system. I'd want to keep the AICore system, but instead of returning actions, it would just make method calls on its associated Actor.
The User presses the Attack button. Player_1's AICore runs, and detects the button press. It runs the attack method on its associated Actor, causing an attack animation to play including a hitbox, which collides with Enemy_1's hurtbox. They send out their signals. ... it's basically the same, and continues to the same problem. Either it dodges the AICore and has to use a unified functionality between Actors, or it needs to signal the AICore some way.
So I'm not sure there's any real benefit to using the Action system over direct method calls. Especially if damage is going to come from collisions of hitbox and hurtbox anyways.
And I don't want the actors to be coupled with a third party thing anyways. Shoot. Alright the Action system gets the boot too.
So! Instead of returning anything the AICore is just run and it does its thing. I'll have to implement that first.
Had to get rid of my old PlayerAICore, it didn't do anything that didn't depend on the old GameMap system.
Next step is to make a new PlayerAICore to read the input from the User and run the appropriate Actor methods.
Now one tricky thing about Godot in general is that you want to take your input in the _process() method but you want to do your movement in the _physics_process() method. So, the move_actor method that the AICore runs will set a direction to move in, and a target velocity, but it'll only actually be moved during the _physics_process() method.
But wait, will that work properly? I'm not sure. I just realized that there's every possibility the player will press the movement control and release it before the physics process goes... Hum... Tricky Pickle!
8:20pm - I did some reading in the documentation and it seems it's okay to poll input during the _physics_process() function but there is a reason I wanted to do it during process() instead.
_process() runs as fast as possible, while _physics_process() only runs once a frame. As such, complicated AI Behavior should happen during _process(). Since I'm getting the input in the AICore which runs during _process() I have to deal with it then.
Hang on a sec. I just realized that right now, my AICore only runs when triggered by something outside of it. Now that it doesn't return an action, there's no reason it can't run on the _process() function of the Actor node itself, instead of the Level node. This would decouple them, and enable the Actor nodes to function independantly as I wanted.
Damn, everything is shifting so much!
What's more, that realization and change has completely emptied the Level script. XD
10:23pm - I ended up leaving the computer for a couple hours because I realized that there was yet more code from my roguelike game left, and it has to go too.
The whole Actor system, complete with the AICore system.
Really, there's no point in keeping ANY of the code from my Roguelike Project. There's no reason to have the Actors all be based off a single Actor script anymore. The whole game is completely different and it just doesn't make sense anymore.
The emotional toll of realizing I was not only starting from scratch, but starting by gradually eliminating old stuff before starting from scratch, was just too much, and I had to stop and get comfortable for a while.
Yeah, there's no reason not to do this all as dead simple as possible and make each thing its own thing.
Yeah, it's all gone now. All the code is gone now and I'm starting from scratch again, there was nothing left after I checked the code.
Frustration.
Well it doesn't change what I'm doing. I'll just have to start again.
11:40pm - Alright I've got my animations in and my MrBall looks good. Even the spin, I was worried about that. So I'm happy. But I have a lot of work ahead of me.
Anyways I've got my sprite sheet done and I want to see it in action, so I've got to put together a Player in my game, with animations and stuff.
Of course that brings me back to my problem from before I started doing the art to distract myself...
The Actions system. The last remaining element from my Roguelike project.
I need to figure out if I'm going to keep it or not.
The way it works is the AICore returns a list of Actions and each Action calls a method on the Actors involved. But what about collisions?
The Actions system made a lot of sense when I was doing combat and things outside of space, but with the actions happening in virtual space, with colliders, I'm not sure how it'll work. Let's think about it for a bit.
The user presses the attack button. Player_1's AICore intercepts the input and returns an Action list with an Attack action.
Right there it's a difference from before, because it's not melee attack or ranged attack, it's just attack. It would use whatever was the equipped weapon/item, probably a sword, and swing it.
So, the action pump calls attack_action() which plays the attack animation, which includes a hitbox. When the hitbox collides with Enemy_1's hurtbox, what happens there?
Player_1 and Enemy_1 both register the collision, which cause their signals to go off. Who is listening to the signals?
If they're listening to their own signals, they could react by running a method on themselves, but that would go 'around' the AICore system. They could set a property on themselves that they hit something, and the AICore could react to that on its next run. Or there could be a third party that all Actors register with when they are instantiated, which informs the AICore. Or I could make the AICore able to take input somehow.
I feel like, on a better day, I could figure this out no problem, but today it's being really taxing.
Let's look at how this would go if I got rid of the Action system. I'd want to keep the AICore system, but instead of returning actions, it would just make method calls on its associated Actor.
The User presses the Attack button. Player_1's AICore runs, and detects the button press. It runs the attack method on its associated Actor, causing an attack animation to play including a hitbox, which collides with Enemy_1's hurtbox. They send out their signals. ... it's basically the same, and continues to the same problem. Either it dodges the AICore and has to use a unified functionality between Actors, or it needs to signal the AICore some way.
So I'm not sure there's any real benefit to using the Action system over direct method calls. Especially if damage is going to come from collisions of hitbox and hurtbox anyways.
And I don't want the actors to be coupled with a third party thing anyways. Shoot. Alright the Action system gets the boot too.
So! Instead of returning anything the AICore is just run and it does its thing. I'll have to implement that first.
Had to get rid of my old PlayerAICore, it didn't do anything that didn't depend on the old GameMap system.
Next step is to make a new PlayerAICore to read the input from the User and run the appropriate Actor methods.
Now one tricky thing about Godot in general is that you want to take your input in the _process() method but you want to do your movement in the _physics_process() method. So, the move_actor method that the AICore runs will set a direction to move in, and a target velocity, but it'll only actually be moved during the _physics_process() method.
But wait, will that work properly? I'm not sure. I just realized that there's every possibility the player will press the movement control and release it before the physics process goes... Hum... Tricky Pickle!
8:20pm - I did some reading in the documentation and it seems it's okay to poll input during the _physics_process() function but there is a reason I wanted to do it during process() instead.
_process() runs as fast as possible, while _physics_process() only runs once a frame. As such, complicated AI Behavior should happen during _process(). Since I'm getting the input in the AICore which runs during _process() I have to deal with it then.
Hang on a sec. I just realized that right now, my AICore only runs when triggered by something outside of it. Now that it doesn't return an action, there's no reason it can't run on the _process() function of the Actor node itself, instead of the Level node. This would decouple them, and enable the Actor nodes to function independantly as I wanted.
Damn, everything is shifting so much!
What's more, that realization and change has completely emptied the Level script. XD
10:23pm - I ended up leaving the computer for a couple hours because I realized that there was yet more code from my roguelike game left, and it has to go too.
The whole Actor system, complete with the AICore system.
Really, there's no point in keeping ANY of the code from my Roguelike Project. There's no reason to have the Actors all be based off a single Actor script anymore. The whole game is completely different and it just doesn't make sense anymore.
The emotional toll of realizing I was not only starting from scratch, but starting by gradually eliminating old stuff before starting from scratch, was just too much, and I had to stop and get comfortable for a while.
Yeah, there's no reason not to do this all as dead simple as possible and make each thing its own thing.
Yeah, it's all gone now. All the code is gone now and I'm starting from scratch again, there was nothing left after I checked the code.
Frustration.
Well it doesn't change what I'm doing. I'll just have to start again.
11:40pm - Alright I've got my animations in and my MrBall looks good. Even the spin, I was worried about that. So I'm happy. But I have a lot of work ahead of me.
