Canyon Racer

THE PROJECT

Canyon Racer is a mobile plane racing game where the player picks an aircraft, each with its own skill set and stats, and races against AI opponents through a desert canyon. The goal is simple: cross the finish line first after two laps of the map. The twist is that the track is alive. You can shoot the canyon's obstacles to open up shortcuts, grab power-ups by flying through boost rings, and use your plane's special ability to sabotage the planes around you.

It was a six-week build by a team of seven, made in Unity. I came onto the project in three roles at once: I designed and implemented the sound, designed and tested gameplay mechanics, and owned the team documentation that kept everyone pointed in the same direction.

Gameplay: two laps through the canyon, with power-up rings, obstacles, and plane abilities in play.

GAMEPLAY

Players choose from three aircraft, and the choice matters. Each plane trades off damage, shooting cooldown, top speed, and acceleration, and each carries a unique Attack Boost ability on its own duration and cooldown. The Medium Plane, for example, leans on a balanced stat line and an Attack Boost that raises the damage it deals to other planes for a short window, a deliberate, aggressive pick rather than a pure speed build.

Racing is two laps around the canyon, but pure throttle won't win it. The map is full of obstacles you can shoot to carve out shortcuts, boost rings that hand you a power-up as you pass through, and openings to sabotage rivals. The result is a racer where positioning, timing, and aim matter as much as speed.

The light, fast Canyon Racer aircraft, a sleek white and green plane. — The three selectable aircraft (light, medium, and heavy), each with its own stats and a unique Attack Boost.

The medium Canyon Racer aircraft, a yellow plane with its robot pilot. — The three selectable aircraft (light, medium, and heavy), each with its own stats and a unique Attack Boost.

MY ROLE

Our team, Ctrl Alt Delete, was seven people: two designers (myself and Alexander), two engineers (Antonio and Nikola), and three artists (Daphne, Memsi, and Hendrik). As one of the designers I owned the audio end-to-end (sound design and implementation) and also drove the documentation and the playtesting that kept the design honest, while contributing to mechanic design along the way. Wearing several hats on a short timeline meant the roles fed each other constantly: what I learned in a playtest went straight into the docs and the next audio pass.

SOUND DESIGN

On the audio side I handled the whole pipeline: collecting and recording source material, building original sound effects in Ableton Live, editing and shaping them, and scripting them into the game. The brief I set for myself was simple: every plane should feel different, every shot should feel impactful, and the whole mix needs to survive on mobile speakers.

The sounds were authored in Ableton, then implemented through FMOD's Unity integration so I could keep iterating on the audio without round-tripping through an engineer. Engine tones, weapon fire, explosions, power-up pickups, and the UI all run as FMOD events, with pitch and timbre randomisation on the repeated sounds so consecutive shots never feel mechanical. Small variations make a small library feel much bigger.

Because this is a mobile game, build size and memory matter, so part of the audio job was format optimisation, weighing OGG vs MP3 per sound to keep the package light without giving up quality on phone speakers.

An Ableton Live session for Canyon Racer, showing layered MIDI and audio tracks used to build the game's sound effects and music. — Building the SFX and music in Ableton Live.

An FMOD Studio event from Canyon Racer, showing the event editor and master track routing used to implement the audio in Unity. — Implementing the events in FMOD for the Unity build.

MECHANIC DESIGN

As a mechanic designer I helped shape how the race actually plays. Several games steered our direction. The power-up loop borrows from Mario Kart: each aircraft has a unique ability, and flying through rings grants a boost, which turns the track into something you read and exploit rather than just drive around. We pulled camera ideas from a handful of flight games so the player genuinely feels like they're piloting an aircraft through the canyon, and we built a UI tuned for playing on mobile.

My job was as much pressure-testing as inventing: prototyping ability ideas, tuning the stat trade-offs between planes, and playtesting to find where the obstacle-shortcut and sabotage systems felt fair versus frustrating.

A greybox prototype of Canyon Racer running in Unity: a plane flying through a canyon toward a rock arch, with on-screen Skill and Shoot buttons, a race position, and a countdown. — A greybox prototype mid-race, with the mobile Skill / Shoot controls, race position, and shootable obstacles in place (FMOD running in-engine, top-left).

DOCUMENTATION & TESTING

With seven people moving fast for six weeks, documentation was the glue. I owned the design docs, capturing mechanics, stats, and decisions so artists and engineers were building against the same source of truth, and kept them current as the design changed.

I also ran the playtesting across three iterations, gathering structured feedback after each build. Early rounds told us the core loop was fun but hard to control and a little thin ("fun trying to fly the plane", "driving through things is really hard"). By the later rounds players were calling out the art style, the motion blur sense of speed, and the per-character special attacks as highlights, while flagging real balance issues like shooting being too strong and the shield ability being too short. That feedback fed straight back into the docs and the next pass, which is where the sound, testing, and documentation roles came together: spot a problem in playtest, reason about the fix, write it down clearly enough for the team to act on.

Playtest feedback responses asking whether the game was fun and easy to understand. — Round one: is it fun, is it readable?

Playtest feedback responses about what interested players most and what they would change. — What players liked, and what they'd change.

Later playtest feedback praising the art style and mechanics while flagging balance issues. — Later round: art style and abilities land; balance needs work.

HOW I MADE IT

The audio and my design work came together over the six-week build like this:

Set the audio brief for myself: every plane should feel different, every shot should feel impactful, and the mix has to survive on mobile speakers.
Collected and recorded source material, then built the original sound effects and music in Ableton Live.
Implemented everything as events in FMOD, wired into Unity, with pitch and timbre randomisation on the repeated sounds so they never feel mechanical.
Optimised formats per sound, weighing OGG against MP3, to keep the mobile build light without losing quality.
Ran three rounds of playtesting, gathering structured feedback after each build.
Fed that feedback back into the design docs and the next pass, tuning stats, controls, and balance.