BEDROOM BRAWL

Lead Gameplay Programmer · Combat & Ability Systems

PROJECT DETAILS

Development: October 2025 – Present
Status: Demo completed · Development currently paused
Team Size: Approximately 20–30 developers
Role: Lead Gameplay Programmer
Primary Ownership: Combat, Abilities & AI

Team Size: 20 - 30

DESCRIPTION

Bedroom Brawl is a multi-mode hero shooter built around the idea of turning childhood toys into playable heroes. The long-term vision includes multiple game modes ranging from competitive PvP to Zombies, Tower Defense, large-scale Mech battles, Karting, and more.

The project has primarily focused on developing the hero shooter foundation, including Team Deathmatch, Payload, Conquest, and Mech-based PvP.

I was the primary owner of the project's combat, abilities, and AI gameplay systems, working across a team of approximately 20–30 developers. My responsibilities included health, shields, damage, melee and ranged combat, hero abilities, gameplay effects, AI behavior, and multiplayer-safe ability implementation.

One of the largest systems I developed was a custom modular ability framework built on top of Unreal Engine's Gameplay Ability System (GAS). I designed this system to make abilities highly reusable, data-driven, and compatible with both players and AI without requiring separate implementations.

The resulting framework significantly reduced the amount of work required to prototype new heroes and allowed our team to produce new gameplay concepts faster than the art pipeline could keep up with.

TECHNOLOGIES

Unreal Engine
Gameplay Ability System (GAS)
Blueprint
Multiplayer Gameplay / Replication
Data-Driven Gameplay
AI
Gameplay Effects
Animation Montages
Modular Ability Architecture

AREAS

Gameplay Architecture
Combat Systems
Ability Systems
AI Programming
Hero Design
Damage & Health Systems
Shield Systems
Melee Combat
Ranged Combat
Multiplayer Gameplay
Technical Leadership
Programmer Mentorship
Rapid Gameplay Prototyping

My Contribution

My primary responsibility was owning the combat, ability, and AI gameplay layer of Bedroom Brawl.

This included:

Health
Shields
Damage
Melee combat
Ranged combat
Gameplay effects
Hero abilities
Ability interactions
Enemy AI
AI ability usage
Multiplayer ability replication
Reusable ability architecture
Data-driven gameplay configuration

I also became the primary owner of the AI and ability gameplay features, while mentoring other programmers and helping guide implementation where needed.

Because the project was intended to support a large roster of heroes, the primary engineering challenge wasn't simply making individual abilities work.

It was creating an architecture that made creating the next ability easier than creating the previous one.

The Ability Architecture Problem

From Animation-Driven to Data-Driven

The earliest versions of the ability system relied heavily on Animation Montage Notifies to determine when gameplay events should occur.

For example, an attack might rely on a specific montage notify to determine when its damage should be applied.

This worked, but it created a significant dependency between gameplay behavior and animation assets.

If a notify was:

Missing
Misplaced
Moved
Incorrectly configured
Or the montage failed to play correctly

The gameplay event could fail as well. This wasn't acceptable for the direction of the project.

The lead developer wanted the ability system to become fully data-driven, with gameplay behavior determined by the ability itself rather than depending on correctly configured animation assets.

That required me to rethink the underlying architecture rather than simply patching the existing system.

Data-Driven Ability Execution

I refactored the ability framework so gameplay events could be driven by data-defined timing and configuration rather than relying on montage notifies.

Instead of saying:

"When this animation reaches this notify, perform the attack."

the ability could effectively define:

"After this amount of time, perform the gameplay event."

This meant the gameplay logic remained authoritative even if an animation was changed, missing, or incorrectly configured.

Montages could still provide presentation, but the underlying gameplay behavior no longer depended on the montage being responsible for the timing of critical gameplay events.

This separation made the system significantly more robust and opened the door for abilities to be reused in situations where animation wasn't necessarily involved.

The Ability Mod System (Custom)

Modular Abilities Built on GAS

The biggest architectural system I developed for Bedroom Brawl was what I called the Ability Mod System, with "Mod" standing for Modular.

The problem I wanted to solve was simple:

How do you create complex abilities without creating a unique ability implementation for every combination of gameplay actions?

Instead of making every hero ability a monolithic implementation, I designed a system where one ability could activate and orchestrate other abilities.

This allowed complex behaviors to be constructed from smaller reusable gameplay pieces.

For example, imagine a hero ability consisting of:

Melee Hit → Melee Hit → Ranged Attack

Instead of creating an entirely new ability specifically for this combination, the system could reuse existing modular melee and ranged ability implementations and chain them together through a parent handler.

This allowed designers and programmers to construct increasingly complex abilities from existing building blocks.

Why the Modular Architecture Mattered

The goal wasn't simply to make abilities reusable. It was to make new content cheap to create.

With the modular approach, a new hero could reuse existing functionality while changing parameters and composition rather than requiring a completely new implementation.

A developer could create a new ability by combining existing components such as:

Melee attacks
Ranged attacks
Movement
Damage events
Status effects
Gameplay effects
Other ability behaviors

The result was an ability architecture that could support increasingly complex hero designs without the amount of custom code growing at the same rate as the number of abilities.

This was particularly important because the project was intended to have a large roster of unique heroes.

One Ability System for Players & AI

One of the most important requirements of the architecture was that abilities needed to work for both players and AI.

I deliberately avoided creating one implementation for player-controlled heroes and another for AI-controlled versions.

Instead, the ability architecture was designed so the same underlying gameplay abilities could be activated regardless of whether the request originated from a player or an AI controller.

This meant that the combat system could be tested and exercised through both sides of the game without maintaining duplicate gameplay logic.

