MY ROLE
Website Design / Product Storytelling
Design Systems / Brand Expression
Team
Evan
/ Website Designer
Samuel
/ 3D & Motion Designer
with support from Product, Engineering, Marketing, Brand, and Legal.
TIMELINE
2026
Links
Free-for-All
Hyper’s battle experience was built on one promise — pick a game, enter a 1v1 battle, play your round, see who wins. Free-for-All extended that into a multiplayer format: enter a shared contest, play your best attempt, climb a leaderboard, and earn rewards based on where you place. But it was bigger than a new mode. It forced a rethink of Hyper’s entire battle system — how games are shown, how players choose a format, how currency works, how results are explained, and how the product recovers when something goes wrong.
When the old Battle system started to feel small
The original Battle flow had one mental model: one player versus one player. That kept the experience focused, but it made the system narrow — the Games tab could centre on the game, the result could stay binary, and the product rarely had to explain competing rules. Free-for-All changed that. Players began asking how many people they were up against, what entry cost, which currency to spend, how rewards were calculated, and what happened when something went wrong. The real challenge wasn’t bolting a new mode onto the old flow — it was redesigning the battle system so several competitive formats could live together clearly.
The original 1v1 battle entry — one game, one opponent, one action.
Multiplayer without weakening 1v1
Hyper wanted to give players more ways to compete and monetise their skill — but skill shows up in different formats. Some love direct 1v1 pressure; others prefer climbing a leaderboard, want more chances to improve, or feel safer entering with GEM before spending HPR. The core question: how do we introduce a multiplayer leaderboard mode into a product built around 1v1, without confusing players or weakening the Battle experience they already trust?
1v1 versus the new questions Free-for-All introduced.
Rebuilding the Games tab around modes
Before Free-for-All, a game card could focus on the game itself. Now the same game could carry 1v1, Free-for-All, a tutorial state, a currency state, a pending state, entry limits, and insufficient-balance states. The Games tab could no longer behave like a simple list — it had to show that each game supported different competitive experiences, with clearer entry paths and mode visibility, while still feeling light.
Games tab evolution — the old battle entry beside the new card with Free-for-All and tutorial states.
Separating two mental models
1v1 is personal; Free-for-All is communal. 1v1 asks ‘Can you beat this opponent?’ Free-for-All asks ‘How high can you place against everyone?’ If both modes looked the same, players would misread what they were entering — and the reward logic, stakes, and results differ. The game details page became the place to clarify the mode: 1v1 stayed a focused challenge, while Free-for-All introduced leaderboard competition, entry cost, currency choice, and reward potential.
1v1 game details beside the Free-for-All game details.
Designing around leaderboard tension
The hook of Free-for-All isn’t just ‘play a game’ — it’s enter the field, climb the table, place higher. In 1v1 the result is binary; in Free-for-All it’s positional. The final result screen had to show where you placed, who ranked around you, what you earned, how it was calculated, and what to do next — and feel rewarding even when you didn’t come first, because multiplayer is about proximity, improvement, and the pull to replay.
Final result screen — placement, leaderboard position, reward, and next action.
Transparent rewards, not a receipt
Free-for-All introduced richer reward logic — entry fee, winnings, commission, total reward. Showing every number on the result screen made it feel transactional, yet the system still had to feel fair. The fix: make the total reward prominent and move the breakdown into a secondary layer. The result celebrates the outcome first; anyone who wants the maths can open the reward breakdown to see exactly how the total was reached.
The result screen, then the reward-breakdown modal.
Introducing HPR and GEM entry
Free-for-All supported both HPR and GEM, creating a decision before play. The two don’t mean the same thing — HPR is closer to real reward value, GEM is more limited and utility-based. This led to the Switch Currency flow: players could move between HPR and GEM without feeling like they’d left the game, because currency confusion quickly becomes trust confusion. Choosing currency had to feel like part of entering a competition, not a separate wallet task.
Switch Currency, GEM entry details, and the insufficient HPR / GEM states.
GEM limits as rules, not errors
GEM entry introduced a tricky state: a player could hold GEM yet still be unable to enter a specific game with it, due to usage limits or eligibility. Left unexplained, that feels broken. The system had to distinguish ‘not enough GEM’ from ‘GEM limit reached’ from ‘HPR still available’ from ‘not available in this currency’ — treating each as an understandable game rule, not a generic blocker, so the restriction felt intentional.
GEM limit variants as a labelled component system.
Teaching each mode at entry
Free-for-All teaches a different kind of competition, so it needed its own tutorial. 1v1 teaches a direct battle; Free-for-All teaches shared ranking. I designed separate first-time flows for each, kept contextual — shown at the moment they help a decision, not as generic onboarding far from play. New players understood the mode before spending currency; experienced players could move fast.
First-time tutorial for 1v1 beside the Free-for-All tutorial.
Never lose an active entry
Free-for-All made unfinished games consequential — a player could enter, leave, and still hold a pending competition with currency and reward potential attached. The principle was simple: a player should never accidentally lose an active entry. Pending games surfaced on the dashboard and game details, and starting a new game warned about the active one before continuing, with a clear forfeit confirmation — making the system feel fair and recoverable.
Pending games on dashboard and details, the new-game warning, and forfeit confirmation.
Designing for failure: invites, network, stats
Multiplayer is where rewards-based products lose trust, so the edge cases got real attention. Expired invite links explained themselves and offered a path back into play. A network-issue flow covered connection loss, reconnection, and a clear ‘couldn’t record gameplay’ state — saying what happened, what was saved, and what’s next. And game stats added a credibility layer beyond the final rank, with an honest fallback when gameplay couldn’t be recorded.
Expired invite, network recovery, and game stats with a fallback state.
Multiple entries and traceable rewards
Free-for-All introduced multiple entries — a player could enter more than once for more chances to climb, turning a single match into a tournament-like loop: try again and climb. The ‘6 entries’ state communicated how many entries remained and how results were ranked. A Rewards & Activity page made the economy traceable — entries, winnings, forfeits, and GEM usage — so players could always see where their currency went.
The 6-entries tracker and the Rewards & Activity page.
Making the old 1v1 flow stronger
The most important constraint was not weakening 1v1. The redesign treated 1v1 and Free-for-All as siblings, not replacements: 1v1 stayed fast and direct, Free-for-All added shared leaderboard competition, and both shared the same foundation where it made sense — game details, tutorials, pending states, currency checks, results, and recovery. The old flow didn’t disappear; it became one mode inside a broader, more scalable competitive system.
1v1 → Challenge → Play → Result versus Free-for-All → Enter → Compete → Leaderboard → Reward.
Outcome
Free-for-All expanded Hyper’s Battle experience from a direct 1v1 product into a flexible multiplayer competition system — and forced the old system to mature. The Games tab, game details, result screens, currency flows, and activity history all became more scalable because they now had to support more than one way to compete. The feature introduced leaderboard-based play, currency choice, multiple entries, mode-specific tutorials, pending-game recovery, reward transparency, and stronger failure handling — turning Hyper’s single competitive format into a multiplayer foundation.
A system map connecting Games tab, details, modes, currency, results, activity, and edge cases.
Case study in progress
This case study is still being refined. Reach out if you’d like a walkthrough before it goes live.
✕
