Skip to content
Logo_UE_XS
Yuewu
Back to wiki

Combat Flow

This article briefly introduces the attack and defense process in the GCS combat system to help you better utilize GCS.

A

Author

Author

Created: Apr 15, 2025Updated: Oct 12, 2026

Table of contents

Combat Flow

UGCS_CombatFlow is a UObject that can be configured on a combat system component. You can extend or configure the GCS_BaseCombatFlow Blueprint, or derive from UGCS_CombatFlow and override the functions your game needs.

Handling Attribute Changes

As described in Gameplay Attributes, GGA_AttributeSystemComponent forwards the AttributeSet's PostGameplayEffectExecute callback to HandleGameplayEffectExecute on CombatFlow. Handle the attribute changes from that Gameplay Effect here, then generate attack results according to your game rules.

If a Gameplay Effect has UGCS_GEComponent_PredictivelyExecute, its instant execution can also be predicted locally on an Autonomous Proxy and enter this same flow.

How attributes are handled and which attack results are produced depend on your game rules. The reference implementation provides a flow commonly used in souls-like games.

Generating Attack Results

After handling attribute changes in HandleGameplayEffectExecute, build an FGCS_AttackResult from the relevant data and register it through the combat system component. Registration is accepted on authority or in a locally predicting context; a non-authoritative, non-predicting registration is rejected.

FGCS_AttackResult contains the Gameplay Effect's EffectContextHandle, aggregated source and target tags, and an optional object. The result struct does not have a TaggedValues field. To pass additional numeric values, store them in the FGCS_ContextPayload_Combat carried by the EffectContextHandle. For example, you can store the actual health change calculated by your processing logic as a custom value in that payload.

Customizing Combat Flow

Attackers can issue different attack requests, and different targets may need different handling for the same request. Customize CombatFlow and configure different flows on each CombatSystemComponent to keep target-specific behavior out of large If/Else branches on the attacker.

For example, an arrow would usually trigger a hit reaction. If a large enemy should not react to an ordinary arrow, configure a different CombatFlow for that target.

Use separate CombatFlows when:

  1. You do not want a dog to deflect the player's attack.
  2. You do not want a gigantic boss to fall over because its foot took a light hit.
  3. You do not want a building to dodge an attack.

Accessing the Attack Request in CombatFlow

The attack request is passed through the GameplayEffectContext during processing. You can read the request and its associated attack definition from the context.

Good to Know

  • AttackRequest is a Const UObject intended to hold authored configuration data. Treat it as static data and do not modify it during gameplay.
  • Blueprint properties that support inline instancing can let you create an AttackRequest inline and save it with the owning asset.

Attack Results

After an authoritative or locally predicted flow registers an attack result, the result is added to the combat system component's Fast Array container and immediately handled by CombatFlow on that machine. Authoritative results are replicated over the network; clients also invoke CombatFlow when they receive a new result. Configured attack-result processors produce feedback from the result, such as sending gameplay events or triggering Gameplay Cues.

Handling Attack Results

Configure multiple AttackResultProcessors on CombatFlow to handle results in a data-driven way. Each processor's execution policy determines when it runs across prediction and authority paths.

  • Default: handles non-predicting results on each relevant machine.
  • LocalPredicted: runs immediately for the local predicted result and also for unmatched authoritative results. If a client receives an authoritative result whose PredictionKey matches a local prediction, that duplicate processor call is skipped. Use this policy for immediate feedback; put authoritative state changes in Default or ServerOnly processors.
  • ServerOnly: handles only the server's non-predicting, non-replicated authoritative result.

Refer to the GCS_BaseCombatFlow Blueprint for an example configuration.

Built-in Attack Result Processors

Send Gameplay Event

This processor sends different gameplay events to the attacker or victim based on the attack result.

You can also use TagQuery to route result handling. For example, trigger a block-hit event only when the source tags contain Block, or a regular hit reaction only when they contain Hit.

Custom Attack Result Processors

Create a new processor by deriving from GCS_AttackResultProcessor. For example, a damage-statistics processor could record received damage in a logging, match-report, or UI system. Choose its execution policy based on whether the logic needs immediate local feedback or an authoritative state update.