The Stairs Go Down
Personal Project, January 2026 - Present
My Role
As the sole developer for this project, outside of art assets, all design and engineering work was completed by myself. This project originally started as a way for me to learn about Unreal’s Gameplay Ability System. After completing a strong foundation in GAS I was able to quickly iterate and implement mechanics and features that allowed me to advance my learning project into a realized game.
What is The Stairs Go Down?
The Stairs Go Down (SGD) is a first person dungeon crawling exploration game inspired by classics such as King’s Field .
The player will find items and magic spells all while fighting enemies as they continue their descent.
Play it on Itch!
What I did
Used Unreal Engine’s Gameplay Ability System (GAS) to implement abilities used by both the player and enemies.
Designed mechanics to encourage the player to interact with the game world.
Implemented custom tasks and decorators in Unreal’s Blackboard system for enemy logic.
Built a level using a combination of the geometry brushes and modelling tools offered in Unreal Engine.
Assets Used
KayKit asset packs - Enemies,Animations,Meshes
FreeStylized - Materials
Gameplay Ability System
Learned how to use and mount GAS in an Unreal Engine project.
Created abilities that could be used simultaneously by the player and enemy npcs such as attacking or shooting projectiles.
Made use of numerous Gameplay Tags to automatically handle logic such as being frozen solid or ignited by fire.
Implemented Gameplay Effects that could manipulate attributes such as equipment or damage over time.
Wrote my own custom Calculation Class in C++ to handle more complex logic between attributes such as attack and defense values.
Linked all of these properties together with the Gameplay Cue system to create satisfying visual feedback that automatically updates to the current state of the game.
Blueprint of Player_Attack Gameplay Ability
Video demonstrating fire effects with GAS
C++ implementation for damage calculation class
Video demonstrating frost effects with GAS
Blackboards and Behavior Trees
Used UE’s Blackboards and Behavior trees to implement the enemy character functionality.
Created Tasks, Decorators, and Services to fufil my designs for enemies.
Structured task implementation around GAS so that the same behavior tree could be used by both melee and ranged enemies.
Connected logic between Blackboards and Animation Graphs that allowed enemies to respond and to appropriately react to the state of the world and themselves.
Blueprint of Behavior Tree Task Activate Ability
Behavior Tree shared by all enemies
Video showcasing enemies
Interactable Objects
One of the ideas that sprouted early into development was making use of the camera to interact with the world rather than just purely for observation, opening a door for example would require the player to move the camera while “holding” the door rather than just pressing a button and watching it automatically open.
While the intention was for the camera to move in conjunction with the object being grabbed, for large objects such as doors this ended up proving fairly disorienting so the camera was made to stay stationary for large objects but remained mobile for light objects.
This was handled through GAS and the Interact ability changing which logic it used based on the tags possessed by the target.
Blueprint of the Interact Ability
Video showcasing some of the interactable objects in game
Post Mortem
This was my very first time working with Unreal Engine’s Gameplay Ability System (GAS). The goal of the project was to simply learn how to effectively use GAS in creating interesting features and content for games in Unreal. My decision to use a dungeon crawler as a base was because it was a genre of game that I had made before and I felt that learning about GAS in a genre I was familiar with would better my understanding than trying to make a “new” game alongside learning it. Overall I am content with my decision to both learn GAS and use a dungeon crawler as the platform to learn it. Initially progress was fairly slow because a lot of documentation of GAS is either very limited or nonexistent, but because GAS requires C++ to function I spent a good chunk of time diving into and reading through the C++ code itself. Another challenge was that much of GAS’s language is very similiar despite doing different things. For example, when using tags to conditionally maintain or remove effects from a character you would use the “Require Tags to Apply/Ongoing/Remove” component in a gameplay effect. When selecting the tags for continuing or pausing the effect the phrasing is the same as the tags for removal however, the logic is inverted. Choosing to require a tag will maintain and remove the effect while the wording would lead you to believing it was the opposite for removal and not allow the effect to be removed at all if that tag was missing. While the solution ended up being very simple, switch the logic around, small language problems like these cost me a lot of time. Overall, after I learned the “rules” and three main components of GAS; Gameplay Abilities, Gameplay Effects, Gameplay Cues, I now understand how powerful it is as a system and am looking forward to learning and using it in more projects.
More Projects
