Sunday, April 21, 2013

Post Mortem: The Daybreak OST / Writing Music for Games at DigiPen

For the past couple months I've been writing music for Daybreak, a co-op survival game from a team of Master's students at DigiPen. The finished product (the soundtrack, not the game) is currently available here. I highly encourage you to take a moment and listen. This is the largest amount of original music I've written for a game yet and, while I do wish I had more time to spend on a few of the tracks, overall, I'm extremely proud of the work I did.


Crystal's Radiance and March of the Afflicted, the first two tracks I wrote for the game, turned out the best by far. They came about as the result of those all-too-rare moments when inspiration crashes over you like a wave, leaving you no choice but to succumb to its inexorable current. I'm still learning to capitalize on those moments and, more importantly, how to kick-start the creative engine when it just doesn't want to go. Creativity is a fearsome yet majestic beast, to be sure; mastering it will not be an easy task, but certainly a necessary one if I hope to succeed on larger projects.

COMPOSING FOR REAL-TIME INTERACTIVE SIMULATIONS
One of the things that makes writing music for games difficult is that everything, be it code, art, or sound, is subservient to the game. The music is written for a purpose and, consequently, if it doesn't adequately serve that purpose, it's of no use. Movies and television have a similar problem, but in games there are other challenges, structure and pacing in particular, that make things even more difficult. When writing music for music's sake, particularly music without lyrics, the composer has more or less total control over these elements - he is, in effect, writing his own narrative. In cinema, these elements are out of the composer's control, but they are scripted - the composer knows what's going to happen, so he can write music to match.

Now we come to games: the composer doesn't control the narrative, nor does he know exactly what's going to happen. In the struggle to find a voice within the chaos of a real-time player-driven experience, it's extremely easy to fall into the trap of (a) writing music for music's sake or (b) writing music that is dispassionate and impersonal, often without realizing it. I won't comment on whether I successfully avoided these pitfalls for this particular project, as it's probably too soon to make that call, but I will say that it was substantially easier to write for this game than for a few others I've worked on. Part of that was due to the nature of the game; having multiple environments and/or gameplay types (with the day and night phases, this game provided both), was immensely helpful in that it provided a less confined creative space in which to work.

This isn't the norm at DigiPen, however, as most student games are, stylistically, relatively one-sided affairs due to time and resource constraints. While the restrictions imposed by those sorts of games can be helpful when trying to hone in on what music is going to work, they also make it far easier to end up in a situation where you've written a track that's essentially unusable for one reason or another, especially if the game ends up changing directions radically. And believe me, that can and will happen; student games are especially prone to sudden metamorphoses and, as stated above, everything is subservient to the game.

COLLABORATION AND FEEDBACK
From what I understand, the developers of Daybreak intend to continue with the game next year, as most of the team are still in their first year of the Master's program at DigiPen. However, since I'll soon be receiving my diploma from that same university, I likely won't be able to write any more music for the team. That being the case, I think it's worth touching on my interactions with them.

Looking back, I can say without reservation that this has been one of the best experiences I've had writing music for a project, particularly for one that I'm not otherwise directly involved in (i.e. coding, design, etc.). A good portion of that is thanks to the team. They treated me like a regular member (or at least as much as is possible when I'm not on site very much) and were explicit as to what they expected of me; they specified the number of tracks, about how long each should be, and so on.

More importantly, they had a clear idea of what they wanted, stylistically, and told me when things didn't fit. While getting my work out there is certainly a priority, it also needs to mesh with the aesthetic and personality of the game, so it's fantastic when a team has a clear picture of what their game is and is not on all fronts - mechanically, visually and aurally as well. Unfortunately, in my experiences thus far, this is the exception to the rule as opposed to the norm.

AUDIO AS PART OF THE DEVELOPMENT PROCESS
Based on what I've observed during my years at DigiPen, at least in the Master's program, music and sound effects are generally treated as an afterthought, tacked on at the last minute; I got requests for music from some teams a mere few weeks before their deadlines. Needless to say, I wasn't able to write new music for these teams. I did manage to provide them with some pre-written tracks that I deemed a good fit, or at least as good a fit as one could hope for that late in the development cycle, but this sort of situation is less than ideal for both parties.

Having been part of the development process in a variety of capacities, I can understand why this happens, but that doesn't excuse it in the least, especially considering how much of an impact sound can have on the player experience when done right. There's a lot of emphasis put on how important it is to "get artists" (which sounds really silly; they're people, not art-making machines, and their fit for your team as a person is as important as their talent) and to bring them on early. This is all well and good - art is very important - but there's often little to no mention of sound effects or music.

When I began working with the Daybreak team, I suggested they put together playlists of existing music they felt would be a good fit for their game. Not only does this help the composer get a better sense of direction for the initial music concepts, it also gets the team thinking more about how sound and music will fit into their game. I was brought onto the team a few months into the project, but ideally this process should be started at least by the time the Game Design Document gets put together.

Bottom line: Sound and music need to be considered more thoroughly, earlier on in the process. I imagine that as the new music and sound design programs start gaining momentum, the shift in focus that's required for this to happen will occur naturally. Still, it'll require effort from both sides, and it's definitely worth talking about now.

Questions or comments? Post below or drop me a line!


--Jeremy

No comments:

Post a Comment