Movements
Movements is a music-driven desktop game built in one 10-week term at Dartmouth with 2 others. My primary role was a developer and composer. As such, I developed the majority of the systems for the game, wrote and implemented music and SFX, and collaborated on game design.
Connecting the Player to Music
In creating Movements, our main goal was to make music mechanically important in a way more distinct from traditional music-based games.
We connected music as much as possible to the player's direct actions, objects the player interacted with, and passive elements in the environment.
The player uses musical tools they find to navigate through a world where everything is on beat.
Check out the videos to the side to see the world moving with the music -
The player uses two instruments in the game: a drum and a horn.
Each instrument helps them surpass obstacles in the environment, but they must use them on the beat of the music for them to be successful.
One of our main goals was making this mechanic as intuitive as possible through lots of different iterations and playtesting - the most difficult part was making people aware of music's importance.
The Underlying Systems
To line up lots of the functionality on the beat, a series of timers control reactions to the player's inputs and cue world changes. Below is a function that was called on a looping timer synced to the bpm of the music. It cycles through an array of function names that it calls with a timer corresponding to a quarter note. With this, we can have different function calls for each beat of a 2-bar loop, and each function can house their respective functionality as needed.
For using instruments, the Player class would have a reference to a general Instrument class. If this reference was not a null pointer, then the Player would be holding an instrument, and could call an overridable method on that instrument to use it. This way, different instruments could be added easily, as long as they each contained their own UseInstrument() function, like the one for the drum below:
Other Functionality
In the first area, there are rocks that fall and move to the beat that the player can destroy. Upon the player getting hit, we need a way to determine which rocks to respawn, depending on what the player destroyed and what they didn't. This solution uses an array of structs, representing the rocks. On each first and third beat, a loop checks if any rocks are null, and if so, spawns another of that same class at the desired position and rotation.
When the player goes from the first area to the second, there a number of changes that need to be addressed. This function calls some others needed to address changes in UI, and then crossfades the first area's music with the second area's. The music tracks are divided into several different variables to allow for greater control.
Collaborating on Game/Level Design
With the goal of making everything as clear and fun as possible, we spent lots of time iterating over the flow of the game and level layout. The second area of the game is less linear than the first, and involves the player finding three flowers to open a larger gate. Below is an overhead view of the entire area, as well as the gate they need to open.
We found that adding paths to the various flowers, and displaying the first one on top of a centered, elevated rock, gave the clearest motive.
The gate has three smaller buds on its trunk that open when the player collects a corresponding flower. This idea is communicated when the player opens the first flower and sees a particle fly towards the gate, opening the bud on the gate.
Watch the Full Game Here!
Below is a video showcasing the entire game from start to finish, with some cuts for brevity. Hopefully you think it's as cool as we do!