Rewrite enchantment system to use cards #275

New issue

Closed

opened 2023-09-10 13:13:17 +00:00 by LunarTides · 2 comments

LunarTides commented

2023-09-10 13:13:17 +00:00

(Migrated from github.com)

Rewrite enchantments to use cards instead of the current stupid system that sucks.

The enchantment cards should get their own type, and should have enchantmentApply(self, owner, other) and enchantmentRemove(self, owner, other) abilities.

When the enchantment is applied to a card, the enchantmentApply ability on the enchantment is called, and the card which the enchantment should be applied to is passed in as the other argument.

When the enchantment is removed from a card, the same should happen expect using the enchantmentRemove ability.

This should make enchantments much more flexible, and more in line with what Hearthstone.gd does.

I'm not entirely sure if adding the other argument is possible at the moment tho, since it clashes with the key and value arguments of passive and the like, and abilities are very soft-coded. Just figure it out, it can't be that hard! :')

Rewrite enchantments to use cards instead of the current stupid system that *sucks*. The enchantment cards should get their own type, and should have `enchantmentApply(self, owner, other)` and `enchantmentRemove(self, owner, other)` abilities. When the enchantment is applied to a card, the `enchantmentApply` ability on the enchantment is called, and the card which the enchantment should be applied to is passed in as the `other` argument. When the enchantment is removed from a card, the same should happen expect using the `enchantmentRemove` ability. This should make enchantments *much* more flexible, and more in line with what [Hearthstone.gd](https://github.com/LunarTides/Hearthstone.gd) does. I'm not *entirely* sure if adding the `other` argument is possible at the moment tho, since it clashes with the `key` and `value` arguments of `passive` and the like, and abilities are very soft-coded. Just figure it out, it can't be *that* hard! :')

LunarTides commented

2024-02-13 12:26:56 +00:00

(Migrated from github.com)

I don't really know why we would need to do this. The enchantment system was added for cards to not override each other's mana cost changes, but i don't think this applies to anything else, or atleast i haven't encountered another situation where cards would clash like this.

Edit: If cards always uses enchantments instead of directly changing fields, blueprints don't need to exist. I've already started working on this in Hearthstone.gd, so this might also apply here. Don't know if it's worth it anymore...

Another edit: Blueprints are essential in Hearthstone.js since there is no other way to create cards properly. In Godot (Hearthstone.gd), it is possible for both to be in one class because of how godot works.

No longer applies after adding a more concrete description.

~~I don't really know _why_ we would need to do this. The enchantment system was added for cards to not override each other's mana cost changes, but i don't think this applies to anything else, or atleast i haven't encountered another situation where cards would clash like this.~~ ~~Edit: If cards always uses enchantments instead of directly changing fields, blueprints don't need to exist. I've already started working on this in [Hearthstone.gd](https://github.com/LunarTides/Hearthstone.gd/pull/11), so this might also apply here. Don't know if it's worth it anymore...~~ ~~Another edit: Blueprints are essential in Hearthstone.js since there is no other way to create cards properly. In Godot (Hearthstone.gd), it is possible for both to be in one class because of how godot works.~~ *No longer applies after adding a more concrete description.*

LunarTides commented

2025-10-15 08:43:56 +00:00

(Migrated from github.com)

Changed the other in the abilities to host to be more distinguishable from owner at a glance. Also because host is cooler :)

Changed the `other` in the abilities to `host` to be more distinguishable from `owner` at a glance. Also because `host` is cooler :)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

LunarTides/Hearthstone.js#275

No description provided.

Rows
Columns