Studio	Mediatonic / Epic Games (Sumo Digital)
Updates	10.2 – 10.9
Role	Client-side Gameplay Programmer
Engine	Unity

Blast Ball

(Full Ownership)

Networked obstacle · Client-authoritative · Dedicated main maps game · Integrated across all modes including creative

Blast Ball is a fire-propelled explosive obstacle that all 100 players interact with simultaneously. It is the central mechanic of its own dedicated game mode. I took it from a spec document to a shipped, live feature, holding full technical ownership across the entire development cycle.

Spec-to-ship ownership.

Translated the designer’s spec into networked gameplay, managing the full client-side implementation of obstacle behaviour, state, and integration into Fall Guys’ addressable and asset package pipeline for deployment across all game modes.

Designer-Focused Tooling.

Collaborated closely with designers throughout, building out granular tuning controls for explosion damage curves and force falloff mappings. This gave the team the ability to iterate on obstacle feel entirely in data — without touching code — which directly accelerated how quickly the feature found its game feel.

Live Game & Creative Integration.

Integrated the obstacle across all of Fall Guys’ game modes, including the creative mode and level editor, where obstacles must behave predictably under user-authored level configurations.

Blast Ball was not only a set-piece obstacle, it also had multiple dedicated game maps in the standard games rotation.

Bugs during production	Post-launch bugs	Delivered in
< 10	< 5	~60% of the planned timeline

---

Bounce Boards

Handoff · Diagnosis · Stabilisation

Networked obstacle · High player-count bug · Client-to-server authority migration

Bounce Boards were handed to me after their initial pass with an unresolved stability problem: at high player counts, the obstacle was misfiring. The root cause wasn’t immediately obvious — and finding it required getting into how the obstacle’s authority model was behaving under real network conditions.

Multiplayer Networking Refactor.

Identified that clients were lagging behind each other by ordinary network delivery time. Because each client held authority over the obstacle, multiple clients could independently decide they had activated it — firing activation events that should never have fired, because the obstacle was already active.

Authority model redesign.

Identified shortcomings in the obstacle’s networking model and contributed to transitioning activation and state management toward a server-authoritative approach, improving consistency and reliability across clients.

Server-side activation buffer.

The proposed solution: a server-side buffer collecting all incoming activation requests, each stamped with the originating client’s activation timestamp, allowing the server to verify which client genuinely triggered the event first. Owned the full client-side transition to this model.

This was a diagnosis-first fix. The bug was a symptom of the wrong authority model — identifying that distinction, and proposing the architectural change, was the actual contribution.

---

Speed Arches

Handoff · Refactor

Player modifier obstacle · Modifier system integration · Post-first-pass refactor

Speed Arches apply temporary speed boosts and stat overrides to players passing through them. I took ownership after the initial pass for a significant client-side rewrite, integrating the obstacle cleanly into Fall Guys’ shared player modifier system.

Player modifier system integration.

Rewrote the obstacle’s code to plug into the modifier system — the shared layer that governs how speed boosts, stat overrides, and appearance changes are applied, stacked, and resolved when multiple effects are active simultaneously.

Stacking and priority logic.

Correct integration required understanding the system’s stacking rules and priority resolution: how the modifier system decides which effects override others, and how those decisions surface through the player state machine.

---

Carryables & Draggables

Primary Maintainer

Networked obstacle family · Player locomotion system · Hierarchical networked FSM

Across the update cycle I was the primary maintainer for all newly introduced carryable and draggable obstacles — objects players can pick up, carry, or push, which influence their locomotion state while held. The work spanned both the individual obstacles and the underlying player carryables system itself.

Carryable Fan & Push Box Fan

Fan-force locomotion limits · Stacking control · Networked FSM intersection

Force stacking problem.

Both fan variants exert locomotion force on nearby players. At high player counts, multiple fans in range simultaneously could compound unboundedly — creating locomotion state outcomes that were neither intended nor replicable.

Controlled influence accumulation.

Contributed to how fan influence is accumulated and capped at the player locomotion level, ensuring that force application was both bounded and consistent across clients.

Replication stability.

Contributed to obstacle gameplay logic and replication for draggable obstacles, ensuring interaction behaviour stayed consistent when multiple players engaged the same object simultaneously — the edge case that surfaces most reliably at match scale.

---