Go to the

Official Game Page

and play for free!


Or get it on mobile:

Google Play

.

.

.

.

.

.

.

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:

58 = 5 beats = a puzzle cycle length of 2.5 seconds
78 = 7 beats = a puzzle cycle length of 3.5 seconds
88 = 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:

Play Video
Levels in 58 have the shortest cycle, compared to other level types (78 and 88).

As you can see (and hear) in the video below, levels in 78 have a slightly longer cycle, giving the player more time to solve each puzzle:

Play Video
Levels in 78 give the player 3.5 seconds to solve a puzzle,
whereas 58-levels are only 2.5 seconds.
Levels in 88 have the longest cycle (4 seconds):
Play Video
Besides giving a different rhythmic feel to the music, having different time signatures also affects the gameplay: The short cycle of 58-levels result in a faster game flow, compared to the 78-levels and 88-levels, where the puzzle cycles are longer.

.

.

.

.

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.

.

.

.

.

.

.

.