FATE

Role
Game Designer & Product Owner
Owned
The entire boss encounter

Unreal Engine 5

  • Implemented boss attacks in GAS
  • Built the boss State Tree
  • Designed the symbol phase logic
  • Built modular hookups for VFX, SFX and animation
  • Calculated enemy density in a spreadsheet
  • Ran Product Owner duties

FATE is an online co-op FPS with a roguelike upgrade system built around Destiny-style raids. Players solve a raid mechanic across escalating encounters, then have to use it against the boss.

Engine
Unreal Engine 5
Genre
Online co-op FPS
Team
10: 4 designers, 4 programmers, 2 artists
Duration
7 weeks
Context
Futuregames Game Project 3
Refs
Destiny 2, Risk of Rain 2, Deep Rock Galactic, Overwatch 2
Build
itch.io link pending
First-person view of the FATE boss, The Ruined Guardian, during the Rocket Barrage attack.

The boss encounter

I owned the boss end to end: design intent, prototype, implementation, playtest, iteration. Everything below I built myself, inside a team of ten where four other designers were working on the encounters leading up to it.

The boss is the payoff for the raid structure. Whatever the player has been taught in the rooms before it has to come back here under pressure, which means the attacks can't just be damage. Each one has to ask a different question.

The attacks

Rocket Barrage is area denial. It doesn't threaten much damage on its own; it takes space away and forces the team to reposition while they're doing something else.

Laser Sweep is a directional line hazard, and it's the one tied to the raid mechanic: surviving it requires the tether to raise the defensive shields. A team that ignored the tether mechanic finds out here.

Ground Slam is the close-range punish, there so that the answer to "stay far away and shoot" isn't always correct.

I prototyped all three as straightforward Blueprint logic first, because the question at that stage was whether they were readable and whether they felt fair, not whether they were built correctly. Once they held up, I refactored them into Unreal's Gameplay Ability System so they'd replicate properly in a networked co-op game. The design survived, and I was the one who moved it onto the right foundation instead of handing over a prototype and hoping. The Ground Slam ability graph is readable on BlueprintUE.

The State Tree

The encounter runs on a boss State Tree I built: transitions, entry and exit conditions, and the flow-control logic that animation hooks into. Phase progression lives here too, so the boss's behaviour and its phase state are one system rather than two that have to be kept in sync.

The ST_Boss_1 State Tree in Unreal: Root leads to Pre-encounter and Intermission, then three phase states each entered on the actor's phase number, then Post-encounter.
The boss State Tree: each phase is a linked asset, entered on the actor's phase number

Symbol logic and phase progression

Phases advance through a symbol puzzle rather than a health threshold, so progress is something the team does rather than something that happens to them. I designed the logic and set up the skeletal mesh sockets the symbols attach to.

Modular hookups

What I'd defend hardest in an interview is that artists and programmers could wire in their own VFX, SFX and animations without going through me. On a ten-person student project with a hard deadline, a designer who has to personally connect every new asset is a queue. I built the systems so that queue didn't exist.

Enemy density

Encounter balancing started as intuition, which doesn't scale across four designers building different rooms. I built a Google Sheet that computes enemy density mathematically, so difficulty across the encounter could be compared as numbers instead of argued as feelings.

The enemy density sheet for encounter one: nineteen spawn points with thrall and fallen counts, spawn interval and pause duration, resolved into enemies per minute and per second, with total enemy health at the foot.
All spawn points in encounter one, calculation of spawned enemies and enemy health introduced per second

As Product Owner

Team contract, Greenlight preparation, and the extended GDD. Also the scope cuts. We shelved the Baptoad hero character and the procedural map system to protect the boss encounter and the raid structure, which were the parts the project was actually about.

What I'd do differently

I'd start structured validation earlier. We playtested, but we playtested generally: we'd sit someone down and watch. What I'd do now is define each test by the design question it answers: is this attack readable, is this phase too hard, is the pacing right, are players cooperating or soloing. Testing "does it work" gets you an opinion. Testing one question gets you an answer.