Back to projects
The String Poet concept art with arcane, shadow and shield-bearing puppets
Champion Design · Combat SystemsChampion & Mechanics Designer

League of Legends Champion Ability Design

The String Poet — an original mage / controller who turns three puppets, their positions and their returning threads into a combat system.

RoleChampion & Mechanics Designer
TeamSolo · AI-assisted implementation
DurationPrototype v1 · October 2026
ToolsUnity 6 / URP · C# · Python · Unity Recorder

Ability showcase

Prototype v1 · 55 seconds

The String Poet in motion

A Unity gameplay recording with English on-screen captions. Watch the complete kit, or jump to a mechanic below.

1920 × 1080 · 60 fps · In-engine capture · Open video ↗

Design evolution

Click a node to explore

From puppetmaster fantasy to playable decisions

Follow the reasons behind each iteration: reduce execution overhead, preserve positional expression and make every returning thread matter.

01 · Design decision

The puppetmaster fantasy

Pain from Naruto inspired the idea of one will expressed through several bodies. My love of Jhin’s unsettling murderer-as-artist identity suggested the personality: an Ionia-inspired poet who treats his puppets as verses and combat as a performance.

01 · Inspiration & character concept

Visual direction

One will. Three bodies. A twisted performance.

Pain from Naruto sparked my interest in a character whose will acts through several bodies. Jhin’s identity as a disturbed artist who turns murder into performance is another character direction I love. Together, they shaped The String Poet: an Ionia-inspired, unsettling artist who calls himself a poet and treats his puppets as his verses.

The design challenge was to carry that fantasy into readable combat: commanding several bodies should feel expressive without requiring constant independent unit control.

Character concept sheet: The String Poet in red and black, a violet arcane puppet, a red shadow puppet and a white-armored repulsion puppet with a shield
Concept art · The champion and three distinct puppet silhouettes. The gameplay prototype uses placeholder models.View full-size sheet ↗

Design decisions

Problem → iteration

Reduce the inputs. Keep the decisions.

The initial concepts were reworked into the current two-cast prototype. These are my design judgments and intended player behaviours; the showcase demonstrates mechanics against test dummies.

01
Design problem

Several bodies compete for attention

The initial fantasy was a controller independently directing multiple puppets’ movement and attacks. I felt the input burden would overshadow combat decisions.

Iteration

Give each puppet a clear function

Azir’s approach to placing and moving soldiers inspired a simpler structure. Q threatens damage, W provides a position swap and E creates displacement. Each puppet has a distinct job.

02
Design problem

Three actions delay a response

Summon → move → activate asks for too much preparation when a threat suddenly reaches the champion. A Rengar leap was my concrete stress case for this proposal.

Iteration

Combine creation and placement

Deploy → activate reduces the sequence to two casts. E already pushes enemies aside during deployment; its recast pushes one enemy away. The kit retains setup decisions with less execution overhead.

03
Design problem

The fight ends at the recast

An early basic-attack mark passive did little to reinforce the puppet-and-thread identity. I wanted movement to remain useful throughout the exchange.

Iteration

Turn recall geometry into pressure

After a second cast, the puppet returns and damages enemies in its path. Repositioning changes that path, creating intended opportunities to kite, punish pursuit and turn a retreat into a counterattack.

04
Design problem

A fixed ultimate ignores preparation

If R always delivers the same payoff, the number of puppets committed to the field has little consequence.

Iteration

Scale the payoff with commitment

R’s damage and radius scale by one third per puppet. Only three puppets unlock the central knock-up. The design asks whether to use a partial ultimate now or preserve the field for a stronger convergence.

Current kit

Mage / Controller · Prototype values

Deploy → activate → recall

Three functional puppets share one loop. The second cast resolves the puppet’s ability, then its return adds a further positioning challenge. Values below describe the current prototype and remain open to balance testing.

P

Threadbound

After a recast, the puppet returns along its thread and damages enemies in its path. Puppets beyond the 1,000-unit thread limit are also recalled.

Design intent

Positioning defines the return path. The distance limit constrains how far the player can maintain a formation.

Q

Arcane Puppet

Deploy up to 500 units, then recast for a cone of arcane force from the puppet’s position. Deployment itself deals no damage.

Design intent

