Enchantments & Curses

Purpose

An enchantment or curse is typically an effect that can be applied to an entity, where an enchantment is beneficial/defensive, and a curse is detrimental/offensive, and that may have:

• A duration: How long the effect will last before it is automatically removed.
  • An effect without a duration will last until it is removed by some other means.
• An on-apply effect: Something that happens to the target entity when it is applied to them.
  • e.g. Gain HP when effect is applied, damage all nearby enemies when effect ends.
• An on-remove effect: Something that happens to the entity it is applied to when it is removed from them.
  • e.g. Take damage when effect ends, heal all nearby allies when effect ends.
• An on-action effect: Something that happens to the entity it is applied to when they perform a specific action as defined by the effect.
  • e.g. Entity deals more damage with their next attack, entity takes damage every time they move.
• A periodic effect: Something that happens to the entity it is applied to at a regular interval.
  • e.g. Gain HP every few seconds
• A passive effect: Something that changes about the entity's state while it is applied to them.
  • e.g. Reduced damage taken, faster movement speed

Enchantments

An entity can only have one enchantment applied at a time.

Applying a new enchantment of a higher level than an existing enchantment overwrites that enchantment, and causes any on-remove effect to activate.

This is intended to encourage the team to assign a few members to specialise in applying the highest level of enchantments, and for those enchantments to always take priority, instead of everyone using weak or mediocre enchantments of their own. (Specialisation)

If an enchantment is applied that is of a lower or equal level than an existing enchantment, the target gains the spell cast time multiplied by some factor as healing instead of receiving the incoming enchantment.

This is intended to allow players who don't know what they are doing and think that "enchantments = helpful" to still be of use, where they can still use their enchantments as a means of healing and being helpful, albeit without having their intended enchantments applied. Also discourages uncooperative players from trying to go around and deliberately overwrite better enchantments with their own weaker/lower level ones to be annoying, which won't work.

The healing done is tied to cast time so that the effectiveness remains constant regardless of how long it takes to cast, to prevent faster casting enchantment spells from being better than others for healing. This way, all enchantment spells have the same potential rate of healing over time when used for that purpose.

For example, if a target has a level 5 enchantment, and a level 2 enchantment that takes 3 seconds to cast is then applied to them, the target keeps the existing level 5 enchantment, and is healed for 15 HP (3 x 5 (or whatever the healing factor is)).

Applying an enchantment to yourself always takes priority over any existing enchantment, regardless of the spell level of the existing enchantment. In this case, no healing is done from any difference in the levels of the enchantments.

The player should still have agency over which specific enchantment they want to have on themself, if they have access to a different one that they want to be applied instead, even if it may be weaker than an existing enchantment.

Mostly governed by the Enchanting attribute.

Curses

An entity can only have one curse applied at a time.

Applying a new curse of a higher level than an existing curse overwrites that curse, and causes any on-remove effect to activate.

This is intended to encourage the team to assign a few members to specialise in applying the highest level of curses, and for those curses to always take priority, instead of everyone using weak or mediocre curses of their own. (Specialisation)

If a curse is applied that is of a lower or equal level than an existing curse, the target takes the spell cast time multiplied by some factor as damage instead of receiving the curse.

This is intended to allow players who don't know what they are doing and think that "curses = harmful to the enemy" to still be of use, where they can still use their curses as a means of damaging and being harmful to the enemy, albeit without having their intended curses applied. Also discourages uncooperative players from trying to go around and deliberately overwrite better curses with their own weaker/lower level ones to be annoying, which won't work.

The damage done is tied to cast time so that the effectiveness remains constant regardless of how long it takes to cast, to prevent faster casting curse spells from being better than others for dealing damage. This way, all curse spells have the same potential rate of damage over time when used for that purpose.

For example, if a target has a level 5 curse, and a level 2 curse that takes 3 seconds to cast is then applied to them, the target keeps the existing level 5 curse, and is damaged for 15 HP (3 x 5 (or whatever the damage factor is)).

Mostly governed by the Cursing attribute.

"Why only one of each?"

These kinds of complex abilities can have a wide range of passive and active effects.

When allowing multiple of them to be stacked on the same entity at the same time, they can potentially interact with each other in certain combinations that may be detrimental to the game (from simply being overpowered leading to them becoming meta, to being buggy and potentially abusable).

Due to development constraints (i.e. not being a large team of full-time experienced RPG designers), the project doesn't want to have to deal with the design and implementation complications associated with allowing stacking effects and having to balance and bug-fix around them constantly as new weird interactions are discovered.

By keeping it simple by only allowing a single enchantment and a single curse to be applied at once, and adding a bit more optional depth to them based on how they are used, the development overhead of supporting these features can be kept manageable.