Castle Von Boom
Gameplay Systems Programmer · Combat Programmer
Castle Von Boom was created during the IGDA San Diego Game Jam 2025, where a team of 12 developers had 48 hours to build and ship a game around the theme “Sparks and Steel/Steal.”
Play as The Spark Knight, storming a fortress filled with living fireworks. Use your flint blade to spray sparks, slam your shield onto rails to grind through the castle, and light fuses as you fight your way inside.
Every enemy is a firework waiting to explode. Cherry Bombs blast wide, Bottle Rockets pursue targets from above, and Firecrackers pop and scatter everything in their path. Use their explosions against them to create chain reactions and tear the castle apart from within.
PROJECT DETAILS
Project: Castle Von Boom
Event: IGDA San Diego Game Jam 2025
Development Time: 48 Hours
Team Size: 12
TECHNOLOGIES & SKILLS
-
Unreal Engine
-
Gameplay Ability System (GAS)
-
Blueprint
-
Gameplay Programming
-
Combat Systems
-
Gameplay Ability System
-
Enemy AI
-
Character Movement
-
Traversal Systems
-
Systems Integration
-
Rapid Prototyping
-
Technical Collaboration
-
Game Jam Development
My Contribution
I served as the main gameplay systems programmer, focusing primarily on player combat, movement, enemy AI, and integrating gameplay systems developed by other members of the team.
I proposed using Unreal Engine's Gameplay Ability System (GAS) as the foundation for our combat and ability architecture. I established the initial framework and helped the rest of the team integrate their gameplay features with it.
A major focus of my work was connecting the game's individual mechanics into a cohesive gameplay loop. Combat, enemy behavior, movement, rail grinding, and the game's firework chain reactions all needed to interact consistently rather than function as isolated systems.
With only 48 hours to develop the game, my role required balancing maintainable gameplay architecture with the need to rapidly prototype, iterate, debug, and ship.
Technical Highlights
Gameplay Ability System
I proposed and implemented the use of GAS as the foundation for the game's combat and ability systems.
The primary benefit was separating gameplay abilities from the characters that used them. Rather than building every combat interaction directly into the player character, GAS gave us a consistent framework for handling abilities and their associated gameplay behavior.
This provided a modular foundation for rapidly iterating on the Spark Knight's gameplay while keeping individual abilities from becoming tightly coupled to the character implementation.
Because GAS was unfamiliar to much of the team, I also helped establish patterns for working with the system and assisted other programmers in integrating their gameplay features into the architecture.
Combat & Firework Mechanics
I implemented the core gameplay systems behind the Spark Knight's combat and its interactions with the firework enemies.
A central mechanic was the ability to light enemies on fire, turning them into active threats and opportunities within the combat loop.
Enemies could be ignited through several different interactions:
-
Depleting their health could ignite them.
-
The player's special attack could directly light enemies.
-
Rail grinding near enemies could ignite them as the Spark Knight passed by.
This allowed the same gameplay state to be reached through multiple forms of player interaction rather than tying it exclusively to a single attack.
The system was particularly important to the game's larger chain-reaction mechanic. Enemies weren't simply targets that disappeared when defeated; their firework properties made them potential sources of additional destruction.
This created a combat loop where the player could manipulate enemy states, ignite fireworks, and use their resulting explosions to affect other enemies and the environment.
The result was a combat system where damage, enemy state, traversal, and environmental destruction all fed into the same gameplay loop.
Enemy AI
I implemented and iterated on the gameplay behaviors for the game's firework enemies.
Each enemy type was designed around a distinct combat role:
-
Cherry Bombs create wide-area explosions.
-
Bottle Rockets pursue targets from above.
-
Firecrackers pop and scatter, creating chaotic interactions.
The AI needed to support these distinct behaviors while remaining compatible with the player's combat systems and the broader firework gameplay loop.
Because enemies could become ignited through several different player interactions, their behavior also needed to coexist with the underlying gameplay states that controlled their firework interactions.
The goal was to keep the AI simple enough to implement and tune within the 48-hour deadline while still giving each enemy type a meaningful gameplay identity.
Player Movement & Rail Grinding
I implemented and refined the player's movement systems, including the rail-grinding traversal mechanic used throughout the castle.
The rail system used custom target detection to identify nearby traversal opportunities and determine when the player could interact with a rail.
To make the mechanic readable without interrupting gameplay, I also implemented world-space UI indicators that provided visual feedback when a rail was available for traversal. This gave the player a clear indication of when a traversal opportunity was within range without requiring them to discover the mechanic through trial and error.
Rail grinding was also directly integrated with the game's combat mechanics. Grinding near enemies could ignite them, allowing the player to use traversal itself as an offensive tool.
A key technical consideration was integrating rail grinding with GAS and the existing gameplay architecture rather than creating a completely isolated movement system. This allowed traversal and combat to coexist without unnecessarily disrupting the player's ability flow.
The result was a traversal mechanic that could transition naturally between movement, combat, and environmental interaction, keeping the game's fast-paced gameplay fluid.
Systems Integration
A significant portion of my role involved integrating gameplay features created by other programmers.
With 12 developers working simultaneously, individual systems were often being developed in parallel. My responsibility wasn't only to make my own systems function, but also to make sure those systems could interact reliably with features being developed elsewhere in the project.
Rail grinding was one example of this integration work, requiring the traversal system to interact with the player's movement, GAS architecture, combat mechanics, and enemy states.
This required identifying conflicts between systems, adapting implementations where necessary, and ensuring that the final gameplay experience behaved as a cohesive system rather than a collection of disconnected features.
Technical Decisions
Designing Around Gameplay Interactions
One of the most important design considerations was avoiding isolated mechanics.
The game's central concept was that everything is a firework waiting to go off, so the systems needed to support interactions between combat, movement, enemies, and environmental destruction.
Rather than making ignition a single-purpose combat effect, I designed the gameplay around multiple ways of reaching the same enemy state.
An enemy could be ignited by:
Combat → Damage
Combat → Special Attack
Traversal → Rail Grinding
Once ignited, the enemy could contribute to the game's larger chain-reaction loop.
This created more opportunities for the player to discover emergent interactions and meant that traversal wasn't simply a way to move through the level—it could also become part of the player's offensive toolkit.
Why GAS for a 48-Hour Game Jam?
Introducing GAS into a 48-hour project came with additional setup and complexity, but I believed the structure it provided was valuable even within such a short development window.
Our combat system needed to support multiple abilities and different interactions while remaining easy to iterate on. Keeping gameplay logic separated from the player character gave us more flexibility than implementing every mechanic directly inside the character's Blueprint.
It also gave us a consistent framework through which different gameplay systems could communicate.
The tradeoff was that I had to spend some of the team's limited development time establishing a system that the rest of the team wasn't familiar with.
Ultimately, the decision came down to finding the right amount of architecture for the project's scope. The goal wasn't to build an elaborate framework for a game that would only exist for a weekend. It was to create enough structure that we could move quickly without turning every new gameplay change into a problem of tightly coupled systems.
Challenges
Building a Game With a New Team
Castle Von Boom was developed by 12 people who had never previously worked together on a game project.
Everyone was developing different parts of the game simultaneously, which meant system boundaries and communication became especially important.
As the primary gameplay systems programmer, I frequently worked between different areas of the project rather than only developing isolated features. This meant communicating with other programmers about how their systems would interact with the existing gameplay framework and resolving issues as those systems came together.
This made communication and system integration just as important as the implementation itself.
Introducing GAS
GAS was another challenge because it was not a system the rest of the team was familiar with.
I had to establish the initial architecture while also making sure other developers could actually work with it during the jam.
This meant helping teammates understand how their features should interact with abilities and the underlying gameplay framework rather than allowing every system to develop its own independent approach.
Working Under a 48-Hour Deadline
The biggest constraint was simply time.
Features needed to be implemented, tested, integrated, and iterated on while the entire team was simultaneously developing the game.
We also encountered the expected problems of a game jam, including last-minute source-control issues and lost work.
These situations reinforced the importance of making pragmatic technical decisions. With hours remaining, the best solution isn't necessarily the most elegant one—it is often the solution that restores functionality quickly while minimizing the risk of destabilizing the rest of the project.
Outcome
Castle Von Boom was successfully completed and submitted within the 48-hour deadline as part of a 12-person development team.
The project gave me the opportunity to take ownership of several interconnected gameplay systems while also helping establish the technical foundation that other team members built upon.
More importantly, it gave me experience working as a gameplay programmer in an environment where implementation, architecture, communication, and integration all had to happen simultaneously.
With only 48 hours available, every technical decision had to be evaluated against the same question:
Does this help us build a better game before the deadline?
That balance between engineering quality and development speed is one of the most valuable lessons I took away from the project.
