// 01
Purpose
GASOline is a C++ plugin I built from scratch in Unreal Engine 5.7 to give my RPG, The Resonance, a clean, reusable foundation on top of Unreal's Gameplay Ability System — instead of wiring an Ability System Component, attribute sets, and ability-granting logic by hand inside one game's codebase.
The goal was a plugin-level abstraction over GAS: drop in a working Ability System Component, attribute set, character base, and data-driven ability set, and get a project that can grant abilities and attributes declaratively instead of rebuilding GAS plumbing from zero every time. It's the difference between treating GAS as something I configure once and reuse, versus something I re-derive per project.
// 02
Implementation
Four core classes make up the plugin's public API, plus the build-system work required to get a custom GAS plugin compiling cleanly in the first place.
-
Custom Ability System Component The plugin's own Ability System Component subclass — the shared entry point every character in a GASOline-powered project uses to grant, activate, and manage gameplay abilities and effects.
-
Base Attribute Set A shared attribute set base that game-specific attribute sets build on — currently backing both the player and enemy attribute sets in The Resonance, keeping health, damage, and other stats on one consistent GAS-native path.
-
GAS-Wired Character Base Class A character base class pre-wired to the plugin's Ability System Component and attribute set, so any character subclass gets a working GAS setup by default rather than needing it re-plumbed per actor.
-
Data-Driven Ability & Attribute Granting A
UPrimaryDataAsset, modeled after Lyra's GameFeatureAction ability sets, that grants abilities and attribute sets declaratively from data instead of code. Each character type specifies its own attribute set through its own ability set asset, so adding a new character's kit is a data change, not a code change. -
Getting a Custom GAS Plugin to Compile Cleanly Standing the plugin up meant working through real Unreal Build Tool friction — resolving source encoding issues, chasing down module dependency errors, and tracking an MSBuild environment-variable bug down to a PowerShell-based build workaround. Unglamorous, but the kind of problem that has to get solved before any gameplay code compiles at all.
// 03
Impact
Every combat, health, and ability interaction in The Resonance runs through this plugin — it's the shared foundation the rest of the RPG's systems are built on top of, not a side experiment.
4
Core Plugin Classes
UE 5.7
Built From Scratch
1
Shared Architecture, Every Combat System
C++
Engine-Level Module
// 04
Media Gallery
This is engine-layer code more than it's a visual showcase — best represented with a class-diagram walkthrough and a look at the data-driven asset it powers.
Architecture
Plugin class architecture — core framework → game-specific layer
Ability Sets — Data-Driven Granting
DA_PlayerCombatSet — Sword, Finisher, Dash, Death, Hit React
DA_EnemyCombatSet — same asset type, a different actor's kit
// 05
Takeaway
Building GASOline is a different discipline than writing gameplay code inside one game. Every class here is meant to be consumed by code I haven't written yet — a future character type, a future project — so the API surface, module boundaries, and naming have to hold up on their own, not just work for the one enemy or one ability I happened to be testing against.
I've deliberately deferred one refactor: the player and enemy attribute sets for The Resonance currently live inside the plugin itself, which means GASOline still references that game's own gameplay tags rather than being fully game-agnostic. Moving those classes out into a game-side module is the honest next step, and I'm keeping the current structure as a portfolio example of where the line between "reusable plugin" and "game-specific code" currently sits, rather than pretending that line is already clean.
The build-system debugging — encoding issues, module dependency errors, an MSBuild environment-variable bug — is the part of engine programming that doesn't show up in a gameplay reel but is exactly the kind of problem a tools or engine programmer is expected to solve without being told how.