Lessons Learned: Video Games, Part 1
Hello again, gamers, and welcome to the penultimate installment of Lessons Learned, where I bastardize hard-won industrial methods of creative production for my own nefarious ends. Today, I’m going to talk about game development, in preparation for the final part in which I will finally justify the amount of time I’ve put into video games since finishing my last degree. It turns out that there’s a lot of things us composers can learn from game development: not only does game dev espouse some very consistent and helpful creative practices, but the division of labour in the games industry can make for some interesting ways of conceptualizing the composition process. I blitz-wrote this in a midmorning haze in front of my cat at my parents’ house, so I hope you will forgive any hasty errors. On with the show!
Lesson 1: Failure
A common theme in many of the video game development manuals and YouTube tutorials I’ve consumed over the years is that of iteration, or the importance of being able to work out a banal idea, scrap it, take its best aspects, and start all over again with a slightly better idea. Every creative I’ve ever met has held (and my personal experience has confirmed) that ideas, or at least initial ideas, are always going to suck and they should be taken with a grain of salt – frequent and repeated failure is essential to any creative enterprise. Failing shouldn’t be taken as a sign to stop working, but rather to continue working further: the faster you fail and cycle through bad ideas, the sooner you’ll end up with a great idea that works really well.
In composing, there are a few different ways of approaching this kind of failure: the one that I was taught by Allen Bell closely resembles that of game development in which you generate a ton of ideas, rigorously test each one, and only keep the best. The other method, famously used by American composer John Corigliano and his students, involves refining a slate of bad, initial ideas into a singular, hardened diamond of an idea that guides the entire piece. The result of the first method is usually a panel of refined musical ideas comprising notes and rhythms whereas the result of the second is more akin to a thesis statement or central literary theme. In my work, I’ve found myself stealing a little bit from both of these: deciding on a guiding thesis has helped me to focus my efforts of finding and refining material. While putting in a lot of work into these processes at the beginning can pay dividends throughout the birth of a piece, there’s still plenty of failing to be done after the initial ideas are set: more concrete elements, the actual “putting together” part of composing, is where the iterative ideas of game development really become useful. Rather than working section by section, though, I find it much easier to make a through-line of all or most of the piece after my initial ideas are settled, then work my way from beginning to end by filling in the details. Each section, then, becomes a new iteration on the ideas of the last; once I’ve got my first draft, I then repeat the process, further refining each aspect of the piece until I’m satisfied with it. Not only does this help with cohesion (returning to the beginning of a work after I’ve pushed through to the double bar almost always reveals new aspects of that beginning that I missed initially), but it also makes the editing process much quicker and easier since it gives me something to compare each section against. I find that this method conceptually unifies a piece in my mind, transforming it from a collection of disparate sections into something I can (hopefully) be proud of.
Lesson 2: Roles
Last summer I attended a workshop that centred around creativity and discussed a few ways in which we can conceptualize different parts of the creative process. One such approach that caught my attention was that of the “six thinking hats,” a method described by Edward de Bono in his 1985 book of the same name. Each of these hats represents a different mode of thinking about a creative project: for instance, the method’s blue hat symbolizes “thinking about thinking,” or planning and organizing the kinds of thinking that need to be done at every point in the creative process. I’m going to don this blue hat here and make a few parallels between the roles of different personnel in the video game process and different ways in which an individual composer can conceptualize a piece. Unlike in video games or film, us composers often work on an entire project alone, without much outside feedback or support until the piece is (almost) complete. In every piece I’ve written since finishing my Master’s degree, I’ve wished at times for the kind of feedback I would get from my supervisor: the roles I’m about to describe are a cursory attempt at replicating that outside perspective.
In game development, the designer is the creative lead, conceptualizing systems and structure as well as (sometimes) planning out the game’s narrative. A game designer needs to be a planner as well as a creator, generating ideas about gameplay mechanics as well as deciding where and when in the game’s structure those mechanics should appear. A game designer also acts as a sort of literary dramaturg for the dev team: they need to be aware of the history of game design as well as recent trends and new innovations in the industry. In a (horrendously oversimplified, real game devs please don’t laugh at me) sense, the game designer approaches a project from a high elevation, beginning with a bird’s-eye view of the project and gradually honing in on different sections of the game as they become more fleshed-out. Whenever I’m writing a piece, I put on my designer hat whenever I need to generate material or make creative decisions about what goes where, how long a section should be, et cetera. It’s a great way to sieve out minutiae when they’re not important: when I’m trying to figure out a piece’s form, I obviously don’t want to be distracted by thinking about whether or not a certain double stop is possible for the cello.
Sometimes, though, minutiae can make a break a piece (or your rapport with your performers), and that’s where the programmer hat comes in. To my limited understanding, game programmers make everything happen: they engineer physics, non-player characters, the user interface, and a dozen other extremely important parts of any video game. Programmers are hands-on professionals who make a designer’s ideas into something tangible, taking ideas about mechanics and gameplay and ensuring that they feel good to play with. The composer analogue to this role is similarly important. When I put on my programmer hat, I’m thinking about nuts-and-bolts details: is this passage possible on this instrument? How exactly should this harmony be presented? What are the notes and rhythms going to be for this melody? To be completely honest, this is the part of composing that I struggle with the most (thanks, ADHD), and being able to separate out the concrete from the conceptual in this way has done wonders for my ability to break each piece down into actionable tasks.
Conclusion
See, guys? I wasn’t just being lazy and procrastinating on writing my pieces this entire past year, I was learning about the creative process! In all seriousness, though, the above tips have saved me a lifetime of grief and helped turn my neurodivergent musical hyperfocus sessions into something resembling a coherent creative process, and for that I will be eternally grateful. Join us next week, when I will argue that my time spent in Monster Hunter and Risk of Rain 2 was actually helpful to my career as an artist. Thanks for reading, and take care, everybody.