Actor health system #

AC_Actor_Health Technical Documentation

Overview board from the example environment.

Contents

---

Introduction #

AC_Actor_Health is a reusable actor component that centralises health and damage logic in one place. It is designed to be added to any actor that needs consistent health behaviour, including characters, AI, props, and destructible world objects. The documented implementation is server authoritative, supports replication, and exposes clear health-related callbacks for any system that needs to react when health changes or reaches zero.

The component keeps actors free of custom one-off health code by routing all health changes through the same internal function. Damage, healing, and full restore all end up using the same modification path, which makes behaviour predictable and easier to integrate into larger gameplay systems.

• Reusable Actor Component that can be assigned to any actor.
• Server authoritative and multiplayer safe.
• Supports direct damage, healing, and full restore.
• Can optionally bind to Unreal's Take Any Damage event.
• Replicates current health and exposes change callbacks.
• Provides a zero-health callback for death, destruction, or cleanup behaviour.

High-level summary board for AC_Actor_Health.

---

Adding AC_ACTOR_HEALTH to an Actor #

The component is intended to be added directly to the actor that should own health. Once attached, that actor gains current health, maximum health, damage handling, healing support, and a small set of events that other Blueprints can bind to.

• Add AC_Actor_Health to the actor Blueprint that should have health.
• Set the starting Current Health and Max Health values in the details panel.
• Decide whether the component should bind itself to Unreal's Take Any Damage event by setting Should Bind On Take Any Damage.
• Call the provided server events or use the built-in damage binding path to change health during play.
• Bind to On Health Changed or On Health Zero if the owning actor or other systems need to react.

This makes the component suitable for player characters, AI enemies, breakable props, harvestable objects such as rocks or trees, and any actor that should follow the same health rules rather than bespoke per-actor logic.

---

Details Panel / Important Variables #

The documented component is intentionally small. It exposes only the variables needed for core health state, replication bookkeeping, and optional damage binding configuration.

No structs or data tables were part of the documented implementation. This system is intentionally straightforward: state lives directly on the component rather than being driven by external row data.

---

Functions and Server Events #

The component uses one core health function plus a small set of server events that feed into it. This is the main architectural strength of the documented implementation: there is one place where health is actually changed, and all public paths route into that same logic.

---

Modify Health #

Modify Health is the core function responsible for changing Current Health. The documented graph takes an Amount to Modify, adds it to Current Health, clamps the result between 0 and Max Health, and writes the final value back to Current Health using Set w/ Notify.

• Damage is represented by a negative amount.
• Healing is represented by a positive amount.
• The final result is clamped so health cannot go below 0 or above Max Health.
• Set w/ Notify ensures the replicated health change path is triggered for clients.

Modify Health clamps the final value between 0 and Max Health.

---

Server_ApplyDamage #

Server_ApplyDamage is the documented server event used for incoming damage. The graph shown multiplies the incoming Damage value by -1 and sends the result into Modify Health. This ensures the component uses the same modification path for damage as for every other type of health change.

---

Server_ModifyHealth #

Server_ModifyHealth is a general-purpose server event that forwards its Amount to Modify directly into Modify Health. Use this when the caller already knows the signed change amount it wants to apply.

---

Server_SetHealthToMax #

Server_SetHealthToMax restores the actor to full health by sending Max Health into Modify Health. Because Modify Health clamps the result, this safely drives Current Health back to its maximum allowed value.

---

Summary #

The Actor Health System is a reusable, server-authoritative health component designed to give any actor a consistent health workflow without requiring custom health logic on each Blueprint. By centralising damage, healing, and full restore behaviour inside a single component, the system keeps implementation clean, multiplayer safe, and easy to reuse across characters, AI, props, and destructible world actors.

At its core, the component tracks Current Health and Max Health, routes all health changes through Modify Health, and ensures values are always clamped between zero and the configured maximum. Incoming damage can optionally be bound directly to Unreal’s Take Any Damage event, while dedicated server events provide a clear API for applying damage, modifying health, or restoring health to full.

Replication is handled through Current Health, with OnRep_CurrentHealth_Execution responsible for broadcasting health updates and detecting when health reaches zero. The included dispatchers make it easy for UI, audio, gameplay feedback, destruction logic, or other systems to react when health changes or is fully depleted.

