Paraclysm

Paraclysm is a top-down roguelite action RPG developed as a university team project in Unreal Engine 5. The project focused on giving players more control over how their combat abilities are built, allowing them to collect and recombine gameplay modules during a run instead of relying on a fixed set of skills.

I worked as Team Lead, System Designer, and Gameplay Scripter. My main contributions included building the modular ability system with Unreal Engine's Gameplay Ability System (GAS), designing its supporting data structures and execution pipeline, and implementing additional gameplay systems such as deterministic random streams. As team lead, I also coordinated task distribution and managed development across the five-person team.

The modular ability system is the core gameplay mechanic of Paraclysm. Instead of selecting abilities from a fixed list, players build their own by combining reusable modules collected during a run. Each ability is made from an Ability Base, which defines targeting or delivery behavior, and one or more Ability Modifiers, which define what happens to the target.

Internally, both module types are stored as Data Assets derived from a shared parent structure. Base modules reference a Gameplay Ability that defines targeting or delivery behavior, such as selecting the nearest enemy or firing a projectile. Modifier modules reference Gameplay Effects with their associated tags and magnitudes.

Before an ability is cast, the system compiles this array into executable groups. Each Base is paired with the Modifiers that follow it until another Base is encountered. This allows the same library of targeting and effect modules to be recombined into different abilities without requiring a separate implementation for every possible combination.

When an ability is cast, the executor processes the compiled module chain and executes each Ability Base together with its associated Modifiers. The project uses Unreal Engine's Gameplay Ability System (GAS) to handle Gameplay Abilities, Gameplay Effects, attributes, tags, and communication between players, projectiles, and affected actors.

A challenge I had was keeping the player's modules synchronized across the UI, inventory, and executor. Rather than allowing each system to maintain its own copy, they all read from or update the same data source, a blueprint component attached to player. Drag-and-drop changes update this compoenent and trigger recompilation, so the new module arrangement is ready for the next cast.

The main challenges were designing a data structure that could represent flexible player-created abilities, preventing invalid module chains from breaking execution, connecting custom ability data cleanly with GAS, and keeping the scripting UI synchronized with the compiled result. Earlier iterations stored too much state inside individual systems such as the UI; restructuring the project around clearer data ownership made the execution pipeline easier to maintain and extend.

The final prototype demonstrated a working runtime-modular ability system with examples such as damaging the nearest enemy, applying multiple effects to enemies inside an area, or healing the player. The architecture was designed to support a much larger library of Bases and Modifiers than the course project ultimately had time to produce. The project reinforced the importance of clear data ownership, scalable system architecture, and separating gameplay logic from UI state.