Composing Jobs and Scripting

[WillRock]

So I don't know how many of you know but i'm looking into becoming a game composer.

I've done a few small time things but not actually worked at a company, and found out about "Scripting" which is basically making the sound work in the game via text, like making explosions go off at the right time etc. Now I assumed (perhaps incorrectly) that wasn't done by the composer, but according to an article i'm reading I may be wrong.

Now... i'm curious, if I was to want to work at lets say... SEGA (hypothetically) how much would I need to know about scripting? I'm assuming its a very important part of the process, and what would I need to learn, what programs would I be using etc? Would anyone here in the know be able to advise me at all here?

Edited March 6, 2014 by WillRock

[Garrett Williamson]

This interests me quite a bit. Is scripting that important? I always thought of it as an additional thing that isn't necessarily required. If it is, though, I'd love to learn more about this as well because composing for games is something I often am interested in.

[zircon]

Prepare for a long post I'll try to keep it focused!

There are a few different audio jobs one might have in the game industry. Keep in mind these are not necessarily exclusive... you could be an inhouse sound designer but do freelance composing, or an audio programmer that also does music editing.

1. Freelance composer or sound designer. In either of these cases, you're creating assets and material for the developer. It's very unlikely that you will personally be doing anything with the game engine, code, etc.

2. Inhouse 'audio designer', sound designer, composer (rare). In a job like this, you will likely be involved in much more than just creating assets. You may be doing editing, optimization, looping, and other things to make sure the assets work right with the game. It's possible you'll be involved with some code as well; more than likely, you will be using some kind of "middleware" like FMOD or Wwise. These are basically software packages that handle audio for a game, allowing you to make many changes and edits without going into the code.

I'd say the majority of non-indie games use some kind of middleware. It might be a custom solution, but it will most certainly be there. Gone are the days where you would have to specify everything in code (or script). You can set a huge number of parameters for sounds, including some triggering behavior, in the middleware. The complexity of interaction here can be immense or simple depending on the game.

3. Audio programmer. Here you will definitely have your hands dirty with code. Not all developers have dedicated audio programmers, but a good chunk of the bigger ones do. You'll be working on making sure the audio engine runs smoothly - that might involve using middleware, creating a new solution, editing existing code, etc. This is where code comes in the most, obviously.

I would say that if you're interested primarily in writing music, it is unlikely that you will NEED to do any coding yourself. However, knowing a bit about programming 'logic' in general may be beneficial. You want to be able to communicate with programmers if there are things that need to be changed about how audio is triggered or handled.

[Phonetic Hero]

I would say that if you're interested primarily in writing music, it is unlikely that you will NEED to do any coding yourself. However, knowing a bit about programming 'logic' in general may be beneficial. You want to be able to communicate with programmers if there are things that need to be changed about how audio is triggered or handled.

Any suggestions on where to start? This is all good information, thanks for posting

[Dafydd]

Any suggestions on where to start? This is all good information, thanks for posting

