![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee1: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!
