SlashBack

The pitch

“Step into the chaotic world of SlashBack as N8, a silent enforcer trained to kill without question. In this arcade-style top-down endless slasher, your goal is simple: survive, kill, and get the highest score. Fight through waves of madness in a world overrun by the Umbra virus, where order has collapsed and only the ruthless remain.”

My role

SlashBack was my first project as a UI designer, in a team of 12: four designers, four programmers and four visual artists. I designed the layout of every screen and implemented all of the UI in Unreal Engine 5. Our UI artist then created the final art, and once it was in place, I added the animations.

I also took on the role of tech designer. That meant writing feature specs for gameplay systems, researching how other games solve similar problems, and acting as the bridge between the designers and the programmers.

HUD and game feel

In an arcade game, the score is the reason to keep playing, so the HUD had to make every kill feel rewarding. It shows the score, the combo multiplier, the special skill bar and the time rewind icons.

Every kill gives 100 points, multiplied by the current combo. The combo has a timer: if the player doesn’t kill an enemy in time, it resets, and the combo display disappears until the next kill.

After the first version, the designers on the team said it would be great if the score and combo reacted visually. So, I made my first ever UI animations. The combo number now pops in size whenever it increases, and the score plays an animation when it passes certain thresholds. The team’s reaction to the score animation gave me the confidence to keep experimenting with UI motion.

Menus

I designed and built the start screen and the death screen. The death screen sums up each run with the total kills, the final score and the best combo, so players have a reason to try again, along with restart and quit buttons. After the first version, teammates pointed out that the colours needed work and that the best combo wasn’t being tracked correctly, so I fixed both.

Tech design: feature specs and guiding programmers

Before a feature was built, I wrote a feature spec for it, covering the design intent, how it works, the feedback the player gets, and a flowchart of the logic. I wrote specs for seven systems: the dash, the melee and ranged enemies, the area-of-effect attack, the scoring system, the difficulty increase and the explosive enemy.

Working with the team

At the start, I found it hard to talk about Unreal Engine with the team, because I didn’t know how much blueprint experience everyone had. After talking it through with the programmers, I found my place as the bridge between design and code, and communication became one of my strengths. Teammates told me they found it easy to come to me.

I also helped wherever I could: answering Unreal Engine questions, fixing bugs, and taking over tasks when someone couldn’t finish them in time. That’s how the UI implementation became mine. Our UI artist let us know she was running behind, so I took over the layout and functionality, which turned out to be my first real step into UI.

What I learned

• Write the spec before building. Having a clear plan to follow, and asking for feedback once the first version runs in-game, saved us from many misunderstandings.

• Explain, don’t just fix. When the programmers needed help with the enemy animations, I explained how the animation blueprints worked instead of building everything myself. They could then add the rest on their own, which saved more time than if I had done it all.

• Take risks. I was nervous about making my first animation. It became one of the parts of the game the team liked most, so I keep stepping out of my comfort zone.

What I’d do differently

• Clarify my role and the team’s skills from day one. In the first sprint, I didn’t know how much blueprint experience the team had, so I ended up writing specs and building features myself instead of guiding others. Next time I’d ask about everyone’s experience at the start, so I can be the bridge between design and code from the beginning.

• Plan UI feedback from the start. The score and combo animations were added only after teammates asked for them. Now I plan visual feedback as part of the first UI design, because in an arcade game, it’s a core part of how the game feels.

• Agree on UI asset deadlines early. Our UI artist fell behind partly because nobody had planned when each asset was needed. In my next project, INYIU, I made a priority list of the UI assets I needed and by when, which the artists said really helped their planning.