The AI could use the same abilities the player uses, which significantly reduced the maintenance burden as the number of heroes increased.

This also made new hero prototyping much faster:

Create the ability → configure the AI behavior → the same gameplay implementation works for both.

Teaching AI to Use the Same Abilities

Creating AI behavior for a hero shooter is considerably more complicated when heroes have very different ability sets.

I needed the AI system to understand how to use the project's broad range of ability types without requiring every hero to have a completely bespoke AI implementation.

This involved building the AI behavior around the ability framework rather than hard-coding knowledge of individual abilities into each enemy.

The AI needed to understand things such as:

When an ability was available.
Which abilities could be used.
How abilities interacted with combat.
When attacks could be performed.
How abilities affected targets.
How the AI's available abilities changed its combat behavior.

The goal was to create a pipeline where introducing a new hero did not mean rebuilding its entire AI from scratch.

The Content Pipeline

One of the strongest indicators that the architecture was successful came from how quickly we could prototype new heroes.

Once the underlying systems were established, new heroes required comparatively little bespoke gameplay programming.

The combination of modular abilities + reusable parent classes + data-driven configuration + shared AI behavior meant that we could rapidly create and test new gameplay concepts.

The system became efficient enough that we were able to produce new hero prototypes faster than the art team could create the corresponding character assets and VFX.

While that eventually became a production bottleneck of its own, it was a good indication that the gameplay architecture was successfully reducing programming overhead.

The problem shifted from:

"How do we program this hero?"

to:

"How quickly can the rest of the pipeline produce the content to match it?"

Combat Systems

Beyond the ability framework, I was responsible for the underlying combat systems supporting the heroes.

This included:

Health
Shields
Damage
Melee attacks
Ranged attacks
Gameplay effects
Ability interactions
Combat state
Enemy interactions

These systems were designed to integrate with GAS so that abilities could modify combat state through a consistent gameplay framework.

The goal was to keep the individual combat mechanics independent enough that new heroes could combine them in different ways without requiring completely new versions of health, damage, shields, or other foundational mechanics.

Multiplayer Considerations

Bedroom Brawl was being developed as a multiplayer hero shooter, so the ability architecture also needed to function correctly within Unreal's multiplayer replication model.

I ensured that the gameplay abilities and their relevant gameplay behavior functioned correctly for multiplayer replication within the editor.

My responsibilities were focused on the gameplay and ability side of multiplayer behavior rather than server infrastructure or backend development.

I did not own the dedicated server infrastructure, backend services, or deployment pipeline.

My focus was ensuring that the actual gameplay systems—particularly abilities, combat interactions, and replicated gameplay state—behaved correctly within the multiplayer environment.

Technical Leadership & Mentorship

Bedroom Brawl was the largest team I had worked with at approximately 20–30 developers, and my role expanded beyond individual programming tasks.

I became the primary owner of the project's AI and ability gameplay features, while also mentoring other programmers and helping guide them through problems when needed.

This meant I wasn't only responsible for making my own systems work.

I also needed to make sure that other developers could understand and extend the architecture.

That required establishing reusable parent classes, creating predictable patterns for ability implementation, and helping other programmers understand how to work within the framework.

The modular ability architecture was particularly valuable here because it provided a consistent structure for new developers to build upon rather than requiring everyone to independently solve the same gameplay problems.

A Production Lesson:
When Engineering Outruns Art

One of the more unusual problems the architecture created was that we could prototype heroes faster than the art pipeline could produce them.

The modular ability framework made it inexpensive to create new gameplay concepts, and the shared AI architecture meant those abilities could quickly be tested by both players and AI.

As a result, the programming side of the hero pipeline occasionally moved faster than the production of:

Character models
Animations
VFX
Other presentation assets

This became an interesting production lesson in itself.

Optimizing one part of a content pipeline doesn't necessarily make the entire pipeline faster—it can simply move the bottleneck somewhere else.

In this case, the ability architecture successfully reduced gameplay programming overhead enough that content production became the limiting factor.

Refactoring Under a Moving Target

One of the largest challenges of Bedroom Brawl was that the requirements of the ability system changed significantly as development progressed.

The initial montage-notify implementation was functional, but it didn't satisfy the long-term requirement for data-driven gameplay.

Rather than continuing to build on top of the existing system, I had to discard substantial portions of the original implementation and rebuild the underlying execution model.

That refactor ultimately led to the Ability Mod System.

This experience reinforced an important principle I have encountered repeatedly throughout my Unreal development:

Sometimes the fastest way forward is to stop extending the wrong architecture.

The initial system taught us what the project needed. The second system was designed around those requirements.

Outcome

Bedroom Brawl successfully reached a playable demo, and the project is currently paused while the team works through further approval and funding processes surrounding Kickstarter.

My work on the project resulted in a reusable gameplay architecture capable of supporting a growing roster of heroes, multiple game modes, AI-controlled characters, and multiplayer combat.

The project gave me experience working on the largest team I've been part of—approximately 20–30 developers—while taking ownership of some of the most technically central systems in the game.

The biggest accomplishment for me was the Ability Mod System.

What began as a requirement to move away from animation-dependent gameplay execution evolved into a modular GAS architecture capable of composing complex abilities from reusable components and using those same abilities for both players and AI.

The system allowed us to rapidly prototype heroes, simplified AI integration, reduced duplicate gameplay logic, and established a scalable foundation for the game's combat pipeline.

Bedroom Brawl represents some of my strongest work in gameplay architecture and reusable systems design: identifying where an existing implementation was limiting the project, rebuilding it around the actual requirements, and producing a framework that made the next several features significantly easier to create.

Wishlist On Steam!

PREVIOUS PROJECT

NEXT PROJECT