SWRMS

Combat and progression as one loop

The core design problem was ensuring that combat upgrades changed how the player approached encounters rather than functioning only as background stat growth. I worked across melee and ranged gameplay, abilities, stat scaling, progression, and reward systems so that moment-to-moment combat and long-term growth reinforced one another.

• Defined gameplay systems for melee and ranged combat within a mobile action format.
• Connected stats and progression to combat performance while keeping the underlying rules readable enough to tune.
• Worked across design and implementation, allowing balance changes to be tested directly rather than handed off between disciplines.

Boss encounters built around recognition and response

I designed bosses as structured tests of the player's combat knowledge. Each encounter was planned through attack roles, phase transitions, telegraphs, recovery windows, pressure patterns, and intended counters rather than as a collection of unrelated attacks.

• Authored mechanics, attack patterns, phases, pacing, and escalation across complete encounters.
• Designed telegraphs and punish windows so difficulty came from reading and responding, not from hidden information.
• Balanced pressure, downtime, positioning, and player damage opportunities to avoid both passive waiting and unavoidable overlap.

Designing for mobile production constraints

Combat had to remain readable and responsive on mobile hardware while coexisting with VFX, animation, networking, backend persistence, and a live content pipeline. This required evaluating mechanics not only by their ideal design but by input clarity, screen readability, performance cost, and production feasibility.

UE5 gameplay architecture

I implemented gameplay systems in Unreal Engine 5 using Blueprint and C++, building reusable foundations for combat, stats, progression, and encounter logic rather than isolated one-off scripts.

• Developed combat behaviours, progression rules, stat scaling, and gameplay state management.
• Structured systems for iteration so designers and developers could tune values without rewriting core logic.
• Integrated mobile-facing gameplay with the wider production build and release pipeline.

Boss logic from phase plan to playable encounter

Boss designs were implemented as executable state and behaviour logic, connecting attack selection, phase conditions, timing, damage windows, telegraphs, VFX, animation, and failure recovery into a complete encounter.

• Translated encounter plans into state-driven gameplay behaviour.
• Coordinated animation and VFX requirements around gameplay timing and readability.
• Kept tuning parameters accessible so pacing and difficulty could be revised through playtesting.

Backend and live production systems

Alongside combat work, I built online trading and persistent backend integrations, implemented monetisation systems, and supported live releases. That broader ownership helped me design gameplay with persistence, economy, failure handling, and production realities in mind.

Encounter tuning through playable behaviour

Bosses were reviewed as player-facing loops rather than static specifications. Attack timing, phase pacing, telegraph length, recovery, and overlapping pressure were adjusted according to whether the player could identify a threat, choose a response, and earn a meaningful punish window.

Cross-disciplinary combat iteration

Animation and VFX were treated as functional parts of combat. I worked with artists and designers to align visual anticipation, impact, and recovery with the underlying gameplay timings instead of applying presentation after the mechanic was complete.

Feedback reaching production faster

I helped improve the player feedback pipeline so gameplay issues could be reproduced, prioritised, and resolved more quickly across live builds. That shortened the distance between observed player problems and practical iteration.