Decouple core from custom

[zombieCraig]

Currently it's very hard to upgrade. This is mainly because core has dependencies on Custom. We should consider moving default information into core and then using custom for additional information that core could function without. The goal should be that upgrades are simply a matter of copying over a new src/core folder. Some things of note so far:

• custom/cards/CardConfig is instanced from core/CardTemplate - Recommendation, put CardConfig into core
• core/CardTemplate (as of v1.1) has CARD_LABELS - Recommendation, Move these to CFConst by NODES_MAP
• update coreCardTemplate.gd to check if node exists first (this way different card types could support optional fields) Example: if get_node(CARD_LABELS["Name"]).text != "": Should be if has_node(CARD_LABELS["Name"]) and get_node(CARD_LABELS["Name"]).text != "":

Currently CardConfig has all the customization details. Suggestion, use a method where you can extend the new core/CardConfig into a custom/CardConfig or have CardConfig check for a res://custom/CardConfig.json or something to extend/overwrite existing values.

This issue was created to start a discussion as there are a couple of ways to solve this. Once there is a direction we could break this down into small issues/PRs.

[db0]

All good points, some things

• CardConfig should not be in core, as it is supposed to be customized for every game's requirements, and we do not want it to be reset back to the default on upgrade. Typically it should not be part of an upgrade. However is does need to exist in custom, same as board.tcsn, so it's refered to from the core.
• CARD_LABELS don't belong to CFConst as they are supposed to be able to be customized per card-type that needs them. So a card that does not need the "Power" label, can remove it. The way you would handle different labels is by having the custom card have its own script, extending Card. Then define its own CARD_LABELS const in it. This also resolves the third point you suggested.

Currently CardConfig has all the customization details. Suggestion, use a method where you can extend the new core/CardConfig into a custom/CardConfig or have CardConfig check for a res://custom/CardConfig.json or something to extend/overwrite existing values.

This is why it's in "custom" ;) There is no reason for multiple CardConfig at the moment, as it only specifying the sort of fields each label is. You can add all the labels names for all types of cards in CardConfig without issue, as the card is populated only by the fields actually defined in its json.

The only reason why I see one would need multiple CardConfigs, is when they might want a different "SHRINK_LABEL" per card type. Can you describe a scenario where you'd need multiple CardConfigs?

[db0]

I've adjusted and republished 1.1 so that CARD_LABELS are not constants anymore, as that made it not possible to overwrite them in an inheriting scene. Now they are initialized inside _init_front_labels() and this can be overriden in extended classes.

Do you see any other area where there's an issue with coupling?