![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
9:54pm - Well today I napped most of the day away, and now I'm trying to work on that story I've been procrastinating on. I thought I'd listen to some appropriate music to get into the right head space but I just realized I'm about to write a fight scene and I'm listening to lullabyes.
Oh here's a good song, Sonic Colours metal. <3
Now let's see... It's actually just before the fight scene. They're approaching the castle and I want to do their opinions of it. Not all of them because six characters voicing opinions would be a lot.
10:49pm - Alright I spent almost an hour screwing around on Twitter so that's not great for productivity.
Let's see if I can actually start now.
1:59am - Alright I think that's enough for now. I wrote a good bit of adventure, this time, all the way up to the aftermath of the first trap.
That should be enough work for today as well.
Oh here's a good song, Sonic Colours metal. <3
Now let's see... It's actually just before the fight scene. They're approaching the castle and I want to do their opinions of it. Not all of them because six characters voicing opinions would be a lot.
10:49pm - Alright I spent almost an hour screwing around on Twitter so that's not great for productivity.
Let's see if I can actually start now.
1:59am - Alright I think that's enough for now. I wrote a good bit of adventure, this time, all the way up to the aftermath of the first trap.
That should be enough work for today as well.
4:06pm - Though I had a hard time admitting it to myself, I've just accepted that I'm working, and so I should have a work post going.
I'm actually laying in bed goofing around but in my head and on my screen I'm trying to figure out what to do with myself, and that's a kind of work.
1) I can work on my Zeldalike project. I don't want to do that right now because I feel like laying down.
2) I can research Vircadia more. I've been investigating Vircadia on and off for the last few days. It's a relatively new, FLOSS, virtual world system. Sort of like VRChat meets Second Life. I'm thinking about contributing to it. That would take getting up and working on it, too. That said, there are parts I could look at while I'm laying here in bed.
Incidentally I have tested it, and it works, but I haven't connected online yet.
What I could do with Vircadia is look into the coding guidelines and also look at how I'd go about compiling the whole thing. I can't do either in practice on my Chromebook obvs but I can do research on them that might inspire me to get up later.
3) I can work on that story for a friend of mine. I'm still procrastinating on it, and I think part of the problem is my Perfectionism/Fear of Failure. I want to make it as good as it can be and I'm afraid of messing it up, so I just don't touch it. That's no way to finish it, though.
I'm probably going to start with 2 and move to 3 if I can't get myself up after the research. I also want to go to a festival downtown with my Roommate (masked up of course!) but we won't be going until he's done his stream at least, and that gives me around two hours I figure.
So, let's get started with Vircadia research I guess.
5:34pm - I'm getting hungry so I'mma get a snack, then play a game I think.
I ended up looking through some of the Vircadia code and chatted up one of the core devs, and it seems pretty good. They told me about a "Good First Issue" label they use, so I have a few things I might try to fix for them. They also told me the history of the project, which was really cool.
So, the issues I'm thinking of tackling are
https://github.com/vircadia/vircadia/issues/117
and
https://github.com/vircadia/vircadia/issues/989
and we'll see what I can do with them later.
For now, snacks, games, and then Ribfest.
I'm actually laying in bed goofing around but in my head and on my screen I'm trying to figure out what to do with myself, and that's a kind of work.
1) I can work on my Zeldalike project. I don't want to do that right now because I feel like laying down.
2) I can research Vircadia more. I've been investigating Vircadia on and off for the last few days. It's a relatively new, FLOSS, virtual world system. Sort of like VRChat meets Second Life. I'm thinking about contributing to it. That would take getting up and working on it, too. That said, there are parts I could look at while I'm laying here in bed.
Incidentally I have tested it, and it works, but I haven't connected online yet.
What I could do with Vircadia is look into the coding guidelines and also look at how I'd go about compiling the whole thing. I can't do either in practice on my Chromebook obvs but I can do research on them that might inspire me to get up later.
3) I can work on that story for a friend of mine. I'm still procrastinating on it, and I think part of the problem is my Perfectionism/Fear of Failure. I want to make it as good as it can be and I'm afraid of messing it up, so I just don't touch it. That's no way to finish it, though.
I'm probably going to start with 2 and move to 3 if I can't get myself up after the research. I also want to go to a festival downtown with my Roommate (masked up of course!) but we won't be going until he's done his stream at least, and that gives me around two hours I figure.
So, let's get started with Vircadia research I guess.
5:34pm - I'm getting hungry so I'mma get a snack, then play a game I think.
I ended up looking through some of the Vircadia code and chatted up one of the core devs, and it seems pretty good. They told me about a "Good First Issue" label they use, so I have a few things I might try to fix for them. They also told me the history of the project, which was really cool.
So, the issues I'm thinking of tackling are
https://github.com/vircadia/vircadia/issues/117
and
https://github.com/vircadia/vircadia/issues/989
and we'll see what I can do with them later.
For now, snacks, games, and then Ribfest.
6:00pm - It's been a rough couple of days but I'm back.
The last thing I was doing was trying to make sense of the project at this stage.
I think my best bet is to walk through how I think it'll work, and see what problems come up.
So, when the game loads, it starts by building the dungeon. The Dungeon generator procgens up an internal dungeon layout on a grid, making sure everything fits properly and doesn't overlap. Then the rooms matching those properties are selected and instantiated.
The next step is to have the rooms link to one another. Probably the Dungeon will inform each Room what it's connected to, and the Rooms' Doors will be linked.
The player is spawned in next, and the game camera+interface should target them, or maybe be attached...
Once the player's in the starting room the room/s next to it will spawn their monsters/traps in an idle state. This is done by the Dungeon telling the Room that the Player is near, so the Dungeon needs to keep track of where the Player is.
I think the Dungeon will also tell the rooms what their treasure is, if any. It's up to the Dungeon to balance treasure through itself, rather than the rooms.
Okay let's see... a Room will always have a treasure SpawnPoint but unless something is put in it by the Dungeon, it doesn't go off when the room is "Defeated". Treasure rooms with a chest are special, they always get filled by the Dungeon, but they were placed during the Dungeon Generation intentionally.
There will also be monster SpawnPoints and trap Spawnpoints. The specific Monster or Trap will be decided by the Dungeon based on its theme, but the type of Monster or Trap will be decided by the Room. So, if it's a Swamp Dungeon it'll have a Swamp Knight or a Swamp Trap, if it's a Fire Dungeon it'll have a Fire Knight or a Fire Trap. That sort of thing.
Once the Dungeon is spawned and the nearby rooms populated, the game begins.
The player is carried from room to room by the Doors. When the player walks into them it'll play a little animation on both ends as the player exits one room and enters the next.
At this stage I'm not sure if I want the rooms to be right next to eachother and fadeout/fadein as the player switches between them, or if I want the camera restrained to one room then slide over to the next when the player uses a door. Probably the first one though, otherwise it would be hard to hide the neighbor to an L shaped room.
When the player finishes animating entering the room, everything comes to life. Traps trap, Monsters attack, special effects effect.
I'm thinking I'll keep things simple for the AI and not use pathfinding, they'll just use steering mechanics to approach the Player. It'll let them get caught on things but we want to reward that kind of strategy in the player. There'll be different movement types for enemies also so that'll heat things up.
When the player defeats an enemy it's recorded by the Spawnpoint, so it won't respawn when the player leaves and comes back. Any enemies not defeated will be respawned in an idle state when the player leaves the room, so it's the same as other rooms that were next to the player.
When a spawnpoint registers its monster is dead, it reports to the Room, and when all the monsters are dead it releases the treasure, if any, and unlocks the doors if it was a challenge room.
The player and enemies are able to respond to eachother with their own internal systems of collisions. So that should work easily enough.
6:47pm - Yeah I think that's everything for now. I'll add Bosses and Coloured Keys later on after I've got the basics down.
For now I'm feeling stressed so I'm going to take a break. It's only been 48 minutes but it feels like a lot more.
11:32pm - I ended up getting tied up for a few hours and not getting back to this. I dunno if I will tonight. But, I made good progress for the 47 minutes I worked.
The last thing I was doing was trying to make sense of the project at this stage.
I think my best bet is to walk through how I think it'll work, and see what problems come up.
So, when the game loads, it starts by building the dungeon. The Dungeon generator procgens up an internal dungeon layout on a grid, making sure everything fits properly and doesn't overlap. Then the rooms matching those properties are selected and instantiated.
The next step is to have the rooms link to one another. Probably the Dungeon will inform each Room what it's connected to, and the Rooms' Doors will be linked.
The player is spawned in next, and the game camera+interface should target them, or maybe be attached...
Once the player's in the starting room the room/s next to it will spawn their monsters/traps in an idle state. This is done by the Dungeon telling the Room that the Player is near, so the Dungeon needs to keep track of where the Player is.
I think the Dungeon will also tell the rooms what their treasure is, if any. It's up to the Dungeon to balance treasure through itself, rather than the rooms.
Okay let's see... a Room will always have a treasure SpawnPoint but unless something is put in it by the Dungeon, it doesn't go off when the room is "Defeated". Treasure rooms with a chest are special, they always get filled by the Dungeon, but they were placed during the Dungeon Generation intentionally.
There will also be monster SpawnPoints and trap Spawnpoints. The specific Monster or Trap will be decided by the Dungeon based on its theme, but the type of Monster or Trap will be decided by the Room. So, if it's a Swamp Dungeon it'll have a Swamp Knight or a Swamp Trap, if it's a Fire Dungeon it'll have a Fire Knight or a Fire Trap. That sort of thing.
Once the Dungeon is spawned and the nearby rooms populated, the game begins.
The player is carried from room to room by the Doors. When the player walks into them it'll play a little animation on both ends as the player exits one room and enters the next.
At this stage I'm not sure if I want the rooms to be right next to eachother and fadeout/fadein as the player switches between them, or if I want the camera restrained to one room then slide over to the next when the player uses a door. Probably the first one though, otherwise it would be hard to hide the neighbor to an L shaped room.
When the player finishes animating entering the room, everything comes to life. Traps trap, Monsters attack, special effects effect.
I'm thinking I'll keep things simple for the AI and not use pathfinding, they'll just use steering mechanics to approach the Player. It'll let them get caught on things but we want to reward that kind of strategy in the player. There'll be different movement types for enemies also so that'll heat things up.
When the player defeats an enemy it's recorded by the Spawnpoint, so it won't respawn when the player leaves and comes back. Any enemies not defeated will be respawned in an idle state when the player leaves the room, so it's the same as other rooms that were next to the player.
When a spawnpoint registers its monster is dead, it reports to the Room, and when all the monsters are dead it releases the treasure, if any, and unlocks the doors if it was a challenge room.
The player and enemies are able to respond to eachother with their own internal systems of collisions. So that should work easily enough.
6:47pm - Yeah I think that's everything for now. I'll add Bosses and Coloured Keys later on after I've got the basics down.
For now I'm feeling stressed so I'm going to take a break. It's only been 48 minutes but it feels like a lot more.
11:32pm - I ended up getting tied up for a few hours and not getting back to this. I dunno if I will tonight. But, I made good progress for the 47 minutes I worked.
11:52am - I started working around 11am and forgot to post a work post. I've got Mr. Ball animating properly in my game for walking now. I put down a room and the player in the world and they work fine.
That task done it's time to step back and look at the project from a wider view. With everything I'd done before extracted, I have to figure out just how this thing will work.
One example is spawn points. Do I still need them? I think so. I hate to couple independant things together but I think it's neccesary for gameplay, because I don't want the enemies to have to remember their spawn points internally and return to them when the player leaves the room. I don't even want the enemies to stick around when the player leaves the room. If they're still alive, they'll vanish and a fresh one will pop up when the player re-enters the room.
I'll also still want treasure spawnpoints for the loot that appears in a room when the enemies are defeated.
12:14pm - My eye is bugging me so I'm going to take a break.
7:24pm - I laid down for an hour with my eyes shut to let my eye relax, then got stuck in bed for an hour or two, then played some video games, watched an anime episode, went to the grocery store for some food, had a salad while watching another anime episode, and now it's now.
I'm having a bit of trouble getting back into my work headspace.
10:01pm - Never did get back into the headspace, so I'm closing down for now.
That task done it's time to step back and look at the project from a wider view. With everything I'd done before extracted, I have to figure out just how this thing will work.
One example is spawn points. Do I still need them? I think so. I hate to couple independant things together but I think it's neccesary for gameplay, because I don't want the enemies to have to remember their spawn points internally and return to them when the player leaves the room. I don't even want the enemies to stick around when the player leaves the room. If they're still alive, they'll vanish and a fresh one will pop up when the player re-enters the room.
I'll also still want treasure spawnpoints for the loot that appears in a room when the enemies are defeated.
12:14pm - My eye is bugging me so I'm going to take a break.
7:24pm - I laid down for an hour with my eyes shut to let my eye relax, then got stuck in bed for an hour or two, then played some video games, watched an anime episode, went to the grocery store for some food, had a salad while watching another anime episode, and now it's now.
I'm having a bit of trouble getting back into my work headspace.
10:01pm - Never did get back into the headspace, so I'm closing down for now.
7: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.
5:42pm - MORE ART! Let's see how many Baldo sprites I can make today.
5:44pm - ARGH! I opened Paint.net and got smacked by anxiety and dunwannas. This isn't as interesting or engaging as coding is for me, so it's a struggle. I need to psyche myself up I think. Remember all that I'm trying to do. All the people who will use this sprite sheet in the future, not just me.
5:59pm - Bleh. I'm having second thoughts again. I'm putting way too much detail into Baldo and basing him too closely on one of my references. Enough that someone would probably recognize it if they saw it in action, at least 50% the same shape, just different colours... Shoot.
I'll try again with a simpler one. Just a ball. I'll do like I was thinking before and start with the hands and feet instead of the body.
7:21pm - Alright Mr. Ball came along much better than the last three and I've already got a pretty full sheet. I should probably do the rolling/jumping poses but I want to see what these look like in a game first.
7:27pm - Copied all the sprites into a sheet for use, but I'm a little too wiped now from art to do coding. I'm going to take a break at least, maybe pause for the day. We'll see.
11:34pm - Well, no more work today it seems. I did get to relax some after getting quite a bit of work done so I think it's for the best.
5:44pm - ARGH! I opened Paint.net and got smacked by anxiety and dunwannas. This isn't as interesting or engaging as coding is for me, so it's a struggle. I need to psyche myself up I think. Remember all that I'm trying to do. All the people who will use this sprite sheet in the future, not just me.
5:59pm - Bleh. I'm having second thoughts again. I'm putting way too much detail into Baldo and basing him too closely on one of my references. Enough that someone would probably recognize it if they saw it in action, at least 50% the same shape, just different colours... Shoot.
I'll try again with a simpler one. Just a ball. I'll do like I was thinking before and start with the hands and feet instead of the body.
7:21pm - Alright Mr. Ball came along much better than the last three and I've already got a pretty full sheet. I should probably do the rolling/jumping poses but I want to see what these look like in a game first.
7:27pm - Copied all the sprites into a sheet for use, but I'm a little too wiped now from art to do coding. I'm going to take a break at least, maybe pause for the day. We'll see.
11:34pm - Well, no more work today it seems. I did get to relax some after getting quite a bit of work done so I think it's for the best.
1:53pm - More Art! Geez this is more stressful than I thought. I realized a fatal flaw with my gumdrop design so I'm giving it a third go. Before that, though...
You might be wondering why I'm suddenly spriting instead of coding. I reached a point in my code where I needed some sprites to start testing things and making sure they worked. I figured, since I can't find a free sprite set to use for this purpose, why not make my own? And then release it for everyone else to use! A master plan, I think.
So that's what I've been doing, but it's a hard job making sprites, even low quality programmer art sprites, I've found. Maybe it's just my perfectionism creeping in again, I dunno.
But for now, art.
2:17pm - Art is making good progress, and looks good this time. But I need to take a break for my roomie, and maybe afterwards for errands.
1:27am - Report for the day: Went for errands, got new CPAP mask, got a meal, got new shoes for the roomie, got work gloves and trash bags for cleaning a house, then got groceries. Finished off with a bit of game time. All in all it took six hours, then I laid down and now it's too late for work again. At least I got a few sprites down today...
You might be wondering why I'm suddenly spriting instead of coding. I reached a point in my code where I needed some sprites to start testing things and making sure they worked. I figured, since I can't find a free sprite set to use for this purpose, why not make my own? And then release it for everyone else to use! A master plan, I think.
So that's what I've been doing, but it's a hard job making sprites, even low quality programmer art sprites, I've found. Maybe it's just my perfectionism creeping in again, I dunno.
But for now, art.
2:17pm - Art is making good progress, and looks good this time. But I need to take a break for my roomie, and maybe afterwards for errands.
1:27am - Report for the day: Went for errands, got new CPAP mask, got a meal, got new shoes for the roomie, got work gloves and trash bags for cleaning a house, then got groceries. Finished off with a bit of game time. All in all it took six hours, then I laid down and now it's too late for work again. At least I got a few sprites down today...
2:37pm - For most of the last couple hours, and for some time yesterday too, I've been working on art, trying to make 'programmer art' sprites for my game. As usual I went full hog on it and made stuff that was simultaneously too good and unusable.
Lessons learned are helpful but I want something I can use and reuse. I've made and lost 'programmer art' basic dudes too many times and after searching on itch.io I realized there's a niche there to be filled, so when I get a sprite sheet done I'm going to publish it there for pwyw/free. I'm doing it in grayscale so it's easy to recolour/tint, too.
It's a lot of work, though, and not my specialty, so maybe it's a mistake? Whatever, it's what I'm doing...
I'm going to try making a sort of 'Gumdrop' character next. Kind of a truncated capsule.
4:19pm - Getting bored of Pixel Arting. Gonna do something else for a while. It's probably okay, I've apparently been at this almost four hours.
7:24pm - I wasn't able to play any video games but I did run an errand, eat a weird meal, and watch a few anime episodes. I think I can get back to work now.
7:32pm - Now that I look the sheet over though, I'm not sure what else to do with it right now. I want it to have an attack animation, but it's a bit daunting after all the work I've already put in, and it's only nine frames/poses.
7:51pm - Now though I'm getting surprisngly tired, exhausted even. I may take a longer break, or even stop for today.
Hmm... I have other things to do today though, so I'll just leave this open for now and either come back to it or finish it later.
1:40am - Well I napped a bit, got up and made dinner, ate dinner and watched some YouTube with some friends, and now I guess I'm going back to bed. I'll have to work some more tomorrow.
Lessons learned are helpful but I want something I can use and reuse. I've made and lost 'programmer art' basic dudes too many times and after searching on itch.io I realized there's a niche there to be filled, so when I get a sprite sheet done I'm going to publish it there for pwyw/free. I'm doing it in grayscale so it's easy to recolour/tint, too.
It's a lot of work, though, and not my specialty, so maybe it's a mistake? Whatever, it's what I'm doing...
I'm going to try making a sort of 'Gumdrop' character next. Kind of a truncated capsule.
4:19pm - Getting bored of Pixel Arting. Gonna do something else for a while. It's probably okay, I've apparently been at this almost four hours.
7:24pm - I wasn't able to play any video games but I did run an errand, eat a weird meal, and watch a few anime episodes. I think I can get back to work now.
7:32pm - Now that I look the sheet over though, I'm not sure what else to do with it right now. I want it to have an attack animation, but it's a bit daunting after all the work I've already put in, and it's only nine frames/poses.
7:51pm - Now though I'm getting surprisngly tired, exhausted even. I may take a longer break, or even stop for today.
Hmm... I have other things to do today though, so I'll just leave this open for now and either come back to it or finish it later.
1:40am - Well I napped a bit, got up and made dinner, ate dinner and watched some YouTube with some friends, and now I guess I'm going back to bed. I'll have to work some more tomorrow.
2: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.
4:09am - Geez, I've been up for over five hours and I feel like I haven't done anything, which is actually pretty accurate but not completely. I'd say most of what I did was daydream while listening to music and the quiet breathing of my friends in a voicechat where we weren't saying anything. But now that that's over I'm not sure what to do with myself. The obvious choice is to get back to my Zeldalike project, but something is stopping me. I'm not sure why but I don't feel excited about it right now. Usually, or at least while I had that job and soon after I resigned, I felt like "Yes! Let's make the game!" and now it's more like "Yes! Let's lay in bed and listen to music!" which is a whole lot less productive. It's not even new music, I mostly listen to YouTube streams which are the same albums played over and over on loop, but they're so long you only notice when you listen to them all the time like I do.
Anyways I thought I'd try and start a Work Post to either get myself more in the mood to work on my projects or figure out what else I might want to do that's more active than laying in bed. I mean, I'm not against laying in bed entirely, sometimes I do research or watch YouTube on my little chromebook. (That thing was a great purchase) I just find that it's harder to work there than here most of the time.
4:23am - Rob came in on his way to bed, and we talked a bit, but not much before he had to go to sleep. Now I'm alone and still don't know what I want to do with myself.
6:33am - I ended up spending a lot of time listening to music and reading my Twitter feed. Then I tried to push myself into playing video games. I just played a bunch of Phantasy Star Online 2 New Genesis and that was fun. It's a surprisingly fun game given how simple the premise is. Go out and whack enemies with your sword (or other weapon) until they die, with occasional complications.
I think I'm getting close to being able to work some more, but I want to spend a bit more time gaming if I can manage it. (It's gotten hard to play games these days. I don't know why.) I want to explore more of the sort of games I'm making one of, so I'll probably play Sparklite or Moonlighter. If you know any other games like those two I'd like to hear it, more reference materials to research is fun and hopefully makes my own game better.
6:30am - Actually, dawn is coming really quickly, and soon I won't be able to do much on my computer for the sunlight. When that happens, I've decided to do some cleaning up around the apartment. And so, I'm going to eat and watch a show for now.
8:03am - I took out two loads of mostly cardboard waste and also took care of my RAP-PD reapplication. I dunno if they'll accept it this time since I made a lot more in the previous month than usual. But hopefully it works out.
I'm excited because I got paid for my last work at my job, and with the money I was able to pay off the last debt on my credit card and still have enough money saved to pay rent for this month. That way, whatever I get from my Disability is gravy, and I'm also safe in case it's less than I need to pay my rent.
Now, I think I'm finally ready to work on my Zeldalike project.
First up is SpawnPoints for the Rooms.
I have to admit, I'm a bit iffy about the SpawnPoints the way I had imagined them. I was still working on a Roguelike-brain idea when I came up with them. They'd be spread out in all the rooms as potential monster spawns and then the dungeon generator would pick ones to actually have monsters based on the needs of the dungeon. Instead I'm thinking maybe I should do something completely different.
The monsters in a Zeldalike dungeon should reset to their spawnpoints if they're still alive, or not appear if they're dead. I don't want them clustered around the entrance/exit of the player leaves the room and wants to come back.
So I think the Spawnpoints should spawn and manage specific monsters. I figure I can expose a property of the Spawnpoint that is the Actor it spawns. Then I can use it for everything that spawns. Monsters, Keys, Treasure, and even Doors. So, I want it to be functional as well. But to do all that, I really need Actors to work with it.
So, I've got a basic Room, and I've taken out the old dumb spawnpoints. I wasn't going to do Actors until I had more of the Dungeon generator done, but it looks like I need them now. So I'll get started on that.
9:43am - Things have gotten pretty distracting, lots of people talking on Discord and I logged onto a MUCK for whatever reason. Busy busy.
9:52am - Yeah I can't concentrate and stay in 'The Zone' like this, so I'll work on my programming after some of this conversation has died down, I guess.
10:30am - I'm starting to get tired, but I don't want to sleep just yet. I think I'll take out some more stuff, then relax for a while.
11:13am - Alright I'm much more tired now. I don't think I'll be able to do any more coding without a nap at least. I'm going to finish this here and lay down, but we'll see what comes of it after.
Anyways I thought I'd try and start a Work Post to either get myself more in the mood to work on my projects or figure out what else I might want to do that's more active than laying in bed. I mean, I'm not against laying in bed entirely, sometimes I do research or watch YouTube on my little chromebook. (That thing was a great purchase) I just find that it's harder to work there than here most of the time.
4:23am - Rob came in on his way to bed, and we talked a bit, but not much before he had to go to sleep. Now I'm alone and still don't know what I want to do with myself.
6:33am - I ended up spending a lot of time listening to music and reading my Twitter feed. Then I tried to push myself into playing video games. I just played a bunch of Phantasy Star Online 2 New Genesis and that was fun. It's a surprisingly fun game given how simple the premise is. Go out and whack enemies with your sword (or other weapon) until they die, with occasional complications.
I think I'm getting close to being able to work some more, but I want to spend a bit more time gaming if I can manage it. (It's gotten hard to play games these days. I don't know why.) I want to explore more of the sort of games I'm making one of, so I'll probably play Sparklite or Moonlighter. If you know any other games like those two I'd like to hear it, more reference materials to research is fun and hopefully makes my own game better.
6:30am - Actually, dawn is coming really quickly, and soon I won't be able to do much on my computer for the sunlight. When that happens, I've decided to do some cleaning up around the apartment. And so, I'm going to eat and watch a show for now.
8:03am - I took out two loads of mostly cardboard waste and also took care of my RAP-PD reapplication. I dunno if they'll accept it this time since I made a lot more in the previous month than usual. But hopefully it works out.
I'm excited because I got paid for my last work at my job, and with the money I was able to pay off the last debt on my credit card and still have enough money saved to pay rent for this month. That way, whatever I get from my Disability is gravy, and I'm also safe in case it's less than I need to pay my rent.
Now, I think I'm finally ready to work on my Zeldalike project.
First up is SpawnPoints for the Rooms.
I have to admit, I'm a bit iffy about the SpawnPoints the way I had imagined them. I was still working on a Roguelike-brain idea when I came up with them. They'd be spread out in all the rooms as potential monster spawns and then the dungeon generator would pick ones to actually have monsters based on the needs of the dungeon. Instead I'm thinking maybe I should do something completely different.
The monsters in a Zeldalike dungeon should reset to their spawnpoints if they're still alive, or not appear if they're dead. I don't want them clustered around the entrance/exit of the player leaves the room and wants to come back.
So I think the Spawnpoints should spawn and manage specific monsters. I figure I can expose a property of the Spawnpoint that is the Actor it spawns. Then I can use it for everything that spawns. Monsters, Keys, Treasure, and even Doors. So, I want it to be functional as well. But to do all that, I really need Actors to work with it.
So, I've got a basic Room, and I've taken out the old dumb spawnpoints. I wasn't going to do Actors until I had more of the Dungeon generator done, but it looks like I need them now. So I'll get started on that.
9:43am - Things have gotten pretty distracting, lots of people talking on Discord and I logged onto a MUCK for whatever reason. Busy busy.
9:52am - Yeah I can't concentrate and stay in 'The Zone' like this, so I'll work on my programming after some of this conversation has died down, I guess.
10:30am - I'm starting to get tired, but I don't want to sleep just yet. I think I'll take out some more stuff, then relax for a while.
11:13am - Alright I'm much more tired now. I don't think I'll be able to do any more coding without a nap at least. I'm going to finish this here and lay down, but we'll see what comes of it after.
3:56am - Well it looks like sleep was exactly what I needed, and lots of it. I mostly slept through the day today until around 11pm and then daydreamed for another two hours or so... I'm feeling a lot better now though.
I'm still a bit 'out of it' now that I'm nolonger employed, but I'm feeling better and better. I've got to figure out some sort of plan for what to do with myself now, though. I've got the ideas for what I'll do for 'work' done on my previous post, but I still should figure out some way to live a balanced life, with food, rest, and excercise along with my work.
Sitting at the point I am at right now, four am and laid back, I'm not sure I want to do anything, but I also feel a bit bad doing nothing. I don't know if diving back into my work is the best idea, since I'd probably end up doing it until I was exhausted. I just ate a bit ago, so I'm not hungry, and it's four am so going for a walk would be awkward. Some scary weirdos come out at night sometimes. Also it's dark still.
I want to get my life organized but maybe this is the wrong time of day to start. Especially with my sleep schedule fully out of whack. Maybe I SHOULD just dive into my work until I'm exhausted, at least until I can sort things out properly?
Alright I'll put this work post on pause until I get up again and then start some computator work.
4:57am - Alright time for computator work.
The next step of my Zeldalike project is to make the base Room class. Each room should be a composed duplicate of the base Room class.
So what's a room?
A room is a TileMap node to start with. I was going to make it a Node2d but then it would just have a TileMap as its first child with lots of children of the TileMap, so why not skip the extra Node2d?
5:23am - Alright I made a scene based off a TileMap and set up the TileSet using the tiles I created, and boy are they rough. Oh well.
5:31am - Okay enough playing around with my tiles. I need to get back to figuring out what the room needs.
I had an interesting realization; I had been planning on exposing a property of each room to let the Dungeon arrange them by that property, but they won't be instantiated when that info is neccesary, so I'll have to split up the Room plans by type beforehand.
I'm thinking that to start with, I'll have regular rooms, challenge rooms, environmental hazard rooms, and treasure rooms.
Hmm... The Dungeon generator could build a theoretical dungeon in data to make sure it's complete before it starts throwing rooms down. I could also make it so that each room could have 'potential' doors, instead of making the same room over and over with all the doors extant or not...
I'm not sure on that one. The problem is that some rooms would have to have doors in specific places, and mixing potential doors and mandatory doors would be a lot more complicated for the generator.
I'm also thinking that there should be a standard size for the rooms, to make them 'square' on the conceptual map. So oversized rooms would take up multiple squares. Undersized rooms would still take up a square but be partly filled by walls.
I'm thinking that, including wall tiles, each room should be 10x12. It's a ways short of the X extants of my camera view, and just past the Y extants. It's also comparable to the room sizes in the Legend of Zelda games, a little bigger than Link's Awakening and a little smaller than LttP. I think the normal room size in Binding of Issac is 9x15 for a more modern comparison. Actually I looked at Moonlighter and it looks like they used the same scale as BoI, maybe I should do that since my Camera is different from the ones in those old zelda games?
6:28am - Alright after playing with it a bit I'm going to set the default room to 15x9, and I can change it later if I need to.
Another thing I'm thinking about is doors/exits. Should they be Actors? They'd be standing on the walls, which will be physics blocking. I suppose since I'm making my Actors with composition, they don't need to have a physics presence, so they couldn't be bumped or pushed accidentally anyways. But what about their function?
You don't close doors anymore, it's zeldalike. Monsters don't go through doors, only the player does. Sometimes the doors are locked, though. And there might be a variety of types of door, like one way doors maybe? And doors that lock when you enter the room, so you have to have a key to go back, or defeat a challenge.
Alright I'll leave the doors as Actors for now. In theory, anyways, since I haven't actually MADE doors yet...
The other thing rooms need is a varety of point types to show where the Dungeon could place things if it wanted to. I guess they'd be SpawnPoints.
6:46am - I've put in some Position2Ds to serve as spawn points, but I'm again wondering about the doors and alternative room sizes. It's stressing me out enough I might stop for a bit, take a break and come back.
7:56am - I played PSO2:NGS for about an hour, and now I'm thinking about having a shower. I'm planning to go get a haircut and do some errands at 9am so I want to do the shower beforehand. That gives me an hour, and it usually takes me 20-30 minutes to have a shower.
Ahh well I'll do it now, get it out of the way and dry off while I wait for go time.
10:42am - I went out and got my hair cut, and got a few things from the grocery store, and I'm back. I just spent a little time looking up info on Video Game Reviewing and it's pretty intimidating. For a lot of people, that's their whole job, and I'm looking at it as a sideline. My main thing is my programming work.
11:57am - Well I've been messing around on Discord and Twitter for around an hour it looks like. I've gotten tired at last so I'm going to lay down, but my roomie is probably going to get me up in an hour or two to play Heroclix on his twitch stream, so we'll see how that goes.
For now I'm going to switch computers and load this on my chromebook to continue.
12:06pm - Now on the chromebook. I'm probably just going to roll over and sleep at any moment but until then I wanted to think some more about my Zeldalike project.
I'm thinking for example that I should change the Position2d nodes I'm using for spawn points into their own thing, with scripting, and signal hooks.
I'm thinking the Dungeon generation is going to go something like this. First the Dungeon Generator picks what style of dungeon it's going to make. I'm planning at least two styles, linear and grand hall. The first is basically a line, maybe curvy, that has side passages that loop back to the main line at the end. The grand hall style will have a big main room the size of, probably six normal rooms, and it'll have multiple doors leading off of it to side routes that have loot or keys at the end, until you find the big key and open the boss door in the grand hall or maybe a little past it.
After the dungeon style is picked, an internal grid is formed to represent the dungeon, and areas are blocked out procgen style with the rooms based on various forms of logic and patterns. The rooms are only instantiated when the player is one room away from it, though, So as to keep resources freed up.... maybe. I'll experiment with it. I don't want monsters respawning every time the player goes two rooms away.
When it comes time to generate one of the rooms, it places monsters in the spawn points based on how difficult of a challenge that particular room should be, and the challenge of the dungeon as a whole. It also places the treasures and such.
The doors on the edges of the rooms are connected to eachother and that's basically it. Now that I've spelled it out it sounds a lot easier than I was thinking.
12:27pm - I'll have to try and put it together later along with the special Position2d spawners. For now I'm very tired and gonna sleep some.
I'm still a bit 'out of it' now that I'm nolonger employed, but I'm feeling better and better. I've got to figure out some sort of plan for what to do with myself now, though. I've got the ideas for what I'll do for 'work' done on my previous post, but I still should figure out some way to live a balanced life, with food, rest, and excercise along with my work.
Sitting at the point I am at right now, four am and laid back, I'm not sure I want to do anything, but I also feel a bit bad doing nothing. I don't know if diving back into my work is the best idea, since I'd probably end up doing it until I was exhausted. I just ate a bit ago, so I'm not hungry, and it's four am so going for a walk would be awkward. Some scary weirdos come out at night sometimes. Also it's dark still.
I want to get my life organized but maybe this is the wrong time of day to start. Especially with my sleep schedule fully out of whack. Maybe I SHOULD just dive into my work until I'm exhausted, at least until I can sort things out properly?
Alright I'll put this work post on pause until I get up again and then start some computator work.
4:57am - Alright time for computator work.
The next step of my Zeldalike project is to make the base Room class. Each room should be a composed duplicate of the base Room class.
So what's a room?
A room is a TileMap node to start with. I was going to make it a Node2d but then it would just have a TileMap as its first child with lots of children of the TileMap, so why not skip the extra Node2d?
5:23am - Alright I made a scene based off a TileMap and set up the TileSet using the tiles I created, and boy are they rough. Oh well.
5:31am - Okay enough playing around with my tiles. I need to get back to figuring out what the room needs.
I had an interesting realization; I had been planning on exposing a property of each room to let the Dungeon arrange them by that property, but they won't be instantiated when that info is neccesary, so I'll have to split up the Room plans by type beforehand.
I'm thinking that to start with, I'll have regular rooms, challenge rooms, environmental hazard rooms, and treasure rooms.
Hmm... The Dungeon generator could build a theoretical dungeon in data to make sure it's complete before it starts throwing rooms down. I could also make it so that each room could have 'potential' doors, instead of making the same room over and over with all the doors extant or not...
I'm not sure on that one. The problem is that some rooms would have to have doors in specific places, and mixing potential doors and mandatory doors would be a lot more complicated for the generator.
I'm also thinking that there should be a standard size for the rooms, to make them 'square' on the conceptual map. So oversized rooms would take up multiple squares. Undersized rooms would still take up a square but be partly filled by walls.
I'm thinking that, including wall tiles, each room should be 10x12. It's a ways short of the X extants of my camera view, and just past the Y extants. It's also comparable to the room sizes in the Legend of Zelda games, a little bigger than Link's Awakening and a little smaller than LttP. I think the normal room size in Binding of Issac is 9x15 for a more modern comparison. Actually I looked at Moonlighter and it looks like they used the same scale as BoI, maybe I should do that since my Camera is different from the ones in those old zelda games?
6:28am - Alright after playing with it a bit I'm going to set the default room to 15x9, and I can change it later if I need to.
Another thing I'm thinking about is doors/exits. Should they be Actors? They'd be standing on the walls, which will be physics blocking. I suppose since I'm making my Actors with composition, they don't need to have a physics presence, so they couldn't be bumped or pushed accidentally anyways. But what about their function?
You don't close doors anymore, it's zeldalike. Monsters don't go through doors, only the player does. Sometimes the doors are locked, though. And there might be a variety of types of door, like one way doors maybe? And doors that lock when you enter the room, so you have to have a key to go back, or defeat a challenge.
Alright I'll leave the doors as Actors for now. In theory, anyways, since I haven't actually MADE doors yet...
The other thing rooms need is a varety of point types to show where the Dungeon could place things if it wanted to. I guess they'd be SpawnPoints.
6:46am - I've put in some Position2Ds to serve as spawn points, but I'm again wondering about the doors and alternative room sizes. It's stressing me out enough I might stop for a bit, take a break and come back.
7:56am - I played PSO2:NGS for about an hour, and now I'm thinking about having a shower. I'm planning to go get a haircut and do some errands at 9am so I want to do the shower beforehand. That gives me an hour, and it usually takes me 20-30 minutes to have a shower.
Ahh well I'll do it now, get it out of the way and dry off while I wait for go time.
10:42am - I went out and got my hair cut, and got a few things from the grocery store, and I'm back. I just spent a little time looking up info on Video Game Reviewing and it's pretty intimidating. For a lot of people, that's their whole job, and I'm looking at it as a sideline. My main thing is my programming work.
11:57am - Well I've been messing around on Discord and Twitter for around an hour it looks like. I've gotten tired at last so I'm going to lay down, but my roomie is probably going to get me up in an hour or two to play Heroclix on his twitch stream, so we'll see how that goes.
For now I'm going to switch computers and load this on my chromebook to continue.
12:06pm - Now on the chromebook. I'm probably just going to roll over and sleep at any moment but until then I wanted to think some more about my Zeldalike project.
I'm thinking for example that I should change the Position2d nodes I'm using for spawn points into their own thing, with scripting, and signal hooks.
I'm thinking the Dungeon generation is going to go something like this. First the Dungeon Generator picks what style of dungeon it's going to make. I'm planning at least two styles, linear and grand hall. The first is basically a line, maybe curvy, that has side passages that loop back to the main line at the end. The grand hall style will have a big main room the size of, probably six normal rooms, and it'll have multiple doors leading off of it to side routes that have loot or keys at the end, until you find the big key and open the boss door in the grand hall or maybe a little past it.
After the dungeon style is picked, an internal grid is formed to represent the dungeon, and areas are blocked out procgen style with the rooms based on various forms of logic and patterns. The rooms are only instantiated when the player is one room away from it, though, So as to keep resources freed up.... maybe. I'll experiment with it. I don't want monsters respawning every time the player goes two rooms away.
When it comes time to generate one of the rooms, it places monsters in the spawn points based on how difficult of a challenge that particular room should be, and the challenge of the dungeon as a whole. It also places the treasures and such.
The doors on the edges of the rooms are connected to eachother and that's basically it. Now that I've spelled it out it sounds a lot easier than I was thinking.
12:27pm - I'll have to try and put it together later along with the special Position2d spawners. For now I'm very tired and gonna sleep some.
4:31am - I need to remember sometimes this journal is for all kinds of work, not just my coding. I did a bit of art earlier today for my Zeldalike project, but that's not what I'm here to write about either.
I resigned from my job and got it confirmed that it went through, so I'm unemployed again. I have to figure out what I'm going to do next.
I've been struggling both to find work and to find a way to make money on my own for the longest time, and now, well, if I can't do the job I just resigned from, I can't do any sort of normal 'work' so I have to lean harder on the latter.
I've had a few ideas I've been working on. One is to keep going as I have and finish this prototype, maybe make it into a game that I can sell or convince people to pay me to improve. That's something I'll probably be doing anyways, though.
Prior to taking this job I was exploring a few options, and one of them was Game Review Blogging. My roommate I think was the one who suggested it, that in order to enjoy playing video games again I might try writing about them. He found new joy in games by streaming, but that's not for me. So I think I'll be trying to work on my Game Blog, though it's a little intimidating.
Then there's the tutorials. I've been thinking of making Tutorials for Godot, but I'm not sure I have anything to add to what's already out there, and when I've gone looking for things people know they don't know, I haven't found anything.
I was also thinking about tutoring, but I'm not sure I can do that now that I'm so far removed from education. I mean, I might be able to tutor teens or kids on programming or game development, but it'd be hard for me to tutor CS degree university students when I have no CS degree of my own, and my education while formal was primarily on subjects that are irrelevant today. I've also never used the services of a tutor, so I don't know what to expect. Maybe I should invest in a tutoring tutor?
I've got a few possibilities here, but no guarantees. I'll pretty much certainly keep working on my programming projects, because that's just what I do, but I also think I'll be able to do the game blogging as I play games to relax from coding and review them. The tutorials will be quite a bit of work, and I need to figure out what I want to teach, and maybe they'd just get in the way of my programming projects, so I'll put it in the maybe pile.
Tutoring is kind of scary, but intriguing. So I'll consider it for now.
That gives me two main things to do for now.
I'd also like to try and organize my life a bit more, now that my schedule is open again. Get some exercise and proper diet in there maybe.
The other thing is sleep of course, and I'm exhausted right now, so I'm going to finish this here and go to bed.
5:29am - Good night.
I resigned from my job and got it confirmed that it went through, so I'm unemployed again. I have to figure out what I'm going to do next.
I've been struggling both to find work and to find a way to make money on my own for the longest time, and now, well, if I can't do the job I just resigned from, I can't do any sort of normal 'work' so I have to lean harder on the latter.
I've had a few ideas I've been working on. One is to keep going as I have and finish this prototype, maybe make it into a game that I can sell or convince people to pay me to improve. That's something I'll probably be doing anyways, though.
Prior to taking this job I was exploring a few options, and one of them was Game Review Blogging. My roommate I think was the one who suggested it, that in order to enjoy playing video games again I might try writing about them. He found new joy in games by streaming, but that's not for me. So I think I'll be trying to work on my Game Blog, though it's a little intimidating.
Then there's the tutorials. I've been thinking of making Tutorials for Godot, but I'm not sure I have anything to add to what's already out there, and when I've gone looking for things people know they don't know, I haven't found anything.
I was also thinking about tutoring, but I'm not sure I can do that now that I'm so far removed from education. I mean, I might be able to tutor teens or kids on programming or game development, but it'd be hard for me to tutor CS degree university students when I have no CS degree of my own, and my education while formal was primarily on subjects that are irrelevant today. I've also never used the services of a tutor, so I don't know what to expect. Maybe I should invest in a tutoring tutor?
I've got a few possibilities here, but no guarantees. I'll pretty much certainly keep working on my programming projects, because that's just what I do, but I also think I'll be able to do the game blogging as I play games to relax from coding and review them. The tutorials will be quite a bit of work, and I need to figure out what I want to teach, and maybe they'd just get in the way of my programming projects, so I'll put it in the maybe pile.
Tutoring is kind of scary, but intriguing. So I'll consider it for now.
That gives me two main things to do for now.
I'd also like to try and organize my life a bit more, now that my schedule is open again. Get some exercise and proper diet in there maybe.
The other thing is sleep of course, and I'm exhausted right now, so I'm going to finish this here and go to bed.
5:29am - Good night.
1:26am - Tonight's TTRPG game was a short one since we weren't all feeling up to it. We ended on a nice cliffhanger. I talked with the guys afterwards about my thoughts with regard to my project, and came to the conclusion that...
Yes, I am going to pivot.
I'll start by making a fork of my Roguelike project to serve as the base.
...
Okay so GitHub won't let me fork my own projects since I'm not an organization. That's fine, we can get around that... I'll just copy it as is locally and make a NEW repo.
1:49am - Okay that worked fine. Now I've got my new Zeldalike Project started.
The next part comes with lots of thinking. How is this going to work, and what can I save of my previous work?
1:58am - I think I want to compare how others have tackled this sort of thing in the past, so I'm going to skim over some tutorials and guides first.
2:34am - After skimming over some tutorials and guides I'm not sure what I expected to figure out. I think I just did it to comfort myself. ^.^;;
I think I'm going to save this and lay down to work on it more in thoughtful repose.
2:54am - That's better. Thoughtful repose is great.
Now, the first big difference between how I've been doing things and how things will go from here out is switching from a turn-based game to a real-time game. I'd like to keep my idea of using AICores to control the characters, and Actions to handle interactions, but I may have to rewrite some of that. On the other hand I was also thinking it would be good to use this pivot to press more on Godot's signal system. I had already been planning to tie together the action methods to the GUI using signals. I could transfer most of the game's data that way.
I'd really like to be able to do this game more 'Godot' style, with clearly seperated, independant pieces, instead of hard coded classes.
I'd like to be able to drag the RandomLevel into the world and have it generate a level right there, with a seed set up and the whole thing drawn so that it would run like that.
Then I could drag in a Player and a monster or two, start up the simulation, and play it.
The way I had been working before, almost everything is generated at runtime, so it wasn't very Godot'y.
I'd still like the Actors in the game to use the same system, though. So I'd probably build them through composition in the editor rather than in an ActorFactory.
I'm not sure if you can save seperate scenes using the same user made base class as the node or not. I should test that.
For now I'm pretty sure that you can. At any rate, I'd make different Actors and give them different AICores.
4:45am - I got interrupted while I was working earlier, around 3 am. After that I had a lunch and now I'm back.
So I was talking about the Actors. I'm not sure if Items, Doors, Chests and Effects should still be actors or not, since they won't be interacting in the same ways anymore. I could probably keep it the same as it is but I'm not sure... Well, let's keep it the same until it needs to change. It was a good idea before and I can always change it later.
Thinking about it, the Actor scenes will have to have more as well, since they'll be interacting with the physics system now. So each actor will need its own Area2Ds for hitboxes and hurtboxes when neccesary. Let's look at that for a moment.
A Player or Enemy would have a collision area, and also one or more hitboxes which would determine where they could be attacked. Then they would generate hurtboxes when they attacked. That'll take a lot of work and tweaking to get right, so I'll save most of it for later on. But each of those collision areas would need to be connected to the Actor script somehow. Since they'll be different for each Actor, and not every Actor will have them, I'll probably have to expose array properties on the Actor, and connect each of them up based on their type.
Yeah I think it all makes sense.
5:05am - Alright, so let's see...
I need to create a drag and drop randomly generated map system, the sort of thing this whole idea was based around, first. That'll give the player someplace to stand.
It'll need Actors for the doors, but I can add them after I get the basics done on the map generator.
So the Actor modifications will come after making the Dungeon generator.
What about the turn and action pumps... Right now, they go through all of the AICores until a player's turn comes up, then it waits for input. Going forward, since it'll be real time, I'll have to poll all the AICores every frame.
That might be a little intense, though. I'll have to put a StateMachine in the AICores to make them only have to think hard now and then, so they don't do a big pathfind every frame they can see the player. We'll see what's neccesary when I get to that stage.
I guess adding a GUI will come at that stage. I don't know if I'll save my current GUI, it's super simple and doesn't work like I'll need.
After that, well, it's almost done isn't it? There were a lot more steps in my Roguelike TODO list, and they were very broad strokes. Maybe this game will be easier to make than I expected? We'll see.
For now I'll make a TODO list for these tasks, since I've found they're a great way to keep on task and motivated.
TODO:
Create the Dungeon generator
Modify the turn and action pumps to run every Actor every frame
Modify the Actor class for real-time operation
Create a Player Actor Scene
Create an Enemy Actor Scene
Create a Door Actor Scene
Make the rest of the game
That first one is kind of a doozey. Let's break it down into some sub goals.
...
5:33am - It occurs to me that I'm not 100% sure where to start, so the first goal will be to figure that out, right now.
The Dungeon class will hold the whole thing together, it's what you drag in to make a dungeon. The dungeon will be made out of pregenerated "Rooms" though, so I'll have to make them myself, in-editor. Hmm... Now that I think of it, I could make a room first instead of the dungeon generator, then get the actors on it. But nah, at this point I think I should make as much of the dungeon generator as I can, since this whole thing is a proof of concept for that.
Each Room will be able to connect to at least one other room. Usually more than one, since dungeons are made of cycles or circular interconnecting pathways. The Dungeon will arrange these rooms and add in gameplay elements as neccesary, probably along points by my design.
One thing I'm considering is having the rooms be designed simply, and replace their art resources depending on the needs of the dungeon. So if it's a blue swamp dungeon, it uses these tiles in these colours, if it's a red fire dungeon it uses these tiles in these colours, etc.
I wonder exactly what rooms I'll need. It's been a while since I first thought up this dungeon design style and I don't think I fully covered that. I know there'll be rooms with environmental hazards, rooms with monsters, and challenge rooms you have to defeat to progress. There'll be treasure rooms and maybe puzzle rooms? I dunno about that last one.
Alright, so I think I've got my steps now.
Prepare the Dungeon Art
Create Rooms
Fit the rooms together with the Dungeon Generator
I'll probably add more steps as I go along and realize what's neccesary. For now I guess the next step is to get the dungeon tiles ready.
I'm going to save this and head back to my main machine, and maybe do that.
5:53am - Alright so it occurs to me now that it's almost six am and I'm kind of tired, so I don't know how much arting I'll be able to do, but I'll give it a shot.
6:42am - Wow, almost an hour of arting alone. Well I still have more to do, I've been experimenting a bit more than neccesary. XD
Now it's bed time. Good night, everybody!
Yes, I am going to pivot.
I'll start by making a fork of my Roguelike project to serve as the base.
...
Okay so GitHub won't let me fork my own projects since I'm not an organization. That's fine, we can get around that... I'll just copy it as is locally and make a NEW repo.
1:49am - Okay that worked fine. Now I've got my new Zeldalike Project started.
The next part comes with lots of thinking. How is this going to work, and what can I save of my previous work?
1:58am - I think I want to compare how others have tackled this sort of thing in the past, so I'm going to skim over some tutorials and guides first.
2:34am - After skimming over some tutorials and guides I'm not sure what I expected to figure out. I think I just did it to comfort myself. ^.^;;
I think I'm going to save this and lay down to work on it more in thoughtful repose.
2:54am - That's better. Thoughtful repose is great.
Now, the first big difference between how I've been doing things and how things will go from here out is switching from a turn-based game to a real-time game. I'd like to keep my idea of using AICores to control the characters, and Actions to handle interactions, but I may have to rewrite some of that. On the other hand I was also thinking it would be good to use this pivot to press more on Godot's signal system. I had already been planning to tie together the action methods to the GUI using signals. I could transfer most of the game's data that way.
I'd really like to be able to do this game more 'Godot' style, with clearly seperated, independant pieces, instead of hard coded classes.
I'd like to be able to drag the RandomLevel into the world and have it generate a level right there, with a seed set up and the whole thing drawn so that it would run like that.
Then I could drag in a Player and a monster or two, start up the simulation, and play it.
The way I had been working before, almost everything is generated at runtime, so it wasn't very Godot'y.
I'd still like the Actors in the game to use the same system, though. So I'd probably build them through composition in the editor rather than in an ActorFactory.
I'm not sure if you can save seperate scenes using the same user made base class as the node or not. I should test that.
For now I'm pretty sure that you can. At any rate, I'd make different Actors and give them different AICores.
4:45am - I got interrupted while I was working earlier, around 3 am. After that I had a lunch and now I'm back.
So I was talking about the Actors. I'm not sure if Items, Doors, Chests and Effects should still be actors or not, since they won't be interacting in the same ways anymore. I could probably keep it the same as it is but I'm not sure... Well, let's keep it the same until it needs to change. It was a good idea before and I can always change it later.
Thinking about it, the Actor scenes will have to have more as well, since they'll be interacting with the physics system now. So each actor will need its own Area2Ds for hitboxes and hurtboxes when neccesary. Let's look at that for a moment.
A Player or Enemy would have a collision area, and also one or more hitboxes which would determine where they could be attacked. Then they would generate hurtboxes when they attacked. That'll take a lot of work and tweaking to get right, so I'll save most of it for later on. But each of those collision areas would need to be connected to the Actor script somehow. Since they'll be different for each Actor, and not every Actor will have them, I'll probably have to expose array properties on the Actor, and connect each of them up based on their type.
Yeah I think it all makes sense.
5:05am - Alright, so let's see...
I need to create a drag and drop randomly generated map system, the sort of thing this whole idea was based around, first. That'll give the player someplace to stand.
It'll need Actors for the doors, but I can add them after I get the basics done on the map generator.
So the Actor modifications will come after making the Dungeon generator.
What about the turn and action pumps... Right now, they go through all of the AICores until a player's turn comes up, then it waits for input. Going forward, since it'll be real time, I'll have to poll all the AICores every frame.
That might be a little intense, though. I'll have to put a StateMachine in the AICores to make them only have to think hard now and then, so they don't do a big pathfind every frame they can see the player. We'll see what's neccesary when I get to that stage.
I guess adding a GUI will come at that stage. I don't know if I'll save my current GUI, it's super simple and doesn't work like I'll need.
After that, well, it's almost done isn't it? There were a lot more steps in my Roguelike TODO list, and they were very broad strokes. Maybe this game will be easier to make than I expected? We'll see.
For now I'll make a TODO list for these tasks, since I've found they're a great way to keep on task and motivated.
TODO:
Create the Dungeon generator
Modify the turn and action pumps to run every Actor every frame
Modify the Actor class for real-time operation
Create a Player Actor Scene
Create an Enemy Actor Scene
Create a Door Actor Scene
Make the rest of the game
That first one is kind of a doozey. Let's break it down into some sub goals.
...
5:33am - It occurs to me that I'm not 100% sure where to start, so the first goal will be to figure that out, right now.
The Dungeon class will hold the whole thing together, it's what you drag in to make a dungeon. The dungeon will be made out of pregenerated "Rooms" though, so I'll have to make them myself, in-editor. Hmm... Now that I think of it, I could make a room first instead of the dungeon generator, then get the actors on it. But nah, at this point I think I should make as much of the dungeon generator as I can, since this whole thing is a proof of concept for that.
Each Room will be able to connect to at least one other room. Usually more than one, since dungeons are made of cycles or circular interconnecting pathways. The Dungeon will arrange these rooms and add in gameplay elements as neccesary, probably along points by my design.
One thing I'm considering is having the rooms be designed simply, and replace their art resources depending on the needs of the dungeon. So if it's a blue swamp dungeon, it uses these tiles in these colours, if it's a red fire dungeon it uses these tiles in these colours, etc.
I wonder exactly what rooms I'll need. It's been a while since I first thought up this dungeon design style and I don't think I fully covered that. I know there'll be rooms with environmental hazards, rooms with monsters, and challenge rooms you have to defeat to progress. There'll be treasure rooms and maybe puzzle rooms? I dunno about that last one.
Alright, so I think I've got my steps now.
Prepare the Dungeon Art
Create Rooms
Fit the rooms together with the Dungeon Generator
I'll probably add more steps as I go along and realize what's neccesary. For now I guess the next step is to get the dungeon tiles ready.
I'm going to save this and head back to my main machine, and maybe do that.
5:53am - Alright so it occurs to me now that it's almost six am and I'm kind of tired, so I don't know how much arting I'll be able to do, but I'll give it a shot.
6:42am - Wow, almost an hour of arting alone. Well I still have more to do, I've been experimenting a bit more than neccesary. XD
Now it's bed time. Good night, everybody!
9:06pm - So, last night I had some heavy feelings and it brought me down to wondering what I was doing with myself, again. I figure it would be a good idea to talk about it and help myself be soothed.
The goal I set for my Roguelike Project was to test the theory of procgen dungeon design I had thought up. I needed a game that would use procgen dungeons to test it, and I had already started a Roguelike game from 7DRL this year, so I used that.
I've made some good progress on it, but now I find myself questioning my choices and what I'll do next. I do enjoy the occasional roguelike, but it's not my favorite genre, and often I think this would be better tested and done with a Zelda-like action adventure real time style instead of a turn based dungeon crawler.
I'm really conflicted because I don't want to pivot so much after coming so far on my Roguelike Project, but I worry that's just the sunk cost fallacy slipping in. What's the point of finishing a roguelike if that's not the sort of game I want to make? And yet, there are other goals that have been slipping in as the project continues, like making the whole thing open source so that others can follow the path I carved. What does that have to do with testing my theory of procgen dungeon design?
There's a ton of Roguelikes out there already, even if there aren't any open source made with Godot. I'm not exactly treading new ground. On the other hand, the whole point of this is to do what I want, and perhaps make some money along the way.
I was thinking of making this Roguelike Project into my next big thing that I wouldn't stop until I was done, but now I'm questioning if I should even keep going or pivot into something else.
I don't think this is something that should be a snap decision anyways. I'll have to think about it. But let's consider it.
A lot of what I've done I can keep from the Roguelike Game to the Zeldalike Game, so I wouldn't be starting from scratch, but there would be a lot of things I'd have to change or make new. It's also early enough in the game's development that big pivots can still happen; it may seem like I've gotten really far but that's just because I'm working alone.
Before I was writing this as a result of my deep dark emotional period last night, I had been thinking about exploring what I would have done differently if I had focused more on making the game in the Godot 'style' using Signals more. I wouldn't want to redo the work I had already done but I could think about what I might have done differently.
I think that's still worthwhile, and it might shed some light into this problem I'm having. I was thinking at the start of this post that I'd figure out that it was better to keep on the Roguelike path, but now I'm not so sure. So I'll do that.
9:55pm - But I'm short on time, so I'll post this for now.
The goal I set for my Roguelike Project was to test the theory of procgen dungeon design I had thought up. I needed a game that would use procgen dungeons to test it, and I had already started a Roguelike game from 7DRL this year, so I used that.
I've made some good progress on it, but now I find myself questioning my choices and what I'll do next. I do enjoy the occasional roguelike, but it's not my favorite genre, and often I think this would be better tested and done with a Zelda-like action adventure real time style instead of a turn based dungeon crawler.
I'm really conflicted because I don't want to pivot so much after coming so far on my Roguelike Project, but I worry that's just the sunk cost fallacy slipping in. What's the point of finishing a roguelike if that's not the sort of game I want to make? And yet, there are other goals that have been slipping in as the project continues, like making the whole thing open source so that others can follow the path I carved. What does that have to do with testing my theory of procgen dungeon design?
There's a ton of Roguelikes out there already, even if there aren't any open source made with Godot. I'm not exactly treading new ground. On the other hand, the whole point of this is to do what I want, and perhaps make some money along the way.
I was thinking of making this Roguelike Project into my next big thing that I wouldn't stop until I was done, but now I'm questioning if I should even keep going or pivot into something else.
I don't think this is something that should be a snap decision anyways. I'll have to think about it. But let's consider it.
A lot of what I've done I can keep from the Roguelike Game to the Zeldalike Game, so I wouldn't be starting from scratch, but there would be a lot of things I'd have to change or make new. It's also early enough in the game's development that big pivots can still happen; it may seem like I've gotten really far but that's just because I'm working alone.
Before I was writing this as a result of my deep dark emotional period last night, I had been thinking about exploring what I would have done differently if I had focused more on making the game in the Godot 'style' using Signals more. I wouldn't want to redo the work I had already done but I could think about what I might have done differently.
I think that's still worthwhile, and it might shed some light into this problem I'm having. I was thinking at the start of this post that I'd figure out that it was better to keep on the Roguelike path, but now I'm not so sure. So I'll do that.
9:55pm - But I'm short on time, so I'll post this for now.
12:30am - The mental illness has been riding me hard the last few days. I'm not sure what to do with myself.
I've had a lot of time to try and rest and relax, but I haven't really wanted to do anything. I sort-of want to work on my project, but I've been too out of it most of the day, and now the call is on. I figured I'd try it anyways but time has been slipping by too quickly. It's already...
12:44am - Anyways my next task in the TODO list is to make the Use component, for later. I think I'll lower it on the TODO list because later is too far away; I have nothing to 'use' right now.
The next one is Make a Zombie Enemy. But I think something is missing. I've pulled the GUI off the player and made it follow the active player, but it doesn't do anything anymore.
The problem I've got is, if there's more than one player character, does it show the character it's highlighting? Or is there a 'main' player that it always shows the stats of?
I'm not sure. Maybe I shouldn't even have the stats of the characters taking up a big window of the interface like it does.
Maybe I should do some research.
1:20am - I did some research. Similar games have transparent backgrounds rather than solid windows and lower impact GUIs. I think I'll completely re-do the GUI later. For now I just want to get the text log working again.
1:31am - The more I think about it the more I think I'd have to do all the work again when I redo the GUI anyways.
I could use the print function to output to the console log instead, but then it would also make more work, because I would have to replace the code later that put the text in the log into the other log.
I think it would be better for me to just redo the GUI now. But for that I need to solidify the design, and I'm feeling REALLY off right now, so I'm going to take a break.
2:54am - So I've been trying to think of ways to connect the Log in the GUI to the actual signals. If I have each Actor output a different signal for every action, that would be a heck of a lot of hookups for every Actor that I generate. Alternatively I could use one signal for all the actions an Actor can perform, but give it a note or something saying which one it was along with the other variables. But I'd still have to hook up every actor.
One thing I'm considering is putting the notifications for the GUI Log in the Action Pumps instead. Since the two action pumps are in the Level class, all the GUI has to do is watch for signals from Level. The tricky thing though is that Level only works with the Action parent class. The subclasses are different and they have the information.
Maybe I could put the signals in the Actions themselves? But that would only make it more confusing, if every action had to be linked to the GUI.
I could have the Actions return something to put on the log when their execute() method is run, and the Level class could put that into a signal that the GUI, or anything else, could read. I think that would work. The returned value can be ignored, also, in case the Level and Actions are too tightly coupled.
Hmm... but the Actions don't know much about the actions they do, they only tell the Actors to do them, and carry the info of the targets.
So again I have to go back to the Actor class putting out the notes when its functions are executed. But at least I think using a LogNote class would be easier than having a unique signal for every action method.
Alright. I'll modify the Actor class to emit a signal with a LogNote, and make a LogNote class itself.
4:11am - It took a while due to some strange behavior but I've got the log filling up again.
Next up I make a Zombie, along with all its parts, and make it approach and attack the player.
For now though, I need another break, and maybe a sleep.
I've had a lot of time to try and rest and relax, but I haven't really wanted to do anything. I sort-of want to work on my project, but I've been too out of it most of the day, and now the call is on. I figured I'd try it anyways but time has been slipping by too quickly. It's already...
12:44am - Anyways my next task in the TODO list is to make the Use component, for later. I think I'll lower it on the TODO list because later is too far away; I have nothing to 'use' right now.
The next one is Make a Zombie Enemy. But I think something is missing. I've pulled the GUI off the player and made it follow the active player, but it doesn't do anything anymore.
The problem I've got is, if there's more than one player character, does it show the character it's highlighting? Or is there a 'main' player that it always shows the stats of?
I'm not sure. Maybe I shouldn't even have the stats of the characters taking up a big window of the interface like it does.
Maybe I should do some research.
1:20am - I did some research. Similar games have transparent backgrounds rather than solid windows and lower impact GUIs. I think I'll completely re-do the GUI later. For now I just want to get the text log working again.
1:31am - The more I think about it the more I think I'd have to do all the work again when I redo the GUI anyways.
I could use the print function to output to the console log instead, but then it would also make more work, because I would have to replace the code later that put the text in the log into the other log.
I think it would be better for me to just redo the GUI now. But for that I need to solidify the design, and I'm feeling REALLY off right now, so I'm going to take a break.
2:54am - So I've been trying to think of ways to connect the Log in the GUI to the actual signals. If I have each Actor output a different signal for every action, that would be a heck of a lot of hookups for every Actor that I generate. Alternatively I could use one signal for all the actions an Actor can perform, but give it a note or something saying which one it was along with the other variables. But I'd still have to hook up every actor.
One thing I'm considering is putting the notifications for the GUI Log in the Action Pumps instead. Since the two action pumps are in the Level class, all the GUI has to do is watch for signals from Level. The tricky thing though is that Level only works with the Action parent class. The subclasses are different and they have the information.
Maybe I could put the signals in the Actions themselves? But that would only make it more confusing, if every action had to be linked to the GUI.
I could have the Actions return something to put on the log when their execute() method is run, and the Level class could put that into a signal that the GUI, or anything else, could read. I think that would work. The returned value can be ignored, also, in case the Level and Actions are too tightly coupled.
Hmm... but the Actions don't know much about the actions they do, they only tell the Actors to do them, and carry the info of the targets.
So again I have to go back to the Actor class putting out the notes when its functions are executed. But at least I think using a LogNote class would be easier than having a unique signal for every action method.
Alright. I'll modify the Actor class to emit a signal with a LogNote, and make a LogNote class itself.
4:11am - It took a while due to some strange behavior but I've got the log filling up again.
Next up I make a Zombie, along with all its parts, and make it approach and attack the player.
For now though, I need another break, and maybe a sleep.
12:39pm - Sleep was weird, and getting up was different. I wasn't able to get up using soft methods but the two alarms seemed to help. I was shook as a Yeti when I got out of beddy but I'm feeling better now.
I also have a spare hour to myself, so I'm going to try and use it on my project.
12:54pm - Actor classes unified.
1:25pm - Camera and UI removed from Player and put on the World level.
I'm feeling pretty out of it right now. I've got a half hour until work, and I don't want to call out again, but I worry about my capability right now. I'd like to crawl back in bed, but that wouldn't be keeping to my responsibilities.
Yeah I think I'm done with my coding for the moment also, I don't think I can do any more right now. We'll see what happens next.
I also have a spare hour to myself, so I'm going to try and use it on my project.
12:54pm - Actor classes unified.
1:25pm - Camera and UI removed from Player and put on the World level.
I'm feeling pretty out of it right now. I've got a half hour until work, and I don't want to call out again, but I worry about my capability right now. I'd like to crawl back in bed, but that wouldn't be keeping to my responsibilities.
Yeah I think I'm done with my coding for the moment also, I don't think I can do any more right now. We'll see what happens next.
10:22pm - Time is fleeting, and tonight it's going particularly fast. I took the day off work again due to my mental health problems, and if I was still at work I'd be getting off in less than ten minutes (probably) but I've barely begun my day.
I was hoping to do some pasta up tonight, but other things have gotten in the way. I also want to do some programming work, and it's hard to do them both at once. The pasta is the more immediate concern, but it's not as appealing, so I've started working on my programming. I've been studying about the ADHD and ASD that art part of me and I realize this isn't that abnormal, but I'm not sure it's good either? At any rate I've got stuff I want to do.
GreenEnemy isn't just a class in my project, it's also a scene in Godot. It's got it's own scene, with a Node2D and a Sprite. It's instantiated by the main program, which is part of how Godot usually works. In retrospect I probably could have made this game more Godot style than I did. Usually in Godot or, also, Unity games, you create a lot of independant scenes or prefabs that go together and can operate independantly. In the game I've made you can't just slap down a Map and put an Actor down in the editor and expect it to work. But I might have been able to do that if I had really been aiming for it and embraced the Signal system for moving data and commands instead of the way I did it. That said, I've already remade this game so many times, I don't want to do it again, at least not now.
I've actually been thinking about formalizing my goal for this game more and making it a proof of capability project, like the Match 3 game I made a decade ago or more. Something I can finish and say 'This is a thing I did and didn't quit or change to something else'. But this isn't the time for that.
Right now I'm trying to decide if, when I change my GreenEnemy for an Enemy, I should change my Enemy and Player scenes for an Actor scene.
The Player scene has a bunch more stuff in it than the GreenEnemy. It's got a Camera with a CanvasLayer and a bunch of GUI bits on it. That ties the GUI to the Player scene firmly, meaning there's only one possible player scene. So that has to change. But how?
If I made all the Actors into a single Actor scene, with just an Actor and a Sprite, that would make it easier to just make any old thing. But, it would also mean that my Actor subclasses wouldn't have their own unique behaviors.
If I tied the unique behaviors to the AICore system, or made a Capability system of some sort, I would be able to make them transient and pluginable, but that seems a bit over the top for what I'm trying to do.
I could also make it so that all of the actors functioned the same, but their stats were different. That might be a good idea. Let's look at some cases.
What can the Player do that Enemies, NPCs, Items, and Effects shouldn't be able to do?
Well, I suppose there's manipulating the GUI, but that's going to be seperate from the Actor class anyways.
If something wasn't an NPC you wouldn't be able to talk to it, but you could still try. How would I handle that? The talk action would go to a dialogue handler anyways, and if the Actor didn't have one, it would just say something like 'You can't talk to that'.
What about the Use action though. That's meant to be different for every Actor type. But then, not just every type, but almost every Actor. Every different Item type would have its own Use method that was unique.
Hmm...
Maybe, like the pluginable AICore, I need a pluginable Use system?
Let's look at the major cases there.
Use Food, Use Potion, Use Door, Use Chest, and Use Wand.
Use Food, I'd want it to ... I just realized I didn't make an Affect action. I made a recieve effect from actor but nothing to give one. Weird. And I digress.
Use Food, I'd want it to Affect the Target Actor, who would be the user, with a food buff. It should also consume the food, removing it from inventory.
Use Potion, there could be lots of different effects given by potions, but it works the same as food.
Use Door, the door opens or closes. This would be an effect on the door itself, I think.
Use Chest, open the chest and take its items. This is a complex action since it affects the chest and the user and gives over items to them.
Use Wand, you point a wand at something and give it an effect remotely. This is pretty complex since it has to communicate with the AICore to figure out what, where, and when to be used. For the Player there would have to be a targeting system, and for the AI there would have to be something to know it has a wand, and to choose when to use it, and where and on what.
I'll give that a bit of thought.
11:07pm - I'm going to take a bit of a cuddle break while I think about this.
1:47am - Well, the cuddle break went on for a while and was nice but I got stuck, and when my roommmate helped me out I went and made the pasta and sauce.
2:02am - I looked away and it was fifteen minutes later. o.o;;
Anyways I think my idea of putting a plugin in for the use action and otherwise having static actions makes sense.
So, to be clear, moving forward, instead of subclassing Actor, and having different scenes for each actor, there'll just be one actor scene, which will represent all actors in the game. The Actor Factory will assemble the actors to differentiate them, and each Actor will also be assigned an AICore and a Use component. I can add other bits as neccesary too. I'll also have to pull the UI out of Player.
2:29am - Alright I've updated my TODO list with a bunch of tasks, and I'll work on them next time. For now, I'm tired and I have to work tomorrow, so I'm going to bed.
I was hoping to do some pasta up tonight, but other things have gotten in the way. I also want to do some programming work, and it's hard to do them both at once. The pasta is the more immediate concern, but it's not as appealing, so I've started working on my programming. I've been studying about the ADHD and ASD that art part of me and I realize this isn't that abnormal, but I'm not sure it's good either? At any rate I've got stuff I want to do.
GreenEnemy isn't just a class in my project, it's also a scene in Godot. It's got it's own scene, with a Node2D and a Sprite. It's instantiated by the main program, which is part of how Godot usually works. In retrospect I probably could have made this game more Godot style than I did. Usually in Godot or, also, Unity games, you create a lot of independant scenes or prefabs that go together and can operate independantly. In the game I've made you can't just slap down a Map and put an Actor down in the editor and expect it to work. But I might have been able to do that if I had really been aiming for it and embraced the Signal system for moving data and commands instead of the way I did it. That said, I've already remade this game so many times, I don't want to do it again, at least not now.
I've actually been thinking about formalizing my goal for this game more and making it a proof of capability project, like the Match 3 game I made a decade ago or more. Something I can finish and say 'This is a thing I did and didn't quit or change to something else'. But this isn't the time for that.
Right now I'm trying to decide if, when I change my GreenEnemy for an Enemy, I should change my Enemy and Player scenes for an Actor scene.
The Player scene has a bunch more stuff in it than the GreenEnemy. It's got a Camera with a CanvasLayer and a bunch of GUI bits on it. That ties the GUI to the Player scene firmly, meaning there's only one possible player scene. So that has to change. But how?
If I made all the Actors into a single Actor scene, with just an Actor and a Sprite, that would make it easier to just make any old thing. But, it would also mean that my Actor subclasses wouldn't have their own unique behaviors.
If I tied the unique behaviors to the AICore system, or made a Capability system of some sort, I would be able to make them transient and pluginable, but that seems a bit over the top for what I'm trying to do.
I could also make it so that all of the actors functioned the same, but their stats were different. That might be a good idea. Let's look at some cases.
What can the Player do that Enemies, NPCs, Items, and Effects shouldn't be able to do?
Well, I suppose there's manipulating the GUI, but that's going to be seperate from the Actor class anyways.
If something wasn't an NPC you wouldn't be able to talk to it, but you could still try. How would I handle that? The talk action would go to a dialogue handler anyways, and if the Actor didn't have one, it would just say something like 'You can't talk to that'.
What about the Use action though. That's meant to be different for every Actor type. But then, not just every type, but almost every Actor. Every different Item type would have its own Use method that was unique.
Hmm...
Maybe, like the pluginable AICore, I need a pluginable Use system?
Let's look at the major cases there.
Use Food, Use Potion, Use Door, Use Chest, and Use Wand.
Use Food, I'd want it to ... I just realized I didn't make an Affect action. I made a recieve effect from actor but nothing to give one. Weird. And I digress.
Use Food, I'd want it to Affect the Target Actor, who would be the user, with a food buff. It should also consume the food, removing it from inventory.
Use Potion, there could be lots of different effects given by potions, but it works the same as food.
Use Door, the door opens or closes. This would be an effect on the door itself, I think.
Use Chest, open the chest and take its items. This is a complex action since it affects the chest and the user and gives over items to them.
Use Wand, you point a wand at something and give it an effect remotely. This is pretty complex since it has to communicate with the AICore to figure out what, where, and when to be used. For the Player there would have to be a targeting system, and for the AI there would have to be something to know it has a wand, and to choose when to use it, and where and on what.
I'll give that a bit of thought.
11:07pm - I'm going to take a bit of a cuddle break while I think about this.
1:47am - Well, the cuddle break went on for a while and was nice but I got stuck, and when my roommmate helped me out I went and made the pasta and sauce.
2:02am - I looked away and it was fifteen minutes later. o.o;;
Anyways I think my idea of putting a plugin in for the use action and otherwise having static actions makes sense.
So, to be clear, moving forward, instead of subclassing Actor, and having different scenes for each actor, there'll just be one actor scene, which will represent all actors in the game. The Actor Factory will assemble the actors to differentiate them, and each Actor will also be assigned an AICore and a Use component. I can add other bits as neccesary too. I'll also have to pull the UI out of Player.
2:29am - Alright I've updated my TODO list with a bunch of tasks, and I'll work on them next time. For now, I'm tired and I have to work tomorrow, so I'm going to bed.
