Paraclysm

Paraclysm is a top-down roguelite action game developed by Voidframe Studio. As the studio's project lead and a gameplay scripter, I led five other team members in building a three-minute playable demo from scratch over three months during the semester.

Inspired by Hades and Shape of Dreams, we established top-down action combat as the core direction. For ability building, we wanted to push replayability further, so we deliberately designed the ability system to be more flexible and extensible.The game centers on a composable ability system: players can acquire and freely arrange different ability modules to change target selection, delivery behavior, and final effects.

Paraclysm's modular ability system was inspired by games such as Noita that emphasize free-form ability construction.We wanted to bring a similar degree of build freedom into a faster-paced top-down action game while preserving the roguelite loop of continually acquiring and experimenting with new abilities.Instead of choosing only from a set of preset abilities, players can break abilities apart and recombine them. This made the modular ability system the central gameplay design of Paraclysm.

In Paraclysm, a complete ability is not a fixed, prebuilt skill. Instead, it is assembled from multiple ability modules that can be freely rearranged.The system mainly divides these modules into two types: Ability Bases determine how an ability finds a target or delivers its effects, such as locking onto the nearest enemy or spawning a projectile;Ability Effects determine what ultimately happens, such as dealing damage, restoring health, or applying another status. In simple terms, the Base determines the target or delivery method, while the Effect determines what is applied.

Players build abilities by changing the order of modules in the ability bar. The system reads modules from left to right, and each Ability Base is grouped with one or more Ability Effects that follow it until the next Ability Base is encountered. This allows a single ability bar to contain multiple distinct ability combinations at the same time.

For example, combining 'Target Nearest Enemy' with 'Deal Damage' makes the ability apply damage directly to the nearest target. If the same damage effect is placed after 'Spawn Projectile,' the damage is instead delivered through the projectile. Players do not need to acquire two completely separate abilities; they can change ability behavior simply by recombining modules they already own.

During each run, players acquire new ability modules by defeating enemies and exploring the map. Collected modules are stored in the inventory. At any time, players can drag modules from the inventory into the ability bar to replace or rearrange the components currently in use, allowing them to adjust their build while progressing through a level.

Internally, both Ability Bases and Ability Effects are stored as Data Assets derived from a shared ability-module data structure. An Ability Base stores its associated Gameplay Ability, which defines targeting or delivery behavior. An Ability Effect stores its associated Gameplay Effect along with the tags, magnitudes, and other data required by that effect.

Whenever the ability configuration changes, the system parses the ordered modules into multiple executable groups. One Ability Base is grouped with every Ability Effect that follows it until the next Ability Base is encountered. For example, the following sequence is compiled into two independent execution groups:

Target Nearest Enemy (Base) → Damage (Effect) → Debuff (Effect) → Projectile (Base) → Damage (Effect)

Target Nearest Enemy + Damage + Debuff  and  Projectile + Damage

On a single cast, the system therefore first applies damage and a debuff to the nearest enemy, then fires a projectile that deals damage on hit.

Within each group, Ability Effects are also resolved from left to right. To balance larger abilities, the player's cast cooldown is determined by the sum of the cooldown contributions from all modules in the configuration.

Rather than purely technical challenges, this section is closer to the problems I encountered the first time I tried to build a collection of systems that all had to work together.After solving them, I may never make the same mistakes again, and some of them may not even look like problems to an experienced developer.But they are exactly the kinds of questions that appear on a first attempt, such as deciding how to make sure every system uses the same up-to-date information.

Data Storage

Before designing this core system, I had limited experience coordinating multiple systems, so my first implementation stored inventory-slot information directly inside UI elements - which was not a good decision.At the same time, I already had inventory and weapon components attached to the player Blueprint. That meant I effectively had three separate stores of data, one of which was even divided slot by slot and manually indexed.I had promoted three systems that should not have had equal authority to the same level, then expected each one to notify the other two whenever anything changed. It was possible to implement, but inefficient and confusing.

I then refactored this part of the system. Now, whenever a module changes, the UI requests the current data from the components on the player Blueprint and uses it only to update the item icon shown in each slot; the UI no longer stores authoritative gameplay data.When a drag-and-drop action occurs, the UI simply sends a change request to the player Blueprint and waits for the inventory to update before refreshing in the usual way.As a result, the meaningful source data exists only in the inventory and weapon components on the player Blueprint. All updates go through those components, and after a change is applied, an Event Dispatcher broadcasts the update to the other systems.

Paraclysm was an ambitious project, but three months of development alongside the pressure of other courses meant we fell far short of what we originally hoped to build.Looking back, we could have chosen something simpler, such as a Vampire Survivors-like game or some form of card game, but I am glad we chose to make Paraclysm.A simpler genre might have meant much less pressure and allowed me to focus on only a few systems, but it also might have left more of the work at a level that AI/LLM tools could directly replace, without forcing me to engage with deeper architecture and structural design.The most important experience I gained from this project was therefore system and project architecture. Before this, I could read an assignment brief, build one isolated system, and tell myself: the data can temporarily live here, or I can hard-code this for now.This project pushed me out of that comfort zone and gave me my first step from simply completing assignments toward actually designing a game, even if it was only a small step.

Because of scheduling problems at the university and the resulting team changes, this game was originally supposed to have a full academic year of development time - around eight months - rather than only the second semester, around three months. Voidframe Studio was formally established in December 2025 after members of the original production group left and the team was reorganized.Not every remaining member was able to complete their assigned work, but two teammates were indispensable to the project: our technical artist, and the teammate responsible for operations and release-related work.

All visual effects in the current demo, as well as the player and enemy models, were created by our technical artist. Because we did not have a dedicated artist, he also used AI to fill gaps in our art production, such as generating concept images and ability icons.Our operations teammate set up the Perforce workflow and handled platform and legal considerations related to releasing the game in the United States. Her experience creating map materials also helped the team's level designer complete several maps.