Skip to main content

Things to Consider When Scoring for Games, part 17 min read

By Kole HicksThese articles are not intended to be a master source for everything one must consider (and how to prioritize them) when scoring a game, rather it will be a series of articles based off my experiences with each newly completed project. As I learn from the process, the other developers that are involved, and write about the experiences here, I hope the information will help better guide your future scoring efforts for games.

When scoring for any medium, our ultimate goal as a Composer is to enhance the listener/audience/participant/gamers’ experience. In this way all Composers are exactly the same, as we want to move people when they hear whatever we’ve created. The differences always come down to the technical details. The technical skill set one has to have when composing to locked picture is quite different from those necessary for creating an adaptive score ready to change based off the gamer’s choices. Likewise, there are different things we must consider as Game Composers… I would like to talk about 4 today that specifically came up (and I learned more about) when creating the music for the fun puzzle game “Box Knight“.

I. Platform Constraints

Interestingly enough this was one of the last things the developer and I spoke about, because when I was originally approached to create the score for the game there were two platforms it was being ported to… PC & iDevices. Since there was so much emphasis on creating great music at a decent enough length that it wouldn’t get old and an unspoken understanding that the PC port was priority, certain app store limitations for the mobile version never crossed our mind until much later in the development process.

Was this a bad thing? Perhaps, I always like to take as much into consideration as possible before writing a single note of music. However, since the overall goal was to create a great product with a decent amount of high quality music, the 20mb over 3G limit wasn’t a concern. Yes, this means that you can only download the game via WiFi connection, but both the developer and I think the quality/quantity of the end product makes up for this slight inconvenience.

II. Serving the Right Purpose

Fortunately, the developer was fantastic with communication and already had a playable client ready when I was approached to do the score. This helped immensely at discovering the game’s tone, feel, art style, etc. After a few initial e-mails discussing the direction of the music and signing some paperwork, I was left to create some music. After spending a decent amount of time recording live guitars (in alternate tunings), vocals, and programming V.I., the music for the first half of the game was completed. Confident in my work, I sent it over to the developer and began working on the rest of the music.

 

Unfortunately and humbling for my ego (haha), the developer got back to me very quickly saying that he really enjoyed the piece, but it didn’t make sense with the game play. After discussing it back and forth, we came to find out that although the art style is unique, it was essential to cue off the game play instead. I had paid more attention to the cool art style when that was in fact the 2nd most important thing the music was supposed to serve. The priority was urging the player forward to complete the level more quickly. With my new understanding of the priority and some arrangement adjustments (plus a few percussion parts), we came to a solid piece that served the correct purpose. Linked below are two short excerpts from the original piece (to dynamic) & the updated version (consistent pulse/rhythmic movement propelling you forward).

Grass Theme:

Original Version VS Updated Version

Also, as a side note I’d just like to mention that the developer also didn’t initially like the feel/style of this first piece. This was mainly because temp. music was used throughout the development process before hiring me, so the developer became very accustomed to hearing a certain style while playing through each of the new clients. Eventually it all worked out though and I’ll explain more about that below.

 III. Overall Vision

As I mentioned above, the developer was using temp. music for the game before I was hired and was (rightfully) expecting something similar… otherwise why pick that temp music? However, in our initial discussions about the music we came to the conclusion that it was important to capture the differences in art style/difficulty level as you progressed through the game.

The first half of the game is much easier and features grass themed puzzles. However, as you progress forward it becomes much more difficult and the grass theme turns into a dungeon theme (which can be heard in the Trailer). Our understanding of expressing the difference between this progression was solid, but we differed on how that would be accomplished with the music.

Since the developer only used a single style temp track throughout both the grass & dungeon themed levels, our ideas of where that style fit best differed (in the future I’ve learned to be more clear when temp tracks are involved!). I felt that the temp style fit quite well for the dungeon theme (as it was intense but not too dark… fitting with the art style) where as the developer believed that it fit well for the grass theme and going darker for the dungeon theme was best.

I strongly felt opposed to this view, as it would take this unique/light art style and might make it a little too heavy or serious… I didn’t want the music to weigh down the experience. However, I always try to make the client happy and began to work on an alternate version. Fortunately for both of us, after the developer had played through the client with the original tracks in the background (while I was working on the alternate) he came to really like the first piece and appreciated the change in feel between each style. This is what I initially envisioned, so I was not only glad to hear that the developer was happy, but learned that sometimes its best to “stick your ground.” If time allows for a concept to fully sink in it’s much more likely that the developer will understand/enjoy your intent and have a change of heart.

IV. Recording/Composition Process

As is true for most Composers, the Composition/Recording process often differs from project to project (and sometimes from piece to piece). However, as continuity & accurately expressing an overall vision are very important to me, I try to keep some parts of the process consistent from piece to piece within a project.

Since ‘Box Knight’ was to feature acoustic guitar more than any other instrument, I made sure to write with the guitar & double check that everything would be idiomatic. It’s very easy to get carried away in a song & write outside of what is idiomatic for an instrument (especially when writing for guitar). With that said, I did alter the tuning of my guitars for the ‘Grass Theme’, as the fingering for certain shapes were way too difficult in standard tuning.

It was only after I had set a foundation with the entire (solo) guitar track, that I would then go back & not only add in the other instruments, but “break down” & record many of the guitar parts separate from one another (so I could have more control over them in the mix). Often, I found that even though the acoustic guitar was the “glue” that connected the pieces together, that didn’t mean it always had to be the center of attention throughout the entire piece. So, I had no problem pulling down its level in the mix or playing background lines while a different instrument took the lead if that would best serve the song.

As mentioned in the italics at the beginning of this article, this is by no means a complete list and I’m still a young professional with many ups/downs ahead in my career, but nevertheless I believe this information can be beneficial to many composers no matter their experience level. Thanks for reading and keep composing fellow artists!

About the author: Kole Hicks is an Author,
Instructor, and most prominently an Audio Designer with a focus in Games.
He’s had the pleasure of scoring mobile hits like ‘Bag it!’, has provided
audio for Indie PC titles like ‘Kenshi’ and ‘Jeklynn Heights’, and was nominated
for a 2012 GANG award for an article written exclusively for Shockwave-Sound.com
titled, “Mixing as Part of the Composing Process. Emotionally Evocative
Music & Visceral Sound Effects… Kole Audio Solutions.

Bjorn Lynne

Bjørn Lynne is a Norwegian sound engineer and music composer, now living and working in Stavern, Norway. He was also known as a tracker music composer under the name "Dr. Awesome" in the demoscene in the 1980s and 1990s when he released tunes in MOD format and made music for Amiga games.