Composing for Video Games -- and Adaptability
Until this recent article from the Boston Globe, it hadn’t occurred to me that composing music for video games would be different enough to warrant a whole subcurriculum. The Berklee College of Music is offering five separate courses this term alone in video game audio or game (musical) scoring.
What makes composing for video games different? Video games are interactive. What happens in the game changes each time someone plays. Traditional compositions, on the other hand, are written to be played sequentially from start to finish.
Adaptation in music as it is performed live, of course, is not unknown. Consider a good jam session, or music that is played as stars walk to the podium to receive their awards. In the former case, the jammers only have to sense and adapt to each other (and perhaps to the enthusiasm of the listeners), while the music used at award shows is pretty much a set of preplanned snippets. Music written for a video game, on the other hand, has to be able to branch in specific ways at many different points.
It struck me, after thinking about the article, that this nonlinearity, this arbitrary branching, also models how we read the World Wide Web. We might start out looking up what a “Kessel Run” is, for example, only to find ourselves linking to the definition for “parsecs.” A wise web page creator will not design her text and graphics to be processed linearly as if we were leafing through a book, but will rely on hyperlinks to allow her readers to dig further into other issues according to their interests. And with interactive web languages, the pages can even modify themselves dynamically in response to inputs from the user.
And for those of us who are software designers, I’m finding more and more of us adopting the notion, common to a number of Agile methodologies, that requirements are going to be constantly changing on us, so we had better adapt our development methods accordingly. (See a brief example from Damon Poole, as well as Vellenga’s Law of Project Redefinition.) The old waterfall methodology, in which a group first settled on requirements, then used those to drive an agreed-on design, then implemented, then tested, and then delivered, is falling out of favor. I have heard an unconfirmed report, for example, of one project that was completed in 18 months, exactly according to the original requirements, only to be ignored by the customer because that was no longer what the customer needed. (And yes, the customer did agree that the vendor had provided what was contracted and did pay the bill.) In a way, software engineering has something in common with the video game itself, in that it has to constantly respond to new inputs from the user.
Another Globe article briefly reviews the music composed or arranged for five different video games.
What makes composing for video games different? Video games are interactive. What happens in the game changes each time someone plays. Traditional compositions, on the other hand, are written to be played sequentially from start to finish.
Adaptation in music as it is performed live, of course, is not unknown. Consider a good jam session, or music that is played as stars walk to the podium to receive their awards. In the former case, the jammers only have to sense and adapt to each other (and perhaps to the enthusiasm of the listeners), while the music used at award shows is pretty much a set of preplanned snippets. Music written for a video game, on the other hand, has to be able to branch in specific ways at many different points.
It struck me, after thinking about the article, that this nonlinearity, this arbitrary branching, also models how we read the World Wide Web. We might start out looking up what a “Kessel Run” is, for example, only to find ourselves linking to the definition for “parsecs.” A wise web page creator will not design her text and graphics to be processed linearly as if we were leafing through a book, but will rely on hyperlinks to allow her readers to dig further into other issues according to their interests. And with interactive web languages, the pages can even modify themselves dynamically in response to inputs from the user.
And for those of us who are software designers, I’m finding more and more of us adopting the notion, common to a number of Agile methodologies, that requirements are going to be constantly changing on us, so we had better adapt our development methods accordingly. (See a brief example from Damon Poole, as well as Vellenga’s Law of Project Redefinition.) The old waterfall methodology, in which a group first settled on requirements, then used those to drive an agreed-on design, then implemented, then tested, and then delivered, is falling out of favor. I have heard an unconfirmed report, for example, of one project that was completed in 18 months, exactly according to the original requirements, only to be ignored by the customer because that was no longer what the customer needed. (And yes, the customer did agree that the vendor had provided what was contracted and did pay the bill.) In a way, software engineering has something in common with the video game itself, in that it has to constantly respond to new inputs from the user.
Another Globe article briefly reviews the music composed or arranged for five different video games.
posted by Jim Vellenga at
5:28 PM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home