.
.
.
.
.
.
.
Making Orbit Crusher
Here you can read about how the rhythm engine of Orbit Crusher was made.
These are just a few aspects of the process, I found especially interesting.
More in-depth explanations of the systems might be added in the future.
.
.
.
.
.
.
.
Poly-rhythmic level design
Each level runs in one of three time signatures:
5⁄8 = 5 beats = a puzzle cycle length of 2.5 seconds
7⁄8 = 7 beats = a puzzle cycle length of 3.5 seconds
8⁄8 = 8 beats = a puzzle cycle length of 4.0 seconds
Each one of the videos below shows one of the three level types, where you can hear how the rhythms differ and see how that affects the gameplay.
In each video I synced up four gameplay captures, so the levels play out simultaneously. No sounds were added to the videos. It’s simply the gameplay audio being faded in and out when changing focus between the levels:
As you can see (and hear) in the video below, levels in 7⁄8 have a slightly longer cycle, giving the player more time to solve each puzzle:
whereas 5⁄8-levels are only 2.5 seconds.
Levels in 8⁄8 have the longest cycle (4 seconds):
.
.
.
.
Custom Rhythm Engine
The fundamental rhythm engine consists of three parts: Repeater, Conductor and Event Handler.
- The Repeater manages coroutines responsible for the timing of the next beat.
- The Conductor manages the counting of beats.
- The Event Handler manages all the methods subscribed to the rhythm engine.
When a method is subscribed to the rhythm engine, it runs on every beat, checking if a certain beat condition is met by comparing it with the conductor status.
This is used for all the music and some visual effects.
.
.
.
.
Rhythmic Movement Physics
Outside of levels the comet moves around free of rhythm and at a constant speed. When entering a level the comet changes its state by subscribing to the rhythm engine. This makes it move in sync the music:
Each frame the comet checks how long it will take to reach the next planet in its path, and this data is converted into a trajectory.
.
.
.
.
The "Look ahead" problem of audio latency
Running the game on platforms with high audio-latency requires the music to be triggered around 0.3s in advance. But since the state of the rhythm engine can change at a frame’s notice, there emerges interesting problems. An example:
When the player has 2hp and the comet is 0.1s from reaching the last planet in the last stage of level, one of three things can happen with the game state:
- The player completes the level: Fade to victory-music
- The player dies: Fade to defeat-music
- The player manages to stay alive without completing the level: No fades
So how can we make the music responsive, when a sound has to be triggered 0.3s before we even know if it should play?
.
.
.
.
Scheduling and Fading
The solution to the “look ahead” problem of making interactive music with high latency was to create a “Schrödinger’s cat”-like situation, where all potential audio files get scheduled 0.3s ahead of a comet-planet-collision, and then in the last split-second the incorrect audio files are terminated. This involved two key challenges:
- Choosing potential audio files by anticipating the possible state-changes, before they happen
- Activating the correct sounds and deactivating the incorrect ones, when the game state changes
This system made the soundtrack able to transition between parts seamlessly – even with audio latencies of up to 0.3 seconds.
.
.
.
.
.
.
.