Core server events all route into Modify Health.

Utility: Is Health Full

The function list also includes Is Health Full as a utility function. Based on its name and placement in the utility category, its purpose is to provide a simple check for whether the actor is currently at maximum health. This is useful for gameplay checks, healing restrictions, UI state, or interactable logic that should only run when the actor is not already fully restored.

EVENT DISPATCHERS

The component exposes two event dispatchers for downstream reaction logic. These are the main extension points for UI, audio, destruction logic, AI state changes, and any other behaviour that should respond to health transitions without being embedded directly inside the component.

These dispatchers keep the health component generic. The component owns the health rules; the owning actor or other systems own the reaction to those rules.

OPTIONAL TAKE ANY DAMAGE BINDING

On BeginPlay, the documented setup checks authority and then evaluates Should Bind On Take Any Damage. If the bool is enabled, the component gets its owner and binds to the owner's Take Any Damage event. The bound damage event then forwards incoming damage to Server_ApplyDamage.

• BeginPlay runs on the component.
• Authority is checked first so the binding path is handled on the server.
• If Should Bind On Take Any Damage is true, the component binds to the owner's Take Any Damage event.
• When the owner receives damage through that engine event, the component calls Server_ApplyDamage.

The Blueprint comment in the screenshot also notes that projects may sometimes want to perform additional checks before applying damage. That fits this design well: the optional engine damage binding gives a clean default path, while projects can still insert extra validation or equipment checks when needed.

BeginPlay authority check and optional Take Any Damage binding.

REPLICATION AND HEALTH CHANGE HANDLING

Current Health is replicated, and the documented implementation uses OnRep_CurrentHealth_Execution to process the resulting change. This function performs two jobs: it tells listeners what changed, and it checks whether health has reached zero.

This means the component does not just replicate a number. It also provides a clean event-based interpretation of that number changing. UI can update bars, audio can play hit reactions, actors can trigger destruction, and cleanup logic can respond when health reaches zero.

OnRep_CurrentHealth_Execution calls change callbacks and zero-health callbacks, then updates Previous Health.

DAMAGE / HEALING FLOW

The documented implementation uses one shared path for all health modification. This is the main behavioural rule to keep in mind when integrating the component.

Damage flow

• Damage reaches the component either through Server_ApplyDamage or through the optional Take Any Damage binding.
• Server_ApplyDamage converts the incoming damage to a negative modifier.
• Modify Health applies the signed amount and clamps the result between 0 and Max Health.
• The replicated health path processes the change and calls On Health Changed.
• If the result is zero or below, On Health Zero is called.

Healing flow

• A positive amount is sent through Server_ModifyHealth or directly into Modify Health from authorised logic.
• Modify Health adds the amount to Current Health.
• The result is clamped so it cannot exceed Max Health.
• The replicated change path fires On Health Changed with the final amount of change.

Full restore flow

• Server_SetHealthToMax sends Max Health into Modify Health.
• Modify Health clamps the result against Max Health.
• Current Health is restored to full and the replicated change path runs as normal.

EXAMPLE USE CASES

Because the component is generic, it fits a wide range of actor types.

• Player characters that need consistent health, healing, and death callbacks.
• AI enemies that should take damage and trigger zero-health behaviour when defeated.
• Destructible props or world objects that only need simple replicated health handling.
• Resource nodes such as rocks or trees that can use the same damage and zero-health pattern.
• Any actor that should respond to standard engine damage events without implementing custom health code directly on the actor.

A typical usage pattern is to keep AC_Actor_Health focused on state management while the owning actor binds to On Health Changed or On Health Zero to play animations, destroy itself, spawn loot, disable interaction, or update UI.

SUMMARY

AC_Actor_Health is a compact, reusable health component that centralises one of the most common gameplay patterns into a single server-authoritative Blueprint component. The documented implementation is intentionally simple: Current Health and Max Health define the state, Modify Health defines the rule for changing that state, server events feed into that rule, and replication callbacks expose the results through event dispatchers.

• One shared path for damage, healing, and full restore.
• Optional binding to Unreal's Take Any Damage event.
• Replicated health with change and zero-health callbacks.
• Minimal setup and no supporting structs or data tables required.
• Suitable for characters, AI, props, and destructible world actors.