Go to the

Official Game Page

and play for free!


Or get it on mobile:

Google Play

.

.

.

.

.

.

.

Making Orbit Crusher

Custom rhythm engine

Rhythmic Movement Physics

The "Look ahead" Problem of Audio Latency

Scheduling and Fading

Here you can read about how the rhythm engine of Orbit Crusher was made. 


.

.

.

.

.

.

.

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.

.

.

.

.

.

.

.