Separate placement from damage so the player has to choose the attack origin and the moment to fire.

W

Shadow Puppet

Deploy up to 400 units across terrain, then recast to swap positions with the puppet. Deployment itself deals no damage.

Design intent

Create a relocation option for escape, pursuit or a changed recall angle. Its range increased from the initial 300 units.

E

Repulsion Puppet

Deploy up to 500 units, damaging enemies and pushing them 120 units to either side. Recast for a 250-unit shield charge that drives one enemy forward, with wall-impact feedback.

Design intent

Offer immediate space-making during deployment and a more directed answer on the recast. Reduced lateral push avoids excessive displacement.

R

Triune Collapse

Puppets within 1,000 units converge and detonate. Each contributes one third of the full damage and radius. At three puppets, the inner zone knocks enemies airborne.

Design intent

Reward full setup while allowing a smaller immediate response. Outer damage and inner control indicators communicate the different zones.

Passive demonstration: a returning puppet crosses the line between its deployed position and the moving champion
P · Recall geometryRepositioning changes the return path and creates another damage opportunity.
Arcane Puppet's purple cone attack fired from its deployed position toward a practice dummy
Q · A separate attack originThe puppet’s location defines where the second cast begins.
Unity sandbox environment validation: grounded Azir placeholder, terrain and towers, calibrated camera, vegetation and a League-style HUD

Environment validation · Character scale, terrain, vegetation, camera and HUD.

02 · Unity test environment

Judge the kit in a familiar combat space

I wanted the prototype to answer how this champion might feel inside League. In Unity 6 with URP, I assembled a Rift-style sandbox with game-unit scale, an isometric camera, right-click movement, QWER controls, terrain collision, practice dummies and a League-style HUD.

A shared coordinate conversion uses 1 Unity unit for 100 game units. NavGrid-based ground and wall checks support movement, wall sliding, corrected Flash destinations and W’s cross-terrain placement. Camera framing and scale were calibrated toward League’s presentation; the result is a champion test environment rather than a complete match simulation.

Prototype workflow

Design → playable evidence

Build tools that keep iteration repeatable

With AI coding assistance, I turned repeated conversion, setup and recording tasks into tools so I could spend more time making design decisions and evaluating the result in-engine.

01

Implement the loop

A puppet state machine handles flight, placement, activation, convergence and recall. Exposed Inspector values make range, timing and displacement easy to tune.

02

Make effects readable

Python conversion and a Unity editor importer turn effect definitions into particle prefabs. Shader fixes address UV clamping, particle-age scrolling, vertex alpha and Gamma-style additive blending.

03

Play, diagnose, verify

I replayed the prototype, described the observed issue and checked the next revision visually. E’s push direction follows the charge; shield disappearance and hit-stop were adjusted for clearer impact.

04

Stage the showcase

An F10 demo director finds suitable terrain, stages seven mechanic examples and records through Unity Recorder. Wall-detour checks make W’s demonstration meaningful; staging avoids brush because vision is not implemented.

My role & scope

What this prototype demonstrates

Design ownership, with AI-assisted development

01

My contribution

I owned the champion concept, kit mechanics, iteration decisions, numerical and game-feel judgment, playtest feedback and showcase narrative. Claude Code and Codex assisted with substantial code implementation, tools and asset conversion.

02

Placeholder art

I have no formal art background, so Azir represents the champion; Kassadin, Zed’s shadow and Braum stand in for the three puppets. Their silhouettes and effects communicate the functions. Original character work is in progress; the footage shows a mechanics prototype.

03

Next validation

Add opponent heroes and minion pressure to test reaction windows, counterplay and teamfight readability. Implement brush vision, then assess terrain interactions. Balance and competitive viability are still unvalidated.

03 · Why I made it

From watching every reveal to making my own

I never miss a League of Legends champion preview. I wanted to make one myself: take an idea, question its execution burden, build the revised kit and present it through an ability showcase. This project is a step toward my ambition to become a game designer at Riot Games.

“All are puppets. Only I hold the strings.”

Watch the showcase ↑

Fan-made, non-commercial champion concept. League of Legends and all related reference assets belong to Riot Games. This project is not endorsed by Riot Games. This page presents gameplay video and screenshots.

Next projectCars Don’t Fly