How to Plan the Jam: Making Videogame Music with External Collaborators
Video game development teams have always been known for being multi-disciplinary, conformed by people from different departments. Learning to communicate and understand each other is a continuous work in progress. However, there might be external collaborators who aren’t always around, and communicating with them is even more complicated. Such is the tale of musicians vs developers.
In our studio we don’t have any kind of sound designer nor composer, so when we’re developing a project we have to rely on a professional studio; just like we did on Mucho Taco! Where we found allies with Soundscape Studio.
The musical composition of a game differs with that of any other piece of media and it is wise to keep in mind the following considerations:
- The player is in control of the game’s progression.
- This means that that music track can change at any moment.
- Music tracks must loop.
- As the game can be left idling for an indefinite amount of time, some music tracks must be able to be played again and again without any noticeable interruptions.
- Music tracks mustn’t be lengthy.
- Free space is a precious commodity, specially for mobile games. The amount of tracks and their duration must be kept at the bare minimum needed.
All these considerations were shared with Soundscape when we showed them the project and the art we had of it. They also played the demo version of the game. We shared some music tracks from different media (TV shows, movies, games) that we thought could serve as inspiration.
Using that information as a reference, the Soundscape team built different inspirational pieces to find the core concept for what would later become the main theme for the game. Here’s one of them.
Once both our teams settled on a melody, we explained to the musicians how the tracks had to be exported. Communication between the programmer and the musician was going to be an arduous task, so I realized we would most definitely need a diagram to visually represent the game flow and the exact moment where each track should be played.
I started to build my own nomenclature so programmers and musicians could understand each other, and the result after some iterations was this:
Music diagram’s nomenclature:
- Track Frame
- Displays the name of the audio file to be played.
- Represents a single piece of music. Length may vary and can be either an intro or a loop.
- Theme Frame
- Composed by two or more Track Frames or Theme Frames.
- These are used to combine small music pieces in order to create a longer one.
Complementary information for Music Frames.
- Left Side
The Track Frame or Theme Frame will be played only once.
The Track Frame or Theme Frame will play twice or more in a row. That way, the musicians will know that the track must loop.
- Right Side
- Number of Loops
How many times the Track Frame or Theme Frame should repeat.
- Infinite Looping
The Track Frame or Theme Frame will loop indefinitely until a specific event takes place (usually an action by the player).
- Number of Loops
Displays the intro and outro behaviors of a Track Frame or Theme Frame.
- In (Empty or White connection).
- Out (Filled or Black connection).
- Cut (Rigid corners)
- Indicates that the track either starts or ends abruptly.
- Fade in/out (Rounded corners)
- Indicates that the track will fade in or out.
- Fading Time
- Duration (in seconds) of the fade.
- Instant Play
- The Track Frame or Theme Frame will be played from the start.
- Match Time and Play
- The Track Frame or Theme Frame will be played from the same timestamp as the previous Frame.
- This is especially useful when the musical composition must remain the same with a slight instrumental variation.
- First to Play
- This will be the first Track Frame or Theme Frame played within a Theme Frame.
- The Track Frame or Theme Frame will move onto the next Track Frame or Theme Frame after its whole sequence has finished.
- The Track Frame or Theme Frame will not go onto the next one until a specific trigger event occurs. It can be activated by the player or by an action within the game itself.
- Specifies the name of an event that will trigger a change of Track Frame or Theme Frame.
For example, this is the music diagram for Mucho Taco!’s main theme:
A Theme Frame that loops indefinitely, which is composed of another Theme Frame and a Track Frame.
The track order is as follows:
Flutes Song / Flutes Song / Normal Song / Normal Song / Flutes Song / Flutes Song / Normal Song / Normal Song / Idle Song / Idle Song / Idle Song / Idle Song
For our game (Mucho Taco!) we designed several events which change the BG music. One of such events is the player-activated “Fiesta”. When it happens, the current track must stop and the “Fiesta Song” will be played instead; which is a track with a well-defined beginning and ending with a fixed duration.
Another BG music disruptive event is called “Mucha Suerte” which is triggered automatically. This event does not have a fixed duration and the player can stay on that event an indefinite amount of time, so it must have a track that is able to loop.
To ease-in the loop-able portion of the track, we decided to add an intro track that leads to it.
MUCHA SUERTE INTRO:
MUCHA SUERTE SONG:
Indicates the beginning of the diagram. In our case, a mobile game means the player can open and close the game anytime, so any re-entry points must be highlighted on the diagram depending on the player’s progress.
Finally, we incorporated the game tutorials, which led the final diagram to look like this:
A simple diagram that efficiently shows the musicians how the tracks should be prepared.
Thank you for reading! Hope you find this information useful in your game making. If you enjoyed this post and want to check the music diagram working in our game, Mucho Taco, click this link and have a great #indiedev!
*Download editable file here*