![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee2:40am - Well, I'm up, I had dinner for breakfast, and the call's over for now, so I have the rest of the night and morning to myself. To do with whatever I please. I do have an appointment at 10:45 though, to get my second Covid Shot, but that's a ways away from now.
So, what am I gonna do now? I've got my project for a main thing, but once again I really feel more like being cozy in bed than working.
I suppose I can try to do both, though? I've got my little chromebook here and I do have some things I wanted to think about with regards to the design.
The last thing I did when I was working on it yesterday, was removing everything from the Level in preparation of putting the Dungeon there, with the Rooms on top of that.
But, the GameMap had a lot of code in it that's not there anymore. I mean, I still have the script, but it's not in the world anymore. Anyways the Dungeon class/scene pair need to pick up the slack. The Level has the turn and action pumps. The GameMap kept track of where everything was located and had methods for moving things around on the map. Well, that second part isn't neccesary anymore since I'll be using physics based movement to move the player and other things. But what about the location? Knowing the locations of things is really important in a map for a turn based game, but it might not make as much sense in a real time zeldalike game.
My plan to use the Action classes and methods still stands, but it'll have to work differently.
The way it was working before, when Enemy wanted to attack Player, it would put, say, a melee_attack_actor Action into the Action queue. It would use the monster's stats to determine how much damage output the attack should do. Then the Actor would put a recieve_attack_from_actor Action in the queue, having the target run its defense values against the damage from the Enemy and take the leftover damage.
Uh, actually that would still work that way. Bad example. I'm having trouble running through this in my head because the music I'm listening to is too good. I'll change it to something more mellow when this concert is over.
3:31am - Alright concert over. But in the mean time I noticed it was around the time a certain friend was in a certain place last night, so I went there to look for them, and now I'm there too.
After trying for a bit I don't think I can conceptualize what's wrong with the Actions without looking at the code. So I'll do that when I can get up again.
5:51am - After doing a little of this and that I was able to get up. I watched an anime episode and now I think I'm ready to get back to work.
So, the GameMap's out. Let's take a look inside of it now that I'm at my personalified computator.
Yeah, it looks like it's all obsolete. Even the things I still need, I'll have to make in a different way. Alas! It'll be saved in the Roguelike scripts for the next time I get a roguelike bug up my butt.
One of the goals on my TODO list is to run every Actor and every AICore on every frame. So I only need the actor_timing_list on the Level in order to determine who goes when. It'll seem like they're all going at once, but everything happens in order in a computer simulation.
So, I'll need to write a whole new turn and action pump using a for each statement instead of going through all the NPCs until it's the player's turn and waiting.
6:10am - Alright! The new Action Pump is super tiny and really simple. It's good! I'll need to tweak a few other things though since it doesn't work the same way as before.
6:29am - I've removed a lot of my old code and work from the project that isn't relevant anymore and I don't think I can glean anything from the code for new elements. I've still got my backups just in case though.
The main thing I kept was the Actor and Actions systems. But even the action pump had to be rewritten, tiny as it is now. I'm not starting completely from scratch here but I've gone back like 80% of the way. ^.^;;
It's a good thing this sort of game is what Godot is made for, so I'll be able to catch back up to myself quicker than when I was making a turn-based game.
6:37am - The first thing I need to do with the Actors system is make a new PlayerActor that builds on the base Actor, and a new PlayerAICore that uses the new system for controlling the player. I'll build up the Actor class with bits of the PlayerActor that are generic enough to go into all of the Actors.
6:51am - Fortunately I remembered my previous plan was to make only the one Actor class which has all the Actor activities in it, and not make children of it. The sub actors will let the script know about what elements they have by including them in one of several lists that the Actor class will expose.
8:24am - I'm trying to decide if I should make the Actor class/node into a child of KinematicBody2D instead of just Node2D, or if I should have it only have a KinematicBody2D property if it has one attached.
If it's a KinematicBody2D then it always has/is one by default, but that means all Actors are collidable...
No, I don't think that'll work. I want to use Actors for special effects and things too. They won't neccesarily have collision.
On the other hand, if I'm using the same movement code for all Actors, it'd HAVE to be a KinematicBody2D just to have the move_and_slide() function. Otherwise, I'd have to have two method implementations in the move action just to handle both cases.
Hmm... Maybe I should only use Actors for effects that can collide?
Or maybe I shouldn't use the Actors for anything but the player, enemies, and pickups, and have everything else just use Area2Ds and signals to broadcast what's going on...
Mmph... I'll have to think about this for a bit.
When the player collides with a door, the door should react by signaling the transfer, pausing the room the player was in and playing the door animation, then doing the opposite on the other side of the transfer. It doesn't need all the other things Actors do. But then what about the action system?
Yeah I'll need to take a break before I can tackle something this big. I've been actively working for two and a half hours. I'll lay down and watch an ep or two of anime before continuing.
10:19am - I watched an ep of an anime and also an ep of SFIA and it's getting close to time for me to get my second shot, but before then I'm still struggling with the fact that I'm probably going to have to throw out the last of my remaining work on my project in this pivot. I thought I'd still be able to use the Action system but now I'm not so sure.
I'm having trouble visualizing the situation and really getting in 'the zone' though, especially with such a short time to work. So I guess I'll have to save it for after my shot, if I'm still feeling up to working then.
12:32pm - Well I've got my second Covid shot but I've also entered the state where I'm too tired to work on code anymore, so I guess I'm done for the day.
So, what am I gonna do now? I've got my project for a main thing, but once again I really feel more like being cozy in bed than working.
I suppose I can try to do both, though? I've got my little chromebook here and I do have some things I wanted to think about with regards to the design.
The last thing I did when I was working on it yesterday, was removing everything from the Level in preparation of putting the Dungeon there, with the Rooms on top of that.
But, the GameMap had a lot of code in it that's not there anymore. I mean, I still have the script, but it's not in the world anymore. Anyways the Dungeon class/scene pair need to pick up the slack. The Level has the turn and action pumps. The GameMap kept track of where everything was located and had methods for moving things around on the map. Well, that second part isn't neccesary anymore since I'll be using physics based movement to move the player and other things. But what about the location? Knowing the locations of things is really important in a map for a turn based game, but it might not make as much sense in a real time zeldalike game.
My plan to use the Action classes and methods still stands, but it'll have to work differently.
The way it was working before, when Enemy wanted to attack Player, it would put, say, a melee_attack_actor Action into the Action queue. It would use the monster's stats to determine how much damage output the attack should do. Then the Actor would put a recieve_attack_from_actor Action in the queue, having the target run its defense values against the damage from the Enemy and take the leftover damage.
Uh, actually that would still work that way. Bad example. I'm having trouble running through this in my head because the music I'm listening to is too good. I'll change it to something more mellow when this concert is over.
3:31am - Alright concert over. But in the mean time I noticed it was around the time a certain friend was in a certain place last night, so I went there to look for them, and now I'm there too.
After trying for a bit I don't think I can conceptualize what's wrong with the Actions without looking at the code. So I'll do that when I can get up again.
5:51am - After doing a little of this and that I was able to get up. I watched an anime episode and now I think I'm ready to get back to work.
So, the GameMap's out. Let's take a look inside of it now that I'm at my personalified computator.
Yeah, it looks like it's all obsolete. Even the things I still need, I'll have to make in a different way. Alas! It'll be saved in the Roguelike scripts for the next time I get a roguelike bug up my butt.
One of the goals on my TODO list is to run every Actor and every AICore on every frame. So I only need the actor_timing_list on the Level in order to determine who goes when. It'll seem like they're all going at once, but everything happens in order in a computer simulation.
So, I'll need to write a whole new turn and action pump using a for each statement instead of going through all the NPCs until it's the player's turn and waiting.
6:10am - Alright! The new Action Pump is super tiny and really simple. It's good! I'll need to tweak a few other things though since it doesn't work the same way as before.
6:29am - I've removed a lot of my old code and work from the project that isn't relevant anymore and I don't think I can glean anything from the code for new elements. I've still got my backups just in case though.
The main thing I kept was the Actor and Actions systems. But even the action pump had to be rewritten, tiny as it is now. I'm not starting completely from scratch here but I've gone back like 80% of the way. ^.^;;
It's a good thing this sort of game is what Godot is made for, so I'll be able to catch back up to myself quicker than when I was making a turn-based game.
6:37am - The first thing I need to do with the Actors system is make a new PlayerActor that builds on the base Actor, and a new PlayerAICore that uses the new system for controlling the player. I'll build up the Actor class with bits of the PlayerActor that are generic enough to go into all of the Actors.
6:51am - Fortunately I remembered my previous plan was to make only the one Actor class which has all the Actor activities in it, and not make children of it. The sub actors will let the script know about what elements they have by including them in one of several lists that the Actor class will expose.
8:24am - I'm trying to decide if I should make the Actor class/node into a child of KinematicBody2D instead of just Node2D, or if I should have it only have a KinematicBody2D property if it has one attached.
If it's a KinematicBody2D then it always has/is one by default, but that means all Actors are collidable...
No, I don't think that'll work. I want to use Actors for special effects and things too. They won't neccesarily have collision.
On the other hand, if I'm using the same movement code for all Actors, it'd HAVE to be a KinematicBody2D just to have the move_and_slide() function. Otherwise, I'd have to have two method implementations in the move action just to handle both cases.
Hmm... Maybe I should only use Actors for effects that can collide?
Or maybe I shouldn't use the Actors for anything but the player, enemies, and pickups, and have everything else just use Area2Ds and signals to broadcast what's going on...
Mmph... I'll have to think about this for a bit.
When the player collides with a door, the door should react by signaling the transfer, pausing the room the player was in and playing the door animation, then doing the opposite on the other side of the transfer. It doesn't need all the other things Actors do. But then what about the action system?
Yeah I'll need to take a break before I can tackle something this big. I've been actively working for two and a half hours. I'll lay down and watch an ep or two of anime before continuing.
10:19am - I watched an ep of an anime and also an ep of SFIA and it's getting close to time for me to get my second shot, but before then I'm still struggling with the fact that I'm probably going to have to throw out the last of my remaining work on my project in this pivot. I thought I'd still be able to use the Action system but now I'm not so sure.
I'm having trouble visualizing the situation and really getting in 'the zone' though, especially with such a short time to work. So I guess I'll have to save it for after my shot, if I'm still feeling up to working then.
12:32pm - Well I've got my second Covid shot but I've also entered the state where I'm too tired to work on code anymore, so I guess I'm done for the day.
