BREK DYNAMIC MUSIC

BRICKTRIS - CREATING DYNAMIC MUSIC

INTRODUCTION:

Music and sound are integral to making a game feel more immersive. A great game can easily be ruined by a poor choice in music and sound design, while an already fun game can be taken to the next level with great sound. What makes a song “good” or “bad,” is purely subjective. The timing of that music, however, is less so. Nothing is more satisfying than having the music drop at just the right moment in your favorite part of a game; on the flip side, nothing is less satisfying than when it doesn’t. This is where the idea of Dynamic Music comes in.

For this project, I have developed an arcade style mini-game within Brek. Bricktris is based around randomly generated sets of bricks which slowly descend to the bottom of the screen. Each time a brick hits the bottom, you take damage. When you lose all of your health, the game is over. As you clear sets of bricks, the bricks become stronger, there’s more of them, and most importantly: the music becomes more intense. As the player completes stages, the music slowly builds over time. Also, a sound will play whenever the player destroys a brick, hits the ball, collects a power-up, and more. This effect gives the player the feeling that they are in control of the music.

Bricktris gameplay

Brief Design Overview:

When writing a song for this particular context, composition plays a tremendous role. The ideal structure is a collection of transitions and loop sections. Transitions will bring us seamlessly from one loop to the next, and loops will play continuously until certain criteria are met. Once the song is written, it’s time to break it into chunks.

For the song used in Bricktris, we have an introduction, 4 loops, and a transition between each of those loops. Lastly, we need some special sounds to play during specific timed events. These are sounds like ball impacts, upgrades, transition fills, and so on. Once we have all of our sound bites together, it’s time to get into the actual programming. We will break our script into 2 major segments:

The part that plays different segments of the song as the level progresses
The part that plays our special event sounds

The transition / loop section cycle continues for as long as we want to make the song

Part 1

The goal of this part of the script is to have the song play through from start to finish as the difficulty of the game increases. The intro of the song is treated as a “transition” sound. The script will play the intro until the first loop, and then continue looping until the player meets the requirements to enter the next loop. In this case, the player must have reached at least level 4 to enter the next loop. After the player reaches level 7, the song will play the next transition, followed by the third loop. This cycle of transitions and loops repeats until the end.

To make the song flow correctly we need to be checking if we can advance the song at specific intervals, otherwise, the song will sound like it is being interrupted or rushed. This interval is based on these factors:

Tempo in BPM
Time Signature
Number of Bars (in this particular segment)

Let’s take a look at the first loop as an example. Given the tempo of 96BPM, a time signature of 4/4, and a length (in measures) of 4, we know this segment of the song to be 10 seconds long. Once the loop is over, it is played again from the beginning. When the player reaches level 2, the script knows to move on to the second loop. However, we don’t necessarily need to wait a full 10 seconds to transition. We can neatly divide the loop into 4 chunks of 4 bars, and still have the song sound natural.

When the player reaches level 4, the script is told to transition at the end of the next set of 4 measures rather than at the end of the loop. Otherwise, the longer we wait to transition, the more there becomes a disconnect between gameplay and music.

Part 2

The goal of this part of the script is to play various sounds during specific events. Similar to how we check if the player can advance the song at regular intervals, we have to check if the player did “something” at even more regular intervals; we’ll call this an "event sound." This will give the player the feeling that they are ‘performing’ the song with their actions.

What this script does is organize a player's sporadic actions and synchronizes them to a subdivision of the tempo of the song. This subdivision can't be too small or too large - if the script checks for an event sound at the end of each bar, then it will appear as though certain player actions aren't producing sound. If we divide the measure too much, then the event sounds begin to sound sporadic and arrhythmic. This effect feels most convincing at 1/16th of a bar, or a sixteenth note.

Put simply, we are snapping the player’s actions to the nearest 16th note on a music staff. Each action then plays a sound at that time. Going even further, we can create an array of sounds for each event, and randomize them. This makes each ‘performance’ feel unique, and truly as if it was played by the player’s own hand.