I posted the DevLog 002 (17-07-2026) and right after I just throwed out all my architecture and did a major refactor inside my whole codebase. It was not exactly because it was wrong, but for sure it was becoming very convoluted to work. Something that wasn’t so clear for me when I started to model the Goal Oriented Action Planning (GOAP) and the combat was how everything was being connected. I wanted to have the GOAP running, since it was the most confusing piece of the code, to be running and then I will not lie, from that on I would be winging it the connection to the rest of the IA. I didn’t want to over engineering so I skipped some important questions from the beginning so I could move forward on that front.
I think that now its easier to understand most of the code, since I eliminated a bunch of templates that I was using around, but that cost me to review the majority of the files. Originally we had a very clear distinction on what was an smart object and what was an agent, now everything is a smart object, since everything can provide a interface to be interacted with it. The following image shows the new structure that I’m using.
This means that now everything uses the same data structure, I had to kill a bunch of factories and my DataBase got fattier. A lot more fattier than the previous version. It now holds the responsibility to hold the data for the buildings and the agents. Sometime in the future I should be loading this from JSON files, or something on those lines.
The basic structure of an GameEntity now holds an EntityID, a name, the flags and a team. This will be facilitating since now I can just organize the combat clusters by teams, on the future, if I decide to implement a 4x mode or create neutral units that will remain aggressive until some quest is done, I can use that field to support it. As for the flags, there’s not much of complexity on it yet:
enum class EEntityFlags : uint32_t
{
None = 0,
// Major categories
Unit = 1 << 0,
// Unit roles
Worker = 1 << 2,
Hero = 1 << 3,
Monster = 1 << 4,
// Smart Object roles
Building = 1 << 5,
PointObject = 1 << 6,
Social = 1 << 7,
Inventory = 1 << 8,
GOAPController = Worker | Hero,
FSMController = Monster
};
It was a long refactor to be made, I think I passed over all the code base, but now the combat is much more easier to be done. I did some studies on how I want to implement it too.
The idea is to preserve the GOAP that the Heroes as running, so they still can decide to run away from a battle, but use the CombatClusters to create a sequence of turns using the cooldown of the skills as reference. Again, my reference here is Chrono Trigger but also Ragnarok Online. A combat cluster will be running a tick that is much quicker than the GOAP, so we preserve the processing power passing the environment view for the agents to decide which skill they desire to use when they are out of cooldown.