MY ROLE
Product Design / Research
UX Strategy / Game Mode Strategy
Interaction Design
Team
Evan
/ Website Designer
Yemi
/ Product Lead
TIMELINE
2025
Designing Hyper’s first live arena
Hyper’s original battle mode was simple: enter a game, play a round, submit a score, and wait for the result. It worked for asynchronous 1v1 battles, but it did not create the feeling of competing live against other players.
Death Match changed that. It introduced a real-time arena where players join with limited lives, attack opponents, survive pressure, and earn based on how well they perform.
My role was to design the product logic behind that shift: how players enter, how lives work, how rankings are shown, how connection issues are handled, and how rewards feel fair after each session.
The design challenge
Death Match had to feel intense but not confusing, rewarding but not like a wallet transaction, competitive but not unfair — and it had to absorb the messy realities of live gameplay without feeling heavy.
It needed to help players confidently answer: What is Death Match? How many lives do I start with? What happens when I lose them all? Can I practise before spending HPR? Can I play privately with friends? What happens if my connection drops, or if I leave? How do I know how I performed?
The goal was to make a real-time multiplayer mode feel simple enough to enter, but strong enough to trust.
Entry point: making live play feel visible
For V1, Death Match was launching as a single live arena game, so the entry point had to be simple and prominent. Instead of hiding it inside the games list, I designed it as a featured card on the home screen with the key information players needed upfront: the live status, player activity, current pot, and a clear Play Now action.
Tapping the card opens a focused Death Match entry screen, where players can understand the mode, view the current pot, access room actions, try free mode, or enter the battle.
A dedicated home entry point made Death Match feel like a live event, not just another game in the list.
Designing the live arena hub
Since Death Match was launching as Hyper’s first live arena game, the entry screen needed to do more than start a match. It had to explain the mode, show live activity, surface the current reward pool, and give players clear paths to practise, join, invite friends, or create private rooms.
I designed this screen as a compact arena hub, where every action supports a different player intent while keeping the main goal clear: enter the live battle.
Annotated breakdown of the Death Match arena hub.
Teaching the rules at the right moment
Death Match introduced a new live arena format, so players needed to understand the rules before committing HPR.
When a user lands on the Death Match page, the rules modal appears after a short delay. This gives first-time players a quick explanation of how the mode works, how lives are used, what the entry fee means, and what happens if they forfeit.
Players can close the modal and continue, but the same information stays accessible through the help icon at the top right. This made the experience feel guided without blocking returning players from entering quickly.
Rules appear upfront, then stay available through the help icon.
Starting the live arena
Entering Death Match needed to feel fast, but still intentional. After tapping Enter Battle, the game loads and prepares the arena before the player joins.
Inside the arena, the session does not start immediately. The player first sees a Tap to play prompt, giving them a clear moment to get ready before their timer and lives become active. This prevents players from losing time while the game is still loading or before they are prepared to move.
Once they tap, the arena starts and the player enters the live match.
Enter Battle loads the arena, while Tap to play starts the player’s session.
Keeping the arena clear during play
The leaderboard is useful before the session starts because it helps players understand who they are competing against and where they stand.
But once the player taps Tap to play, the priority changes. They need a clear view of the arena, their lives, the timer, and nearby opponents. Keeping the full leaderboard open during active play would block the game space and create unnecessary distraction.
So the leaderboard hides automatically when gameplay starts. Players can still bring it back anytime with Show Leaderboard, but the default experience keeps the arena focused on play.
The leaderboard is visible before play, then hides to keep the arena clear.
Designing More Actions without stopping the game
During active play, players still need access to basic controls like sound, haptics, and forfeiting. The challenge was making those actions easy to reach without covering too much of the arena or interrupting the session.
I used the More Actions menu as a lightweight overlay. When opened, it temporarily hides the leaderboard so the controls have enough space and the screen does not feel crowded. The player can turn sound or haptics on and off, or choose to forfeit if they want to leave the session.
The timer keeps running while this menu is open. This was intentional because Death Match is a live arena, so opening settings should not pause the match or give players an advantage. If a player chooses to forfeit, we show a confirmation modal before ending the session, making the consequence clear before they leave.
The leaderboard is visible before play, then hides to keep the arena clear.
Designing for unstable connections
In a live arena, connection loss cannot feel like a crash. The player still needs to understand what is happening, what state they are in, and when the game becomes playable again.
I designed the connection flow to use clear status changes. When the player goes offline, the game view dims and a red connection state appears to show that play is temporarily interrupted. The match timer continues because the arena is still live.
Once the connection returns, the UI confirms recovery with a short green status message, then returns the player to the normal game view. This keeps the experience calm, clear, and honest without pulling the player out of the session too early.
A simple red-to-green system keeps players informed when connection drops and recovers.
Supporting landscape-first gameplay
Death Match plays best in landscape because the arena needs more room for movement, attacks, opponents, and live status updates.
To support this, I designed an orientation flow that starts from the portrait entry page, initializes the game, then guides the player to rotate their device before play begins. The player is not dropped straight into the match until the correct orientation is active.
Once the game opens in landscape, the session still waits for the player to tap to play. This keeps the start intentional, gives the player time to settle, and prevents the timer from starting before they are ready.
Players enter from portrait, rotate when needed, then start the live match in landscape.
Letting players create their own arena
For players who want a more controlled experience, I added a private room flow inside Death Match.
From the live arena page, players can create a room, set how long the session should last, choose an entry fee, and invite friends to join before the game starts. This keeps the main live arena open for quick play, while giving groups a way to set their own stakes and play together.
The host controls the setup, but the flow stays simple: choose duration, set entry fee, then create the room.
Private rooms let players set the duration and entry fee before inviting friends.
Designing the private room lobby
After creating a private room, the host lands in a waiting lobby where they can invite players, copy the room code, and start the game once at least one other player joins.
I designed the lobby to make the host’s job clear. Empty slots invite action, joined players are easy to scan, and the start button stays disabled until the room has enough players. This prevents the host from starting too early while still making it clear that all slots do not need to be filled before play can begin.
As more players join, the lobby updates in real time. The host can also remove players before the game starts, while the room code stays visible for quick sharing.
The host can invite players, copy the room code, and start once the minimum player count is met.
Giving hosts control without breaking the room
Private rooms needed two sensitive controls: removing a player and closing the lobby. Both actions affect other people, so I designed them with confirmation states instead of instant actions.
When the host removes a player, the modal explains exactly what will happen before the player is removed. If the host tries to leave or close the lobby, the flow makes the consequence clear: everyone is kicked out and entry fees are refunded.
This keeps the host in control, but protects players from accidental removals, lost rooms, or unclear outcomes.
Host can remove a player before the game starts, with a confirmation step to prevent mistakes.
If the host closes the lobby, everyone is removed and their entry fee is refunded.
Joining a private room
Private rooms gave players a way to bring their own group into Death Match instead of only joining the public arena. The flow needed to make the room feel easy to enter, while still confirming the entry fee before a player commits.
A player enters a room code, the system checks the code, then reveals the cost to join. Once they join, they wait in the lobby until the host starts the game. From there, they can invite more friends, copy the room code, or wait for the session to begin.
This kept private play lightweight, but still protected key moments like invalid codes, paid entry, waiting states, and host-controlled start.
Joining a room moves from code entry to lobby, then into gameplay once the host starts the match.
Closing the loop after gameplay
Once a player runs out of lives or the timer ends, the game exits them safely before showing the final result. This creates a clear handoff from live gameplay to the app, where the backend confirms the reward before anything is displayed.
The result page keeps the main reward prominent, while the player’s performance sits underneath as supporting context. For users who want more clarity, the reward breakdown is hidden behind an info action instead of crowding the page.
The game confirms the session, shows the final reward, and keeps the breakdown available without overwhelming the result screen.
THE FINAL SYSTEM
Death Match became Hyper’s first real live-arena experience.
The work was not just to add multiplayer. It was to design the full loop around live competition: how players enter, understand the rules, practise before paid play, join private rooms, recover from connection issues, return to pending sessions, manage forfeits, and see clear results after each session.
The main challenge was making a high-stakes mode feel easy to understand. Players needed to know what they were entering, what they could win, what could go wrong, and what would happen when the game ended.
So the system was designed around clarity, pressure, and trust. Clear entry details before play. Lightweight controls during play. Safe handling for edge cases. Transparent rewards after play.
WHAT IT UNLOCKED
Death Match pushed Hyper beyond its original score-based battle model.
Before, players competed by submitting scores and waiting for comparison. With Death Match, they could compete in real time, survive pressure, attack opponents, manage lives, and leave with a result based on how they performed inside the arena.
The gamification came from the structure itself. Lives created stakes. Practice reduced fear. Private rooms added social competition. Leaderboards created pressure. Results created reflection. Connection handling created trust.
More than a new mode, Death Match gave Hyper a scalable foundation for live multiplayer. It showed how the product could support richer competitive formats where players are not just chasing scores, but actively playing against other people in the same arena.
