BeatSpace Checker

Click here to visit Itch.io and download!

Motivation

BeatSpace Checker is the result of a 3-month production for the "Develop at Ubisoft 2023" program. The prompt for this challenge was to create a 1-button game with the theme of "crowded spaces".

Drawing inspiration from combos in fighting games, BeatSpace Checker requires players to master precise timing needed to chain these moves seamlessly. By incorporating rhythm, the game introduces a natural awareness of timing that allows players to unlock a multitude of actions using a single button, adding a layer of depth and strategy to the gameplay.

Node Class Architecture

I immediately drew inspiration from Godot's Node structure, which I find intuitive for controlling the information of linked objects. In BeatSpace Checker, I implemented nodes to manage shared spatial information like position and scale, similar to the structure seen in Fig.1.

    Nodes:
  • Will always have a transform component.
  • Will always be renderable.
  • Will always transfer its transform component to its children.
  • Will always transfer its update calls.
  • Will always transfer its render calls.
  • Will always do memory management of their children upon destruction.
    • Limitations:
  • Only one child per type is allowed.
  • Systems processing can't transfer beyond the most immediate generation of children. (As seen in Fig.2)
Fig.2 - Function propagation.

Song Node class

To address a timer coherence problem, we analyzed the drift between a computer's timer and a human tracking the song's timer (pressing to the apparent beat of the song), as depicted in Fig.4.

Fig.4 - Drift between computer's beat count and the song's beat count.

As we calculated the time drift as (Song's count - Computer's count), and the difference is dominantly positive, we can conclude the song's count is delaying in comparaison to the computer's count.

But hope is not lost! We can also identify, at the beggining of the song the drift is almost negligable within the range of 0 s and 40 s! If we simulate a loop within this range (0 s to 16s), we find the results from Fig.5.

Fig.5 - Corrected Drift.

Based on this information, we made the following design decision: we will keep the song tracks within a range of 0 s to 16 s and loop over them. This approach allows us to reinitialize counters and take advantage of the fact that at the beginning, the drift is very small. This means that each sound source will need its own counter so we can maximize coherence between them.

The Song Node is not an Entity Node, because it behaves differently. They can't be processed with the same systems, althought they share some behaviors given their Node nature.