
2025
PC - Unreal Engine 5
Bane of Darkness
Fight your way through the castle with your various magic monster killing weapons!
Role: Programmer
About The Project
Bane of Darkness is a casual single-player dungeon crawler built in Unreal Engine 5. Step into the role of a vampire hunter on a desperate quest to rescue your beloved from the clutches of a powerful vampire lord. Battle through perilous rooms, face relentless hordes of enemies, and grow stronger with every fight by wielding an arsenal of magical weapons.
Summary of work and contributions
Developed enemy attack functions
Developed the enemy AI and behaviors using unreal blueprints
Programmed early level system
General bug fixing and optimisation
VFX
Team
Dylan Yee - Programmer, Audio Engineer
Zerend Sandor - Lead Game Designer
Sasha-Lee Kuzmanov - Producer, Audio Engineer
Eli Merckel - Lead Programmer
Zan Hazlan - Programmer
Kaelum Grossett - Artist
Farhaan Hanif - Artist
Brenten Edwards - Game Designer
Jorja McGrath - Artist
Project Outcomes
This project was a big learning experience for me, especially in terms of working in a larger team and getting up to speed with new tools. Since it was my first time using Unreal Engine, I had to learn quickly early on so I could contribute to development.
Being part of a capstone project with 9 people also gave me a better understanding of how larger teams operate. While I was already comfortable managing GitHub repositories in smaller teams, working at a larger scale introduced new challenges, and I had to adapt my workflow to better handle collaboration, branching, and merge conflicts.
Overall, I came away from this project feeling much more confident both in Unreal Engine and in my ability to work effectively as part of a bigger development team.
Gameplay Video
My Process

Early Development
During early development, I had mostly simple tasks given by my programming lead. This was great for me to get the hang of Unreal Engine blueprints. I was originally intimidated with the visual programming and the complexity of the engine since I was coming from a Unity background, but I got the hang of it quickly and made some simple systems. One of which was the early version of the leveling and XP systems.
I followed a few video guides to create XP orbs that could spawn and be attracted to the player. This laid the foundation for the levelling system for the player that would be improved upon later.
Early Enemy AI Development
One of the major roles I played for the development of Bane of Darkness was developing the enemy AI. Early in development I was tasked with just making the enemies work. Since the game was intended to be easy for players, enemies weren't supposed to have complex behaviour so the team settled on using blueprints for the behaviour over using behaviour trees. The task of making the first enemies was a simple enough task as it just involved me having to add an attack function for the enemies and creating a function for the player to take damage.
The early iteration of the basic enemy which later became the ghouls was incredibly simple. They had a wander behaviour and a move to player behaviour. If the player was within range to them, the player would take damage at certain intervals. This iteration of the enemy behaviour turned out to be incredibly buggy during playtesting. Players would be hit from far away between rooms, the enemies would get stuck facing walls, or the enemies would swarm the entrance doors. I had clearly made mistakes within the blueprints and flow of behaviours.
After analysing what aspects of the behaviours went wrong, I was able to fix most of the bugs and had simplified how the enemies worked. To fix some of the attack range bugs and timings, I switched the damaging behaviour to an animation event, which allowed for more precise control to when the enemies hit over using an internal timer, and I changed the attack from a distance check to a damage box. This meant that the player could avoid damage if they went behind the enemies. To fix the enemies getting stuck facing walls, their awareness system was overhauled. Instead of wandering and having to see the player before moving, the room would alert all enemies after the player entered the room.
From these changes, the enemy was now a suitable base for the two other enemies to be added. The shield enemy, which would charge at players, and the ranged enemy. A type of enemy that didnt move but would shoot from afar.
Enemy AI Continued
While I had created the initial variations of the the three enemy types, my work with them was not over. Over the team's mid year break, we had decided that to add polish to the enemies for release, they needed more dynamic behaviour and interactivity. This meant more behaviour to the enemies and new models, animations and sounds.
The ranged enemy needed a lot more work to make it more interactive with players. In their initial state, they would not warn players when they were about to fire, making dodging impossible. This was fixed with a small flash indicator above their head when their about to fire. VFX and SFX were added to enhance the enemies. Over time the artists also added their new models and animations to make them into the skeletons seen in the final game.
The shield enemy had a lot of work done to it to make them stand out from the standard ghoul enemies. I created a new behaviour for it so that it can charge towards players and damage them, forcing players to weave around them since their shields were more resistant to damage. As with the ranged enemies, the artists provided new models and animations for them. I also added VFX and SFX for when they hit walls.
I also gave the enemies stun states so that when they take damage, players get some visual feedback
Final Touches
Towards the end of development, my work had mostly slowed down. Most of my tasks involved bug fixing of the enemies or tasks in other areas such as VFX improvements. But the major work I did during the end of development was performance improvements. It was already known from early to mid development that Bane of Darkness had performance issues, we hadn't addressed it until that moment. I worked with our team's lead artist to work on finding solutions. We utilised a few performance analyser tools within Unreal engine to find problem areas. One function that slowed down the game in particular was the spawning of xp and health orbs. It was especially noticeable when there were many enemies dying or in the pot room full of pots. Players would feel an FPS drop everytime orbs would spawn. To fix this, I implemented an object pool for the orbs which preloaded the orbs.
I also used this knowledge to make sure enemies would disable their blueprints, models and collision boxes if they weren't in a loaded room.
Once all these last features were implemented, the team was able to publish to Steam and showcase the game at the QUT Capstone Showcase 2025















