Divine Gift Base Implementation and Scaffold Stealing Spells

[LeMichael88]

Changes

• Most files were auto updated to add uid by godot (new thing in 4.4 I think?)
• Add function declaration for CombatManager::StealSpells() (to be implemented in future PR)
• Created Divine Gift base resource and Steal Spells resource file
• Created Divine Gift Component to attach to characters and store which divine gift they have

Refactoring

• Moved attack_rsc.gd script to resources/attack folder
• Changed spells_component scene to extend Node instead of Node2D class

How

• Will operate similar to spells component, where each divine gift has some config (ie. name to override combat GUI button) stored in resource file
• DivineGift resources will have a _cast() function, called when player clicks the Divine Gift button, which will call the correct CombatManager function to execute
• Ex. For stealing spells, combat GUI will take the button name from resource file. Then when player clicks the button, it will call the resource's script's _cast() function which calls CombatManager::StealSpells() to interact with party manager and character spell component

Next Steps:

• Implement CombatManager::StealSpell()

[zalsaigh]

We have this here bc we want everything to first go through combat manager right? I wanna see if maybe we can abstract this into trigger_divine_gift and figure out the specific implementation it calls later?

[LeMichael88]

Yes we want things to go through the combat manager. I think that works too, having a function trigger_divine_gift that gets the correct function to call (for this case, it would just call steal_spell())?

[zalsaigh]

Does this need to be renamed..? I thought this was the general resource

[zalsaigh]

Like it's an overarching attack resource, not a specific one

[LeMichael88]

Yeah do you think general resources should go into resources/ folder? Or in resources/attack folder. Right now I put the general spell and divine gift into their specific folder along with the actual specific resources

[zalsaigh]

ah i see what you're doing here. Do you think this current implementaiton is better or should we go with a "CombatManager is the only interface anything calls in combat"? i.e. the button will call CombatManager::cast_divine_gift() which then calls _cast() which then calls steal_gift() in this case (and steal_gift() implementation is in steal_spells.gd)

[LeMichael88]

I was thinking about that too, but then how do we map the button dynamically based on the divine gift the user has? I think keeping it strictly in CombatManager would involve some kind of hard coded map from DivineGiftType to func.

In my head I think this is kinda cleaner, since we'd abstract that "map" into these resource scripts. Each DivineGift resource script stores which CombatManager function will need to be called, instead of the CombatManager having to figure it out.

Also allows us to extend these _cast() functions in case we want to have divine gifts do things outside of combat (maybe some overworld benefits).

[zalsaigh]

Isn't "what divine gift X character has" defined by their divine gift component?

[LeMichael88]

yeah each characters divine gift component holds the divine gift they have, represented as a resource- and the divine gift resource stores whatever config we need (name, description, what CombatManager func to call, etc)