Role: Director / Designer / Programmer / Writer

Tools: Unity, C#

Follow us on Social Media: Instagram

A Music Game About Making Time Behave Like a Record

Wax Out is a music-driven time-manipulation game where the player moves through a world controlled by two turntable decks. Instead of treating rewind as a magic button, I wanted time to feel physical: something the player could scratch, loop, crossfade, clog, clean up, and finally mix.

The player explores the world, collects records, places them into matching zones, and uses DJ-inspired controls to manipulate recent history. Forward movement builds earwax, rewind consumes it, and pushing the system too far causes a Needle Skip state where the record gets stuck in a bounded loop.

My work on this project covered the full loop from idea to playable prototype: directing the concept, designing the systems, programming the core mechanics, writing tutorial text, and tuning the player experience until the weird idea could actually be learned.

Highlight

• Designed a dual-deck time system where two overlapping timelines can be controlled, blended, rewound, and looped.
• Programmed the main gameplay runtime in Unity/C#, including deck state, rewind traces, crossfader logic, scratch rules, earwax resources, HUD feedback, and tutorial support.
• Built the record collection and placement loop so the audio concept had clear puzzle goals.
• Designed controller and keyboard inputs for crossfading, scratching, looping, speed tiers, commit/cancel, and equipment selection.
• Wrote the in-game tutorial and design documentation to make an unusual mechanic understandable for first-time players.

The Core Design Problem

The hard part was not inventing a cool metaphor. It was making the metaphor playable.

I knew I wanted the game to feel like DJing through space, but the player still needed to understand basic questions every second:

• Which version of the world am I controlling?
• What am I hearing and seeing?
• How far can I rewind?
• What happens if I commit this scratch?
• Why did the record start skipping?
• What is the objective right now?

So the design became a balance between expressive controls and readable rules. The player should feel like they are performing with the system, but the game state still has to be predictable enough for puzzles and onboarding.

Core Loop

1. Move through the active deck.
2. Build earwax as time passes.
3. Crossfade to change the visual/audio blend.
4. Scratch backward through recent history.
5. Commit the new timing or cancel back to the scratch entry.
6. Collect records and place them in matching zones.
7. Use loop and speed controls when the timing problem becomes more demanding.

Dual-Deck World Model

The prototype runs on two independent deck timelines: left and right. Only one deck owns the player body and physics at a time, but the crossfader can blend what the player sees and hears between both decks.

I separated two ideas that could easily become confusing:

• Engagement: which deck the player is controlling.
• Blend: which deck the player is seeing and hearing.

That separation made the mechanic deeper. The player can listen across the mix without losing control authority, and switching decks becomes a deliberate action instead of a hidden side effect of the camera or audio blend.

Earwax as Rewind Budget

Earwax is the resource that makes time manipulation risky.

Forward movement builds wax. Rewind consumes wax. If the player lets either deck or the shared total reach the cap, the system enters Needle Skip: the current moment becomes a short repeating loop, like a record skipping on the needle.

That failure state was important because I did not want the game to say “resource full” and stop. I wanted the audio metaphor to become the consequence.

• Rewind is powerful, but it has a cost.
• Moving forward creates both progress and pressure.
• Failure is playable, visual, and musical.

Scratch, Commit, and Cancel

Scratch is the main timing decision. The player starts by rewinding into recent history, then chooses whether to keep that timing or return to where the scratch began.

The rule I landed on was:

Scratch starts with rewind. Forward only works after a valid scratch range exists.

This made the controls stricter, but much easier to reason about. The player first pulls time backward, then decides whether to commit, cancel, loop, or scrub forward inside the existing range.

Records as Readable Puzzle Goals

The record system turns abstract audio layers into concrete objects. Players collect records, select them from the equipment deck, and place them into the correct zones.

This gave the time system a clear reason to exist. The player is not rewinding just because the mechanic is available. They are using time control to navigate the space, recover musical pieces, and install them in the right place.

Scaling the Space

Once the player understands the basic controls, later areas can ask for more deliberate deck switching, record selection, and timing decisions. I designed the mechanic so it could scale from “learn the buttons” to “manage a layered world under pressure.”

The goal was not to add more systems for the sake of complexity. The goal was to let the same systems create more interesting situations as the level space becomes denser.

Rewind Readability

Rewind uses a strong visual state so the player can tell when they are manipulating history instead of moving normally. The HUD shows speed and deck information only when it matters, then clears it when the player returns to normal play.

For a mechanic this unusual, feedback had to do more than look cool. It had to answer player questions quickly:

• Am I in normal movement, scratch, or loop mode?
• Which deck am I affecting?
• Is the system moving forward or backward?
• Am I about to run out of usable rewind?

What I Designed

Gameplay Systems

• Dual-deck timeline model.
• Crossfader blend and deck engagement rules.
• Earwax rewind budget and Needle Skip failure state.
• Scratch, commit, cancel, loop, and speed tier behavior.
• Record collection, equipment slot selection, and placement objectives.
• Perfect Mix rules for synchronized deck behavior.

Controls and Feel

• Controller mappings for crossfader, deck switching, scratch, loop, commit/cancel, and speed control.
• Keyboard fallback controls that preserve the same logic as the controller version.
• Input rules that reduce ambiguous state changes, especially around scratch entry and forward scrubbing.
• HUD timing feedback for speed, loop direction, deck state, and resource pressure.

Programming

• Unity/C# runtime for deck state, rewind traces, scratch ranges, loop wrapping, crossfader state, resource accounting, and player feedback.
• Gameplay/audio synchronization hooks so transport behavior and player state stay aligned.
• Tutorial, menu, prompt, HUD, and equipment-slot support systems.

Writing and Documentation

• In-game tutorial flow for first-time players.
• Voice-over-ready instruction text.
• Player prompts for collection, placement, scratch, loop, and control reminders.
• Design documentation and devlogs for tracking rules, edge cases, and iteration history.

Design Decisions I Care About

1. Separate Deck Engagement from Crossfader Blend

If seeing, hearing, and controlling all changed at once, the player lost the thread. Separating those layers let the system stay expressive without becoming random.

2. Make Rewind the Door Into Scratch

Letting forward input start scratch created too many edge cases. Starting with rewind gave the player a clean rule and gave the code a more stable state model.

3. Make Failure Part of the Fantasy

Needle Skip turns resource failure into a musical event. The game does not just block the player; it performs the problem back to them.

4. Teach Complexity in Layers

The tutorial starts with movement and crossfading, then adds scratch, then commit/cancel, then loop, then speed tiers. I wanted players to build confidence before asking them to combine the full system.

What I Learned

This project pushed me to think like both a designer and an implementer. Every cool rule created downstream questions: input ambiguity, history trimming, HUD readability, audio sync, tutorial order, and whether a first-time player could form the right mental model quickly enough.

The biggest lesson was that strange mechanics need very grounded rules. The more unusual the fantasy is, the more carefully the game has to explain cause and effect. My favorite kind of design work lives in that space: playful idea first, then serious craft to make it real.

Takeaway

Wax Out is the kind of project I like making most: a weird, personal design idea that still has to survive real player inputs, real feedback needs, and real implementation constraints. It let me combine system design, gameplay programming, music thinking, writing, and player advocacy into one playable prototype.