FATE
- Role
- Game Designer & Product Owner
- Owned
- The entire boss encounter
Unreal Engine 5
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.
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.
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.
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.