Generic Combat System is a combat framework for action and multiplayer projects, built on and including Generic Input System and Generic Gameplay Abilities. It connects input, ability execution, Attack Definitions, Combat Flow, hit detection, projectiles, targeting, combos, weapons, and attack results into one pipeline for teams that want to keep their own characters, animation, and combat rules without rebuilding the combat stack from scratch.

Documentation and Support

• Documentation: 中文 English

• Playable Demo: https://cloud.yuewu.dev/s/qNTK

• Showcase Videos: Video 1 Video 2 Bilibili 1 Bilibili 2

• Community / Support: Discord

Why Generic Combat System?

Many action and multiplayer projects rebuild a similar combat flow: buffered input has to reach ability activation, animation windows open melee hits, projectiles preserve source and effect context, executed Gameplay Effects become replicated combat results, and those results drive death handling, hit reactions, guard logic, feedback, and events. The final combat style can vary widely, but the underlying offense/defense pipeline still needs shared context and explicit extension points; without that foundation, prediction, authority, combos, targeting, and debugging keep adding integration cost.

• How do melee, ranged attacks, projectiles, and environmental damage share one offense/defense flow instead of each path being authored separately?

• How do designers author each hit through data, such as slash direction, fire or frost traits, poise damage, knockback distance, and other combat context?

• How can the same attack produce different responses on different targets, such as monsters, bosses, buildings, or dogs, without making the attacker enumerate every possibility?

• How do local prediction and immediate combat feedback stay aligned with server authority?

• How can a project replace its core offense/defense behavior without modifying core plugin code?

GCS connects tagged input, GAS extensions, Attack Definitions, Combat Flow, and Attack Result Processors into one offense/defense pipeline. Projects can share combat context and replace core reaction behavior without writing a separate path for every attack type.

Key Features

Connect input, GAS, and attack results in one combat chain

GCS links GIPS tagged input and buffering, GGA AbilitySet / effect container / AttributeSet extensions, and the Combat layer's Attack Definitions, Combat Flow, and Attack Result Processors. Melee, ranged, ability-driven, and environmental damage can share the same combat pipeline.

Use Attack Definitions to describe attack context

Each hit can be authored through an Attack Definition: attack tags, SetByCaller values, Gameplay Effects, effect containers, Gameplay Cues, and project extension data can all live around one attack context. Melee traces, projectiles, and ability-driven attacks can reuse that definition so damage and feedback parameters stay tied to the same combat context.

Let Combat Flow decide how each target handles an attack

Combat Flow is the defender-side decision layer. GGA's AttributeSystemComponent forwards attribute-execution callbacks into Combat Flow; Combat Flow uses the target's own rules to create and register Attack Results, the result container replicates them to clients, and Attack Result Processors turn them into Gameplay Events, Gameplay Cues, death handling, hit reactions, or project-specific responses. The same arrow can produce a stagger on a humanoid, damage-only behavior on a giant boss, or a different response on a building without pushing target-type if/else logic back into the attacker.

Manage melee hits through traces and animation windows

Trace definitions support extensible shapes, sweep settings, and fixed-rate or distance-driven updates. Animation Notify States and Gameplay Ability Tasks connect authored attack windows to the trace runtime so characters, weapons, abilities, and hazards reuse the same hit-detection path.

Build replicated projectile patterns

Bullet / Projectile definitions support single shots, spreads, penetration, child chains, and timed emitters. Runtime components manage replicated entries, per-projectile state, hit history, Gameplay Effect application, and first-batch client trajectory / VFX prediction. Predicted bullets do not apply Gameplay Effects directly, and child chains or emitters stay authoritative.

Combine lock-on, team rules, combos, and weapon interfaces

Targeting Presets, selection tasks, and filter tasks support search, lock, switch, affiliation checks, death state, and Gameplay Tag requirements. Combos can select abilities by step, event tags, tag queries, and optional activation tests. Combat entity, weapon, trace causer, effect causer, and related interfaces let your project keep its character and weapon architecture.

Deep Gameplay Debugger integration

The Gameplay Debugger category exposes common runtime information such as combat flow, recent attack results, traces, projectiles, targeting, weapons, and combo state, helping you quickly identify which part of the input, ability, hit, effect, or result chain broke down.

Best Fit For

• Action RPG, soulslike, hack-and-slash, character action, third-person shooter, or hybrid melee/ranged projects

• Teams building combat on Unreal GAS, Gameplay Tags, Targeting System, and Enhanced Input

• Multiplayer games needing replicated combat state, local responsiveness, server confirmation, and debuggable results

• Projects that want input, ability, trace, projectile, targeting, combo, and weapon workflows connected while keeping custom animation, movement, damage formulas, and presentation

The GCS companion project uses soulslike mechanics as a case study to help you understand and use GCS. The product itself is combat infrastructure; damage calculation, death presentation, AI, UI, movement, animation selection, VFX/SFX style, and similar content remain project-owned.