Shipped

Blade Blitz @ Hella Studios

A solo-built local multiplayer sword-fighting game, from design system to shipped Unity implementation.

Designed and built Blade Blitz end to end. Visual identity, UI, characters, implementation, and live playtest iteration over two years.

Client
Hella Studios

Skills
Game Design
UI/UX Design
Branding
Coding (C#)
Marketing

Tools
Unity
Blender
Photoshop
Figma
Aftereffects

My Role
Founder & Sole Developer

Timeline
Q1 2024 - March 2026

Challenge

I wanted to make my first solo-developed game. The inspiration was Nidhogg — a tight 1v1 sword-fighting game I kept seeing in arcade cabinets at bars and venues around Seattle. It's a great game, but I always wished there was a bigger party version of it. That gap became the brief: take the core tension of Nidhogg and redesign it for a larger group.


Combat

The combat system is a three-way rock-paper-scissors: hold beats swing, dash beats hold, swing beats dash. Defeating the opposing team shifts possession and pushes your team toward your scoring end, like football. Levels are designed with more obstacles near either end of the arena, naturally pushing teams back toward center and keeping the match contested.


Hold
Blocks incoming swings. Punishes player who dash at them with a stun.

Dash
Quick attack that closes a big distance.

Swing
Builds up force, stunning players that block, however opens up opportunities to dash at them.

Power-ups

Teams scored upon choose from two random power-ups.


Scored on? Pick a power-up.
When a team concedes a point, they choose from two random power-ups — invincibility, a speed boost, extra lives, and more. Falling behind doesn't mean falling out. Power-ups keep both teams competitive and inject unpredictability into every comeback.

Readability

Two decisions shaped how readable the game felt under pressure.


Dark levels, bright characters
Levels were kept dark in value so player characters would contrast sharply against the environment and stay easy to track in chaotic four-player moments.

Dropped the player labels
Early versions showed name labels above each character. Testing showed the opposite of what I expected — labels added visual noise and made players harder to track, not easier. Removing them forced players to rely on character color and silhouette, which turned out to be more than enough.

Visual System

The visual system balances spectator clarity, character readability, and a reusable UI library.


Sports-inspired aesthetic
Bold type, high-contrast team colors, and clear iconography make the match state readable for both players and spectators.

Character design
3D characters modeled in Blender for legibility from a top-down perspective, with per-team color assignment built into the outline shader.

Component system
A consistent UI library covering buttons, panels, HUD elements, and feedback states, designed and implemented directly in Unity with no handoff gap between design intent and the shipped product.
Image 1
Image 2
Image 3
Image 4

Interface Design

I applied the same component rules across menus, character select, HUD, and feedback states.


Menu
Menu screens use a consistent layout structure built from reusable panels and button components.

Character select
Character select extends the same component system into a more dynamic, multiplayer context.

In-match UI
The in-match HUD adapts the system for moment-to-moment gameplay.

Feedback & States
Interactive and game-driven feedback like hover states, selections, alerts, and transitions all derive from the same component rules.

Playtesting & Showcase

Presenting and tabling at ECCC and SIX gave me the chance to observe players in person, talk with them directly, and gather the kind of qualitative feedback internal playtests rarely surface.


Offensive state needed to be unmistakable
At public events, players often did not know what to do after eliminating the other team. That led me to add larger offensive change banners and brief time pauses so players could understand what to do next.

Player tracking broke down in crowded menus
When several players were present in the same menu, people lost track of which marker was theirs. I fixed that by adding a pointer system in character select so each player could identify themselves more easily with freeform motion.

Readability improved by removing UI noise
Watching matches in person made it obvious that player labels were hurting clarity during combat. I removed them since color, silhouette, and proximity cues could carry the read more cleanly.

Ties needed a stronger payoff
Players were consistently dissatisfied when rounds ended in ties, so I designed a sudden-death tiebreaker arena to give tied matches a cleaner and more satisfying resolution.
Image 1
Image 2
Image 3
Image 4

Outcome

Blade Blitz launched on Steam on March 11, 2026 after two years of public iteration and event testing.


1,000+
Wishlists at launch
Blade Blitz launched on Steam on March 11, 2026, surpassing 1,000 wishlists at release, which is meaningful for a solo title without a publisher.

350+
Demo players
The standalone Steam demo reached over 350 players ahead of the full release.

3800+
Likes on Tiktok
A single Blade Blitz clip reached 3,800+ likes on TikTok, driving a meaningful spike in Steam wishlist traffic ahead of launch.

Reflection

The project clarified three product lessons I would carry into the next game.


Platform fit matters more than technical possibility
I built the game around local multiplayer, assuming Steam Remote Play would fill the gap. In practice, it didn't. Players still prefer native online experiences. If I were to do it again, I would design for online play from the start rather than relying on a workaround.

Novelty is expensive, especially twice
The game introduced both unfamiliar controls and unfamiliar rules. That combination made onboarding difficult and made it harder to communicate the concept quickly. I'd approach this differently by grounding one layer (controls or rules) in something familiar, so players have an anchor.

Perfection can become a trap
As development progressed, the bar kept rising. Instead of converging, the scope expanded toward perfect, which slowed decision making and shipping. In hindsight, I would define clearer constraints earlier and commit to them.
arrow_back Blade Blitz @ Hella Studios ios_share