Character Buffs

Purpose and Scope

Character buffs are self-targeted buffs that are equipped directly on the player character and affect the owner of that character, not a victim hit by a weapon. In RPG Engine v6, buffs are implemented as regular CharacterStates with additional runtime behavior driven by BP_BuffComponent and buff data assets.

This document covers only player buffs placed into the dedicated character buff slots: Health, Armor, Damage, and Experience. Weapon buffs are a separate category and must be documented in buffs-and-debuffs.md, because they are attached to melee weapons and participate in debuff application on hit.

Core idea

At the architecture level, a buff is not a silent stat modifier. Every buff activates its own CharacterState tag, and BP_BuffComponent applies the rest of the runtime behavior based on the buff configuration.

This means a character buff is best understood as a state-driven gameplay effect. The active tag represents the state itself, while stat changes, visual feedback, spawned actors, overlay materials, and Niagara systems are applied by the buff system as consequences of that state.

Player buff types

Player buffs use exactly four categories: — Health — Armor — Damage — Experience

Each category has its own dedicated equipment slot on the player. A player cannot equip two buffs of the same category at the same time, because there is only one slot per category in the current project setup.

Activation flow

The player equips a buff item into one of the four dedicated buff slots in the inventory and then activates it through a dedicated input action. The current input actions are IA_ActivateBuff_1, IA_ActivateBuff_2, IA_ActivateBuff_3, and IA_ActivateBuff_4; by default they are bound to Alt+1, Alt+2, Alt+3, and Alt+4. A key rebinding system is planned for the future.

When the player activates a buff, the system resolves the equipped item of type World.Items.Types.Buff, reads its BP_Buff_ClarData, and activates the Character Tag defined in that asset through the state system. From that point on, BP_BuffComponent applies all configured consequences of the buff and keeps them active until the buff is removed, expires, or is otherwise deactivated.

Runtime flow

At runtime, player buff activation follows this general sequence: 1. The player equips a buff item into the correct character buff slot. 2. The player presses the corresponding input action. 3. The system resolves the buff item and its BP_Buff_ClarData. 4. BP_BuffComponent requests activation of the buff Character Tag through BP_ModulesMediator. 5. If the state is allowed, the buff becomes active. 6. BP_BuffComponent executes the actions defined in Actions After Using If Buff In Use. 7. Other gameplay systems can react to the active CharacterState tag during their own calculations and validations.

When the buff is deactivated, the reverse flow is used: 1. BP_BuffComponent deactivates the same CharacterState. 2. Applied stat modifiers are reverted. 3. Spawned scene actors, overlay materials, and Niagara systems are cleaned up through Actions After Using If Buff Not In Use. 4. If the buff is configured as one-use, it can be removed from the slot or from inventory after deactivation.

BP_Buff_ClarData

Player buffs use BP_Buff_ClarData as their clarification data asset. This asset is a PrimaryDataAsset and stores the runtime configuration of the buff item. Its job is to describe which CharacterState is activated and which additional actions must be performed while the buff is active or when it is removed.

Variables

Variable	Type	Description	Editable
StaticMesh	StaticMesh	Optional 3D mesh associated with the buff item.	Yes
Character Tag	GameplayTag	The CharacterState tag activated by this buff.	Yes
Actions After Using If Buff In Use	S_ActionsAfterUsing[]	Actions executed while the buff is active.	Yes
Actions After Using If Buff Not In Use	S_ActionsAfterUsing[]	Actions executed when the buff is removed or no longer active.	Yes
Remove From Inventory After Deactivating	bool	If true, the buff item is removed after deactivation.	Yes

Actions arrays

Actions After Using If Buff In Use is the main data-driven description of what the active buff actually does. It is not just a decorative list. This array tells BP_BuffComponent which gameplay and presentation effects must be created once the buff state becomes active.

Actions After Using If Buff Not In Use is the paired cleanup array. It is used when the buff is removed, disabled, expires, or otherwise leaves the active state, so that the effects created during activation can be reverted or destroyed cleanly.

Supported action types include: — AddCharacteristics — AddToScene — AddOverlayMaterial — AddNiagaraSystem

Action types

AddCharacteristics

AddCharacteristics changes numeric character values. In the documented action setup, it uses fields such as Characteristic Type, Action, and Value. Example characteristic types include Health, Damage, and Experience, while supported operations include Multiply and Sum.

This is the main action type used by standard player buffs such as more damage, more experience gain, or additional survivability. It allows the buff to remain state-driven while still changing actual gameplay values.

AddToScene

AddToScene spawns a buff-related actor in the scene. The documented setup includes at least the actor class BPConBuffs and Socket Name, so the spawned actor can be attached to a specific socket on the character.

This action is useful for buffs that need a persistent helper actor or a visible world-space attachment while active. It is also the mechanism that allows some self-buffs to exist as spawned protective entities rather than as a stat change only.

AddOverlayMaterial

AddOverlayMaterial applies an overlay material to a skeletal mesh component. The documented parameters include Material and Skeletal Mesh Component Index, which lets the buff target the correct mesh on the character.

This action is used for visual feedback such as temporary body glow, protection effects, or other buff-related screen or mesh overlays.

AddNiagaraSystem

AddNiagaraSystem spawns a Niagara effect either attached to the character or configured in world space. The documented parameters include Niagara System, Skeletal Mesh Component Index, Socket Name, Location, Rotation, and Visibility Mode.

The supported visibility modes include Persistent Visible and Controlled by Anim Notify. For player buffs, persistent usage is the more typical case, while anim-notify-controlled visibility is especially useful for weapon-linked effects.

Gameplay tag structure

Player buff gameplay tags must always use the following structure:

• CharacterStates.Buffs.Armor.<BuffName>
• CharacterStates.Buffs.Damage.<BuffName>
• CharacterStates.Buffs.Experience.<BuffName>
• CharacterStates.Buffs.Health.<BuffName>

This structure is mandatory. The namespace must always be:

CharacterStates → Buffs → BuffType → BuffName

For player buffs, BuffType must always be one of these four values: — Armor — Damage — Experience — Health

Examples

Existing player-buff style examples include: — CharacterStates.Buffs.Armor.PassiveShield — CharacterStates.Buffs.Damage.Horns — CharacterStates.Buffs.Experience.ShimmeringEyes — CharacterStates.Buffs.Health.ExtraLife

These examples follow the required naming structure and represent the intended organization for all self-targeted player buffs.

Resource-based buffs

Not every player buff is just a passive stat multiplier. The buff system also supports self-buffs with resource-based lifetime instead of a simple fixed timer. This is still the same buff framework: the buff activates a CharacterState, creates its runtime effect, and remains active until its own removal condition is met.

ProtTentacles is one such case. It spawns an actor on the player’s back in the form of tentacles and absorbs 400 damage. When that 400 damage is fully consumed, or when the player manually deactivates the buff, the spawned actor is removed and the buff disappears from its slot.

Design rules

Use player buffs only for self-targeted effects that belong to one of the four character buff categories. If the effect is attached to a melee weapon and applies debuffs to a victim during hit windows, it is not a character buff and belongs in the weapon buff / debuff documentation instead.

Also, treat the active CharacterState as the canonical identity of the buff. The tag is what other systems react to, while BP_BuffComponent and the configured actions are what make that state produce real gameplay and visual consequences.