TRIGGER HAPPY

4 Weeks

Gameplay / Scrum Master / Sound & Music

10

Unreal | Jira | Perforce | Miro

Trailer

Overview

This FPS endless roguelike was made during a 4-week-long Game Project at Futuregames. 

The team was incredibly dedicated, certain of how they wanted to contribute, and in line with the vision. We enforced feature and content freezes to manage the scope, and agreed to cut features that weren’t milestone-ready. Thanks to this and open communication throughout, the team stayed on track throughout the whole project.

In-game screenshots

Responsibilities

Design:

  • Player movement
  • Progression design
  • Combat abilities
  • Overall player feel

Prototyping many core systems in Blueprints

Scrum Master & Producer:

  • Set milestone goals
  • Structured sprints
  • Maintained Jira
  • Scrum ceremonies
  • Enforced feature & content freezes

Player & Combat Design (Gameplay)

Our design goal for the player was “smooth and fast”, which I translated into chainable high-mobility mechanics that encouraged flow and rhythm.

Starting from Unreal’s FPS template, I replaced most logic with custom movement mechanics, such as dashing, vaulting, and sliding, all controlled through state-driven checks. I opted to skip a traditional jump, as our level design didn’t require verticality, and instead implemented as many of those mechanics as possible to the spacebar for intuitive traversal. This pushed an agile playstyle that testers described as “rhythmic” and “rewarding.”

Mechanics & ability showcase

Most player logic was reimplemented in C++ for better performance and the programmer’s portfolio, where I guided them to preserve responsiveness and the intended feel of all designers’ player prototypes, and tweaked them to align with design intent.

In-depth: Vault

Controlling the vaulting state inside the Dash logic with a line trace in front of the player enabled smooth state transitions, making the player more intuitive and fun to navigate.

Custom event “Vault” resides in the Dash logic and performs a forward line trace from the player and validates that the hit actor has the “Vaultable” tag. On a valid hit, it sets GroundFriction to 0 and uses LaunchCharacter to apply an upward impulse and a forward impulse along the player’s forward vector to slide the player over the obstacle. Vaulting checks happen both in Dash.Started and Dash.Ongoing to allow for triggering a vault mid-dash.

In-depth: Slide

Prototype

Release build 1.0

For additional maneuverability, I implemented a slide mechanic that allows the player to powerslide when crouching while sprinting. It fed into the smoothness of the character and the push-forward vibe of the game. After C++ implementation, I spent a lot of time tuning values like slide strength, duration, and ground friction to match the intended feel of my prototype.

Sliding latches onto the sprinting and crouching logic. Crouching while sprinting launches the player character towards their aim with its ground friction reduced for the remainder of the slide duration or until crouching is cancelled.

Progression Design

We put a lot of effort into adding an engaging progression system for player agency and replayability. Working with our systems designer and programmer, I designed and balanced stats, unlocks, and rarity tiers, and implemented them using a Primary Data Asset system built on gameplay structs (created by the programmer). Since we were three people involved in the system, I maintained documentation to keep iterations clear and transparent across design and programming. With the Data Asset system in place, I continuously tested values and refined the impact of each ability and stat.

I was responsible for setting stat and ability defaults and caps, upgrade steps per ability/stat, and unlock tiers (common -> legendary). When deciding on the unlockable abilities, I had to figure out a good key layout for how they were going to be used in-game in relation to default abilities to ensure chainability, which led to continuous discussions on which abilities to have default/unlockable, balancing, and a lot of documentation (using Excel and Miro).

Combat Design

Combat was built around hectic and impactful encounters. I designed and prototyped many player abilities, such as Melee, Slowmo, Shotgun, Explosive Rounds, Hookshot, and modified movement abilities with offensive variants. We built the abilities as modular components to allow for clean enable/disable logic and C++ integration. I also guided the programmer when implementing all abilities and adjusted and balanced them to better resonate with the design vision.

Combat abilities showcase

In-depth: Melee

I added a powerful and crunchy melee attack as a short-range “deleter” for when the player gets overwhelmed. Having a sphere trace to control hit detection, apply damage, knockbacks, and effects made balancing and iterating more straightforward, although size and number of spheres had to be thoroughly tweaked to connect correctly and achieve a sensible knockback. For game feel and pushing the dark comedy tone, I also added a strong “death knockback” onto hit enemies and a short time dilation to better convey its impact on hit. The result felt great, and when some testers started to build around the melee rather than ranged combat, I added as many melee-oriented variables as possible to the upgrade tree to enable further player agency.

HitDetect detects Pawns with the Damageable interface using a Sphere Trace. It starts from the player character’s upper arm’s location and ends at its rotation’s forward vector multiplied by a melee reach variable and incremented by the upper arm location. On success, it casts to the enemy base, launches detected enemies slightly (“alive knockback”), and damages as many of them as the attribute value allows for (an upgradable stat), and fires the effects and applies the “death knockback” to killed enemies.

In-depth: Hookshot

The idea of the hookshot (inspired by Roadhog in Overwatch) was to give the player more ways to take down enemies by pulling them in for easier short-range attacks. I planned to let the player grab and use pulled enemies as a shield, but before adding it, we sadly decided to cut the entire Hookshot mechanic. Playtesting proved it leaned too much into a passive playstyle, and there wasn’t enough time to implement it by the gameplay programmer. To address the passiveness design issue, I plan to remake the ability so that the player is dragged towards the hit enemy instead.

BP_Hook

BPC_Hookshot

Scrum Master & Producer

  • 4-week schedule (4 sprints), zero crunch
  • 90% bugs fixed (100% P1) • 81 % delivery rate • 2-day avg cycle time

I structured our sprints, set clear milestone goals, and maintained a transparent Jira setup so each discipline had visible ownership and priorities. I enforced feature and content freezes to manage risks and led planning, reviews, and retros to spot blockers early. This kept the project stable and allowed us to ship a full, polished loop within four weeks without last-minute chaos.

Milestone report examples

The design lead and I used the milestone reports to get a clear perspective of project progression, which helped us decide about resource allocation and discuss our status with the team and school.

What I learned

This project was pivotal for me in becoming a stronger bridge between design, programming, and production, where owning the player mechanics from concept to implementation strengthened my understanding of technical design and iteration workflows. From the Production perspective, I learned to balance creativity with production discipline, keeping the team aligned and scoped even under a tight deadline.

Because of the short deadline, designer prototypes weren’t tested enough before C++ implementation, which led to difficulties matching the final implementation with the intended experience. Moving forward, I’m going to push harder for proper internal testing and deeper game feel discussions before implementation to ensure a better match between creative vision and technical execution.

Mail-bulk
Linkedin