Combat Entity

Introduction

GCS uses a combat-entity interface to connect combat logic to a project's own movement, equipment, and lifecycle implementations. UGCS_CombatSystemComponent is the combat runtime entry point on an Actor. IGCS_CombatEntityInterface provides project-facing capabilities such as target queries, combo data, ability actions, movement state, death handling, and weapon queries.

An Actor or one of its components can implement the interface. Use UGCS_CombatFunctionLibrary::GetCombatEntityInterface to retrieve it; the helper checks the Actor first, then its components. UGCS_CombatFunctionLibrary::FindCombatInterface uses the same lookup order and returns whether an implementation was found. When a component implements the interface, these helpers let combat Abilities access it without depending on a specific character class.

Design Diagram

Interface Responsibilities

The current IGCS_CombatEntityInterface groups common Actor capabilities into these areas:

• Target and combat data: get the current target Actor or target SceneComponent, get the ComboDefinition DataTable, query AbilityActions by context and tags, and query weapons by TagQuery.
• Movement and input: get or set RotationMode, MovementSet, and MovementState tags, and query MovementIntent.
• Lifecycle: start and finish the death process, and query whether the entity is dead.
• Weapons and sockets: query or set the current weapon, and get a mesh's relative transform to a socket for weapon attachment or bullet-spawn alignment.

SetCurrentWeapon marks which weapon the next action will use; the project's equipment system performs the actual weapon switch. A common target implementation reads the current lock-on target from UGCS_TargetingSystemComponent.

Default Implementation and Project Integration

The example implementation shows how movement state and weapon selection can map to project components. To integrate an existing project, implement the interface on your Actor or a component and have its functions call the project's movement, equipment, and death logic. Combat Abilities then call a stable interface while the integration code adapts the project's systems.

If your project uses Generic Movement System, map GCS movement states and rotation modes to it in the interface implementation.

Implementing the Combat Entity Interface

The interface functions are BlueprintNativeEvents and can be implemented in Blueprint or C++. Both Actors and components can implement it; placing the implementation on a focused component often makes it easier to replace and maintain.

Using the Combat Entity Interface

Call GetCombatEntityInterface to retrieve the implementation on an Actor or one of its components. When the interface is optional, call FindCombatInterface and handle the not-found case. If the Actor implements the interface, the helper returns the Actor; otherwise, it returns the first matching component.

Use Case: Movement Ability

The Sprint example shows an Ability calling the combat-entity interface when sprinting starts and ends, while the interface implementation updates the project's movement state. The Ability therefore does not depend directly on a specific MovementComponent.

For example, an Ability can request a rotation mode through SetRotationMode using a tag. The interface implementation maps that request to the project's movement component.

This keeps Abilities reusable and centralizes interface adaptation when a project changes its movement implementation or adds new state tags.