If you're into computer games, try getting involved with mods. A lot of mods modify sound, music, graphics, game behavior etc. and because modders typically don't have access to the game's source code itself, they'll have to make do with scripts. So anytime anyone wants to add a new sound to the mod that wasn't in the original game, or change when what sound is played, someone will have to create or modify a script. Any game that has a Steam Workshop should be a good place to start, if you want to get an idea of what it's all about. Some modding teams are interested in having someone make music for them (modders work for free, so it's a lot easier to get that kind of assignment than to land a job). Once you're on the team, someone can teach you how to do stuff.

I very much doubt that your knowledge of scripting will have any bearing on whether or not someone will contract you to write a game soundtrack, but if you make a soundtrack for a well-known mod, that's something to add to your portfolio.

Edited March 7, 2014 by Dafydd

[timaeus222]

Any suggestions on where to start? This is all good information, thanks for posting

I'd assume concepts such as loops, conditionals, arrays (possibly), lists (maybe), strings (maybe), stacks (maybe not), pointers (possibly), queues (probably not), etc. Obviously you wouldn't need to actually know how to write code for them, or even interpret code that you see, but having a general idea of how they work may help.

For example, it may be useful for communication, if, say, your programmer discusses something like this:

--------

Background information:

|| Imagine you look into the game data of a simple GBA game like MegaMan Battle Network 6. At the right memory offset (an address indivisible by 8 decimal), you can basically find this array (kind of like a group/grid organized by dynamic or static length and width) of pointers (like signs that point along a street) that each point to a bunch of offsets where data is stored for the contents of the song---notes (pitch would logically be the number itself, but in whatever decimal format is practical; octal, hexadecimal, binary, etc.), rhythm (marked by gaps labeled through certain unused characters perhaps, like 00 or FF), etc.

Typically in 16-bit games, songs have headers that are a small array of offsets that each point to a "MIDI part" (e.g. an instrument), which is data that describes a particular instrument's properties and the notes that it plays. The rest of the data right afterwards is typically what these header offsets point to, involving loops, jumps, a "panoramic extraction" of an instrument out of a collection of instruments, the octave it plays on, the panning, the volume, the notes themselves, etc. ||

The programmer then says, "I still need a song that fits within 20000 bytes exactly because it's lying in between a song in the RAM area that ends at 0x031254 and another song that starts at 0x051254. It's going to dynamically load at the beginning, and then go all the way through and loop back to a point after a header that classifies the song and points to its MIDI parts that each contain an instrument playing MIDI notes. 20000 bytes is the equivalent of 2 minutes (not really, but for simplicity's sake, I'm going to say that), so can you write a song that is exactly 120 seconds long that can loop back to exactly 20 bytes after the start point (which is how long the header is)?"

--------

Well, by that logic, you'd need the song to loop at exactly 0.12 seconds into the song (maybe to prevent clicks to accommodate for the crudeness of the programming language used, or something like that perhaps), but you'd have to understand what bytes are, what looping asks a program to do, etc. A little bit of a weird example, but who knows, it might actually happen. Then you'd at least not be confused, and you'd probably follow what they say.

Edited March 7, 2014 by timaeus222

[Nabeel Ansari]

Winifred Phillip's guide on game music gives a good survey on the different jobs and aspects of game audio, from music composition to code implementation. Highly recommended.

I'd assume concepts such as loops (YES), conditionals (YES), arrays (YES), lists (NO), strings (NO), stacks (NO), pointers (YES), queues (YES), etc.

Fixed.

Edited March 7, 2014 by Neblix

[Garrett Williamson]

Prepare for a long post I'll try to keep it focused!

There are a few different audio jobs one might have in the game industry. Keep in mind these are not necessarily exclusive... you could be an inhouse sound designer but do freelance composing, or an audio programmer that also does music editing.

1. Freelance composer or sound designer. In either of these cases, you're creating assets and material for the developer. It's very unlikely that you will personally be doing anything with the game engine, code, etc.

2. Inhouse 'audio designer', sound designer, composer (rare). In a job like this, you will likely be involved in much more than just creating assets. You may be doing editing, optimization, looping, and other things to make sure the assets work right with the game. It's possible you'll be involved with some code as well; more than likely, you will be using some kind of "middleware" like FMOD or Wwise. These are basically software packages that handle audio for a game, allowing you to make many changes and edits without going into the code.

I'd say the majority of non-indie games use some kind of middleware. It might be a custom solution, but it will most certainly be there. Gone are the days where you would have to specify everything in code (or script). You can set a huge number of parameters for sounds, including some triggering behavior, in the middleware. The complexity of interaction here can be immense or simple depending on the game.

3. Audio programmer. Here you will definitely have your hands dirty with code. Not all developers have dedicated audio programmers, but a good chunk of the bigger ones do. You'll be working on making sure the audio engine runs smoothly - that might involve using middleware, creating a new solution, editing existing code, etc. This is where code comes in the most, obviously.

I would say that if you're interested primarily in writing music, it is unlikely that you will NEED to do any coding yourself. However, knowing a bit about programming 'logic' in general may be beneficial. You want to be able to communicate with programmers if there are things that need to be changed about how audio is triggered or handled.

Well this was super helpful, along with all the responses after it.

Thanks everyone and WillRock for beginning this thread, hahahahaha

[Dafydd]

Typically in 16-bit games [...] The programmer then says, "I still need a song that fits within 20000 bytes exactly because it's lying in between a song in the RAM area that ends at 0x031254 and another song that starts at 0x051254.

Seriously, it's 2014. How many people make games for the GBA these days? If you're a game music composer, you'll be expected to deliver audio, as in wav/aiff/mp3/ogg/whatever. You may need to make music that fits on a disc along with the rest of the game's data, but that's not any more complicated than "the soundtrack can't be any larger than 600 MB" (or whatever). Even if you're a script kid, or even a programmer, you won't have to worry about where in the game's memory things go. What you said does make sense, but only if you're making chip music.

Edited March 7, 2014 by Dafydd

[timaeus222]

Seriously, it's 2014. How many people make games for the GBA these days? If you're a game music composer, you'll be expected to deliver audio, as in wav/aiff/mp3/ogg/whatever. You may need to make music that fits on a disc along with the rest of the game's data, but that's not any more complicated than "the soundtrack can't be any larger than 600 MB" (or whatever). Even if you're a script kid, or even a programmer, you won't have to worry about where in the game's memory things go. What you said does make sense, but only if you're making chip music.

Well yeah, but it's just an example. I picked one that I could explain clearly.

[lazygecko]

Implementation of sound is a good general skill to have. Download Unity and UDK, and find stuff you can modify sound and music in.

[Fishy]

Seriously, it's 2014. How many people make games for the GBA these days? If you're a game music composer, you'll be expected to deliver audio, as in wav/aiff/mp3/ogg/whatever. You may need to make music that fits on a disc along with the rest of the game's data, but that's not any more complicated than "the soundtrack can't be any larger than 600 MB" (or whatever). Even if you're a script kid, or even a programmer, you won't have to worry about where in the game's memory things go. What you said does make sense, but only if you're making chip music.

As someone currently working on a 5 platform AAA game in the audio department, I can assure you memory allowances are still huge issues. Memory allowances are puny on consoles.

Music tends to be streamed so it's less of an issue, but sfx budgets can be brutal still. But even then, you're limited on how many streams you can have. Nothing is simple when it comes to loading and storing memory.

Edited March 7, 2014 by Fishy

[lazygecko]

Memory limitations is still a real issue for sure. A lot of games even use 22/32khz sounds still. Since we no longer use dedicated hardware for sound playback, it has compete with everything else for resources. And when developers decide on a resource budget for the different aspects, sound tends to not be very high on the list.

Once I started digging around in the innards of Skyrim's sound playback, it really got to me just how gimped everything was. They had to make tons of concessions to fit it within what I presume was the console RAM limits.

I don't think these problems are ever going to change in the foreseeable future. When we get more powerful hardware, developers just move the goalposts.

[DaMonz]

First of all, zircon's post pretty much nails it

As for scripting, it all depends on the development team you're working with and on each specific project's needs, but I'd say that implementing game-specific audio behaviour should mainly stay in the programmers' hands. It can be as simple as a single "Play" call (like triggering an SFX), and it can be as complex as a whole code file (dynamic music that evolves along with the gameplay, for example). You can learn how to code if you like, no one's gonna stop you but I don't think that it's that useful for someone who's mainly into composing. If you do want to learn it though just let me know and I'll see if I can help you with that. I'm told audio programmers are in high demand in the game industry, but if you're not already a programmer then getting ready for such a job is definitely a few years of learning and practice, unfortunately.

That being said, I think that you can probably find some work as a freelance composer mainly with indies, but the problems in this case are that indies tend to have little budget, and finding a team in need of a composer/soundtrack is difficult. If you can't manage to find a stable job as a sound designer for an established game company though, I think composing for indies is your best bet. Spread the word, make sure people know that you want to make game music, and opportunities might just show up

[Frederic Petitpas]

that can loop back to exactly 20 bytes after the start point

That's mental. You have to be spot on.

[Gollgagh]

it's not like you'd have to guess

in terms of your music engine, each step of your music will have a well defined length, and it'd be easy to keep tabs on your current length

[Nabeel Ansari]

You need to be working with a platform that supports byte-wise audio buffer manipulation.

[WillRock]

Just wanted to say thank you to everyone who responded to this thread, it has been most enlightening!

[alfredofreak]

2. Inhouse 'audio designer', sound designer, composer (rare). In a job like this, you will likely be involved in much more than just creating assets. You may be doing editing, optimization, looping, and other things to make sure the assets work right with the game. It's possible you'll be involved with some code as well; more than likely, you will be using some kind of "middleware" like FMOD or Wwise. These are basically software packages that handle audio for a game, allowing you to make many changes and edits without going into the code.

Both FMOD and Wwise have versions available to download for free if you want to start heading down that route. The School of Video Game Audio (run by Leonard J. Paul, aka FreakyDNA on the Retro City Rampage soundtrack) has two-month classes running year-round that consist almost entirely of you making a demo reel using one of those programs. You basically get instant sound design portfolio material.