![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
2:16pm - Back to work after a nice day off. Today I'll start by writing a script that spawns carrots in the carrot patch.
3:19pm - Alright I've got my carrots appearing on the carrot patch now. I realized partway through that it was more performant to have the carrots always there but invisible instead of spawning a new carrot every time one spawned in the patch. I also defied YAGNI and put in a function to take carrots that isn't used yet.
Next step, I think, is making the civs.
A Civ will be a white capsule for now, and they'll start out in the base. The player can click on the base to access its command UI and summon a Civ, so I'll have to do the GUI for that too. Hmm... Maybe I'll start with a couple demo Civs outside the base during development, so I can test them without having the base fully functional.
So the Civs will have a food stat that is constantly going down, and when it reaches 0 they die. When the player clicks on them, they'll approach the civ and when close enough the Civ's gui will appear. This will allow the player to command the civ to do a job. In this first version, the only job will be 'Gather Carrots'. Clicking on it will start the civ gathering carrots from the carrot patch and bringing them to the Base. At the same time, whenever a Civ's food stat is below a certain threshold, we'll say 60% for here, and a carrot is available at base, the civ will try to eat a carrot and refill its food stat. That should be all of the neccesary civ behaviors.
I'm having a bad feeling that the navmesh implementation in Godot won't take into account multiple characters moving at once like the Unity navmesh does, and thus they won't avoid eachother. I guess we'll see.
I'm also starting to have a concern about the GUI dependancy. The way the game is laid out now, the GUI sits on the Main object, the same as the World. That means the Main object will have to be loaded to see any of the GUI elements. Maybe I should figure out a way to make the GUI in-world? I'll give it a shot.
4:06pm - I'm having a bit of trouble with the logic here so I'm going to sound it out.
The player clicks on a Civ and then the player approaches that Civ. Hmm... Should the Civ stop and wait? Probably...
So the player clicks on a Civ and then the Civ waits for the player to approach.
I'm thinking the player should have a "Target" field that other objects can check to see if it changes, so they know what the player is up to.
4:10pm - Alright, I'm going to take a walk, get a Sub I think, and think about this for a bit. I want to go out while it's still looking nice out, despite the heat wave.
5:08pm - I'm back from getting and eating my Sub, but now I want to take a break and play a game for a while. So I'll come back to this after that.
8:06pm - It's quite a bit later and I've realized I don't really want to do any more work today, so I'll wrap this up here and post it as soon as the internet comes back on.
3:19pm - Alright I've got my carrots appearing on the carrot patch now. I realized partway through that it was more performant to have the carrots always there but invisible instead of spawning a new carrot every time one spawned in the patch. I also defied YAGNI and put in a function to take carrots that isn't used yet.
Next step, I think, is making the civs.
A Civ will be a white capsule for now, and they'll start out in the base. The player can click on the base to access its command UI and summon a Civ, so I'll have to do the GUI for that too. Hmm... Maybe I'll start with a couple demo Civs outside the base during development, so I can test them without having the base fully functional.
So the Civs will have a food stat that is constantly going down, and when it reaches 0 they die. When the player clicks on them, they'll approach the civ and when close enough the Civ's gui will appear. This will allow the player to command the civ to do a job. In this first version, the only job will be 'Gather Carrots'. Clicking on it will start the civ gathering carrots from the carrot patch and bringing them to the Base. At the same time, whenever a Civ's food stat is below a certain threshold, we'll say 60% for here, and a carrot is available at base, the civ will try to eat a carrot and refill its food stat. That should be all of the neccesary civ behaviors.
I'm having a bad feeling that the navmesh implementation in Godot won't take into account multiple characters moving at once like the Unity navmesh does, and thus they won't avoid eachother. I guess we'll see.
I'm also starting to have a concern about the GUI dependancy. The way the game is laid out now, the GUI sits on the Main object, the same as the World. That means the Main object will have to be loaded to see any of the GUI elements. Maybe I should figure out a way to make the GUI in-world? I'll give it a shot.
4:06pm - I'm having a bit of trouble with the logic here so I'm going to sound it out.
The player clicks on a Civ and then the player approaches that Civ. Hmm... Should the Civ stop and wait? Probably...
So the player clicks on a Civ and then the Civ waits for the player to approach.
I'm thinking the player should have a "Target" field that other objects can check to see if it changes, so they know what the player is up to.
4:10pm - Alright, I'm going to take a walk, get a Sub I think, and think about this for a bit. I want to go out while it's still looking nice out, despite the heat wave.
5:08pm - I'm back from getting and eating my Sub, but now I want to take a break and play a game for a while. So I'll come back to this after that.
8:06pm - It's quite a bit later and I've realized I don't really want to do any more work today, so I'll wrap this up here and post it as soon as the internet comes back on.
