Dynamic themes were an important part of STAR WARS EPISODE III: REVENGE OF THE SITH’s universe.
A GREAT GAME SCORE IS ONLY AS GREAT as its implementation. Unfortunately, composers are only closely involved in music implementation a small percentage of the time. The task of wiring a game’s soundtrack frequently falls to audio leads, music supervisors, music implementers, programmers, or any combination thereof. In-house composers find they have a greater chance of tackling implementation, while freelance composers will most likely find themselves only peripherally involved.
Additionally, music implementers are faced with their own set of problems. For the most part, music is a somewhat nebulous aspect of a game’s construction. There is a largely unspoken guideline among Q/A departments that states, “If music is playing, everything’s working. If music is not playing, something’s broken.”
According to Michael Ward, Q/A tester for LucasArts, “No other aspect of video game development requires more open communication between testers and developers than audio. If the line of communication is not established, then there is a blind spot between the developer’s intentions and the tester’s intuition.” Frequently, this line of communication is never substantially established and so the burden of all Q/A work for music rests solely on the shoulders of the implementer/composer.
The result is often that the composer hands control of the music to a team of people that may or may not include any musicians, who are entirely responsible for the bug-free implementation of the soundtrack. With such a scenario occurring so frequently, it’s little wonder why repetition fatigue, playback bugs, and unmusical execution are still common issues in game music development.
WITH A LITTLE HELP FROM MY FRIENDS
There are, however, two very specific steps that can be taken to help composers and implementers get more ears listening for bugs and free up communication regarding the intended music implementation.
Forget for a moment the “If music is playing” axiom of test. The truth is that Q/A is the last line of defense for all bugs between the developers and the consumer. Testers spend every day neck- deep in the game ravenously looking for problems. With a little bit of guidance, testers can become a composer/ implementer’s best friend. They simply need to be told what to listen for.
The best way to do this is to enlist the aid of a dedicated audio tester. Most test teams, whether at a large publisher or a small developer, have someone with some kind of musical background or an ear for sound. The goal is to first identify this person and then request that, at the very least, he or she set aside a few hours with each new build of the game to go over audio issues, and only audio issues. This centralizes the point of contact for audio bugs, allowing the developers to highly educate one person on the intended implementation. The second step is to give the tester the information he or she needs in order to find bugs.
X MARKS THE SPOT
In 2004, LucasArts developed STAR WARS REPUBLIC COMMANDO. To give the game a cinematic feel, we developed a complex interactive music system that reacted to AI activity, scripted events, and had branching gameplay. As such, the music implementation was often closely tied to issues that were completely out of my control. Small changes to props, doors, or enemy counts would sometimes result in bugs like music loops that never ended or broken transitions between cues.
To help fight the battle against music bugs, I enlisted the help of two audio testers. I spent a few days writing up what I named a “music map.” The music map was in essence a blueprint, a Microsoft Word document that specifically detailed every instance of music throughout REPUBLIC COMMANDO and where each music change occurred. For example, one specific instruction read, “If battle music is playing, walking into room D will cause a victory flourish to play, followed by a new suspense cue.”
With everything detailed, Q/A simply had to read through the music map and write up bugs when the music failed to respond as it was documented.
A few months later, the level designers at The Collective were handling the music implementation for STAR WARS: EPISODE III REVENGE OF THE SITH. Again, I spent a few days producing a detailed music map of all of the intended music changes and then handed it off to both The Collective and our dedicated audio testers. This time, not only did the remote music implementers have detailed instructions of where music was to be wired, but Q/A also had a way of checking to ensure that everything was wired correctly—all of which was centrally located in one document. When music wasn’t properly wired, bugs were written up and assigned to the level designer in question, creating an official request for music to be fixed.
Although control over the music assets was out of my hands, both level designers and Q/A were following my documented intentions as specific guidelines. The result was a small team of people all working together toward perfect music implementation.
TAKE THE TIME
Dedicated audio testers and music maps work toward removing the barriers that commonly block communication about music implementation. By taking the time to enlist others in the fight against bugs and to create a centralized music map, composers/implementers need not endeavor to implement a great game score alone.