About Me
Betterlore: CoinPusher
Designing a scalable reward system without compromising performance
A physical arcade game, played online
Coin Pusher is a game where players drop coins or chips onto a moving platform, hoping to push other pieces over the edge and win their value.
Our version brought this experience online. Players controlled a real physical machine through a digital interface while watching the action through a live video stream.
This meant the interface had to respond to events happening on the physical machine in real time — from placing bets and dropping pieces to communicating wins and updating the player's balance.
Earlier public version of the Coin Pusher interface, shown to illustrate how players remotely interacted with the physical machine. By the time I worked on the reward system, the interface had evolved, but the core interaction remained the same.
Role:
Sole UI/UX Designer
Timeline:
2025 (around 4 months along other projects)
Team:
UI/UX Designer (me) • Product Owner • Head of Development • Frontend Developers • QA Engineer
Tools:
Figma • Rive • Adobe Illustrator
Outcome:
Shipped to production
Extended to portrait mode
Some visuals and animations have been recreated or adapted to respect confidentiality. The design decisions, process, and outcomes reflect the original project.
THE CONSTRAINT
A new game mode made rewards more meaningful
For a new game mode, we introduced progressive bars for coins and chips. Instead of receiving a reward after every drop, the value accumulated until the corresponding bar was filled.
When a bar was completed, the final accumulated value determined the reward tier, from XS to XL. This made reward moments less frequent and more meaningful. But the existing feedback wasn't designed for that.
Every win looked and felt the same
The existing system used the same jumping coin or chip animation for every reward, regardless of its value.
It clearly communicated that something had been won, but there was no difference between a small reward and a significant one We needed a system that could make smaller wins feel quick and lightweight, while giving larger wins more space, energy, and impact.
Bigger animations came with a performance cost
The platform relied heavily on sprite sheets for motion, from microinteractions to larger animations.
This worked for simple effects, but more expressive animations required more frames and heavier assets. From previous features, we had already seen how this could lead to slower loading, lag during playback, and reduced responsiveness.
The challenge was clear:
How could we create richer, more emotional reward moments without making the platform heavier?
THE APPROACH
Building on a Lighter Motion Workflow
Moving beyond sprite sheets
Before this project, I had researched and tested different motion workflows to address the platform's performance limitations.
Coin flipping sprite sheet sample
After Effects, Lottie, Rive
I explored After Effects and Lottie, but found them better suited to linear animations. Rive gave us something closer to what the platform needed: lightweight vector-based animations, interactive state machines, and runtime control.
After successfully testing Rive in an earlier feature, we used it as the foundation for the new reward system.
Designing one system for every reward
Instead of exporting separate animation sequences, I built the entire reward system in one Rive file.
The file contained all five reward tiers, from XS to XL, with number inputs and conditions that determined which animation should play for a given reward value.
I could test the system directly in Rive by changing the reward value and triggering the state machine, allowing me to validate how the animations responded before implementation.
Coins and chips shared the same reward system and visual treatment. The platform communicated the reward result to the Rive file, which then displayed the corresponding tier animation.
For this case study, I recreated the original prize ranges to demonstrate how the system worked without exposing production values.
Designing with implementation in mind
Building the animations was only part of the work. The Rive file also needed to communicate clearly with the platform.
I worked closely with frontend developers to define the inputs, conditions, and naming conventions they would reference in code.
We tested the state machine together and resolved cases where the expected animation wasn't triggered correctly. This collaboration helped make sure the logic I created in Rive worked reliably once connected to the platform.
State machine conditions controlling which reward animation is triggered based on the configured value range, trigger, and sound settings.
Keeping dynamic values inside the animation
One implementation challenge was displaying the player's actual prize amount.
The reward titles, such as Good! and Epic!, were embedded in the animations. But the prize value needed to change dynamically for every win.
Our initial approach was to render the amount separately through frontend code. However, reproducing the intended typography and keeping the value visually integrated with the animated composition proved difficult.
After researching alternatives, I found that Rive's Text Runs could keep the prize amount inside the animation while allowing frontend developers to update it at runtime.
I converted the prize values into Text Runs, giving developers control over the displayed amount without losing the typography and visual treatment of the animation.
Making iteration easier after implementation
The team wanted to move the reward system into production quickly, while the animations still needed testing and refinement.
Developers connected the Rive files to Firebase, where we maintained separate files for each environment.
I could upload updates to the appropriate environment and test them directly in the platform, reducing repeated developer handoffs and allowing design and development to progress in parallel.
THE DESIGN PROCESS
From nine planets to five reward tiers
Starting with an ambitious visual direction
While the technical workflow made richer animations possible, I still needed to define what the reward system should look and feel like.
The original brief was ambitious: nine reward tiers, each represented by a different planet. Smaller rewards would start with smaller planets and build toward the Sun as the biggest celebration.
I researched reward experiences in other games, collected references, and explored how illustration, motion, and sound could make each reward feel progressively more exciting.
After storyboarding the animations, I designed the first three concepts around Earth, Neptune, and Saturn.
Reducing the scope without losing the idea
The visual direction was approved, but creating nine bespoke animated rewards would take too long for one designer working across multiple projects.
To move into development sooner, the team reduced the system from nine planets to five tiers: XS, S, M, L, and XL.
Instead of starting over, I adapted the illustrations and motion direction I had already created into one visual system.
Slide left and right to compare before and after.
Creating hierarchy through motion
My first concepts treated every reward as a large, full-screen celebration. But the system needed clearer hierarchy—a small reward shouldn't interrupt gameplay in the same way as a significant one.
I differentiated each tier through illustration complexity, number of elements, scale, screen coverage, movement, color, animation duration, and sound.
Smaller rewards stayed quick and lightweight, while larger rewards became progressively more expressive. XL was the only full-screen experience, playing for six seconds before looping until the player closed it.
Each tier also had its own sound design, adding another layer of intensity as the reward value increased.
Visual
Tier
Duration
Extra Small
(XS)
Small
(S)
Medium
(M)
Large
(L)
Extra Large
(XL)
(Jackpot)
2 seconds
2 seconds
3 seconds
5 seconds
6 seconds
Using sound to reinforce the hierarchy
Each tier had its own sound treatment, increasing in intensity alongside the animations.
I sourced and edited the audio to match the pacing and emotional tone of each reward, making larger wins feel progressively more celebratory.
XS wins have short, punchy sound effects that are powerful but subtle enough not to interrupt gameplay
S wins are slightly longer and brighter effects that break the rhythm and signal a noticeable reward.
M wins included a subtle hovering spaceship sound to complement the spaceship illustration in the animation.
L wins have layered laser effects to match the spaceship firing animation, adding intensity.
and lastly, for XL wins/Jackpots I introduced looping, celebratory background music with layered sound effects for maximum impact.
