Introduction

Creating a combat system is a complex task, and making one that is clean and decoupled from unrelated systems (such as the movement system and inventory system) is even more challenging.

To keep GCS pure and free from coupling with other systems, it provides the GCS_CombatInterface. Any functionality within the combat system that may require different implementation logic or should be handled by third parties is implemented through this interface. This is accessed via a static function called GetCombatInterface, which queries the combat interface on a given Actor or its components.

You can refer to the default implementation and freely reimplement this interface in an Actor or component using Blueprints or C++. Alternatively, you can copy or inherit the default implementation and start customizing it.

In the actual code implementation, any code that needs to interact with external systems is referred to as "glue code," which serves to link different systems together.

Design Diagram

Default Implementation Overview

Since GCS already provides a default implementation, the content of this document is more suited for users who enjoy assembling different systems or those who have ongoing projects and wish to switch combat solutions midway. It is also for users who are not satisfied with the simple default implementation.

The GCS demo project provides a straightforward default implementation to handle logic such as movement state logic and equipment switching logic.

In practical projects, you likely already have your own inventory or movement system, so modifying the default implementation of the Combat Interface is the best way to integrate it into your project.

I also have my own generic movement system and inventory system, and I used the same approach to replace them with my own implementations, which did not affect the logic of the combat system itself.

Users who have purchased Generic Movement System can enjoy native integration(Coming soon) with the combat system, making for a perfect combination of combat and locomotion.

Implementing the Combat Interface

Each function in this interface is documented with detailed comments and implementation guidelines, so I won't repeat those descriptions here. You can implement this interface in an Actor, but I recommend implementing it via a component.

Using the Combat Interface

Typically, you should not directly use objects that implement the interface; instead, call the relevant interface functions through GetCombatInterface or FindCombatInterface.

For example, as shown in the following image, you just need to ensure that the AvatarActor or one of its components indeed implements GCS_CombatInterface, allowing you to correctly obtain a reference to the combat interface and call the relevant functions.

Use Case

I have a skill called GA_GCS_Sprint that controls whether the character is running. This skill includes OnSprintStart and OnSprintEnd events.

Since this skill affects the character's movement style, instead of directly setting the parameters of the CharacterMovementComponent within the skill, I call it as follows:

For instance, in the default implementation (BC_GCS_DemoCombatCore),

You can see that I only retrieve the CharacterMovementComponent at the end and set the relevant parameters. You might think this approach takes a long way around, but it has several benefits:

1. It ensures the reusability of GA_GCS_Sprint without coupling it to the CharacterMovementComponent.
2. You can add new rotation modes, making the use of Tags flexible enough.
3. Epic is developing Mover 2.0 to replace the traditional CharacterMovementComponent, so when you truly wish to switch to Mover 2.0, you won't need to search everywhere for instances of CharacterMovementComponent.