1

Apart from regular tools (DAW, audio editor etc...), it is a common thing for a sound designer-composer to learn/use programming tools (like Unity or FMOD) to be able to implement-test audio myself during the development?

I already have an answer that is pretty much straight forward and the answer is YES. balancing volumes between GUI sounds, background sounds, music and other audio events are crucial elements that need to be handled by the audio guy to fine tune his idea before submitting, having a trained ear and mostly being aware of critical listening. Also seems reasonable to me that having access to the code (audio part only) it'll make it easy to swap files, test different solutions in context..

delegating all these tasks to the lead programmer doesn't sound right to me.

Also it makes dev more complicated and longer since there's this ball pass between the lead programmer before the audio guy can actually hear things in context.

been working on 4 games so far and it doesn't seem it is a common practice. the lead programmer was in charge to do all these things. I will actually start learning these implementing tools

but I'm curious to know how it usually works in general so far.

thanks!!

Improve this question

6 Answers 6

Reset to default
2

Apart from regular tools (DAW, audio editor etc...), it is a common thing for a sound designer-composer to learn/use programming tools (like Unity or FMOD) to be able to implement-test audio myself during the development?

It's not common, because game (and sound) programming requires a certain level of experience in programming to make the person effective in writing code. You'd need to double yourself as a decent programmer for it to be effective for you to write code as well as create sound. Your primary job is to create music and/or sound and to specify its in-game behaviour at some level (usually using tools like FMOD, Wwise etc.).

The sound person rarely does the actual audio calls or procedures, because doing that requires understanding of how the game code is structured. The sound person may be required to write short scripts (that may have a custom, simplified syntax or that may be in an actual programming language e.g. Python, Lua, C# or a markup language e.g. XML) that specify which sound file plays and how it plays when a certain audio event is called from the game code. The scripts are then linked to the game code in some way. The scripts are short and simple and learning to write them, when they're needed, shouldn't be a problem, but knowing the basics of imperative (or object-oriented) programming in some programming language helps and should make different scripting syntaxes and styles very easy to grasp.

If the game developer uses an audio middleware (e.g. FMOD, Wwise) or a framework (e.g. XNA) that has a separate "designer" program or view for audio, then you usually don't need to write anything, because everything that you need to handle is handled via the graphical "designer" program that basically works just like any other program.

If the game uses/is built on a very sophisticated framework that has graphical tools for navigating and editing the entire game build (effectively this is kind of how Unity works), then the sound person can usually adjust the sound and navigate and test builds quite easily.

I already have an answer that is pretty much straight forward and the answer is YES. balancing volumes between GUI sounds, background sounds, music and other audio events are crucial elements that need to be handled by the audio guy to fine tune his idea before submitting, having a trained ear and mostly being aware of critical listening. Also seems reasonable to me that having access to the code (audio part only) it'll make it easy to swap files, test different solutions in context..

Remember that every person has ears and most people listen to music and other audio. Anyone is as informed (if not just as experienced) as you to make a decision or to form an opinion regarding sound.

delegating all these tasks to the lead programmer doesn't sound right to me.

I'd say it depends on who does most effectively what needs to be done. If everything is handled via code, then it's easier to just do it, than try to teach someone who doesn't know how to program to program the audio. If you did know what to do, then wouldn't you be programming those audio procedures already?

Also it makes dev more complicated and longer since there's this ball pass between the lead programmer before the audio guy can actually hear things in context.

That's true and it sucks from audio's part, because audio needs to be worked and listened "in real time" to make decisions and having to wait to hear what you've done is a suboptimal practice. The solution is to use a tool/middleware that allows the sound person to work on the sound and test it independently or almost independently.

been working on 4 games so far and it doesn't seem it is a common practice. the lead programmer was in charge to do all these things. I will actually start learning these implementing tools

All learning is good, but depending on what you mean by "learning these implementing tools" you may be taking quite a plunge. Learning to program in a programming language (especially in a complicated language like C++) and to read code, when you're exposed to it for the first time, is hard enough for starters and it'll take a while until you can advance to understanding audio middleware libraries for example. I'm just warning that it'll be complicated and it'll take time to grasp, so be prepared to put the time in.

Improve this answer
8
  • thanks for you insights! "depending on what you mean by "learning these implementing tools" to narrow it down, I only mean 2 features: - being able to implement files (so you can test them in context) - being able to mix them (aka volume) I still think that investing a reasonable amount of time on these 2 features only - by sucking out some work time from the lead programmer' schedule to instruct the audio guy - might be a HUGE time saver in the long run. I usually work with small teams and there's only one, super busy lead programmer. other insights welcome ;)
    – Dollosyntax
    May 28, 2013 at 12:56
  • 1
    @Dollosyntax You ought to consult the programmers about that, because it depends on what tools/libraries the game uses. For integrated game engines (Unity, UDK etc.) you can access all audio parameters from the game editor and if the game uses FMOD or Wwise then you set the parameters using their graphical "designer" counterparts (e.g. FMOD Designer). If the game only uses programming libraries, then those parameters can be set directly in code or by using scripts (if the programmers have implemented handling of the scripts), which you can write. But ask the programmers, they know what to do.
    – Internet Human
    May 28, 2013 at 15:00
  • @Internet Human thanks again for your thoughts I will investigate on this. I feel there is space for improving the workflow making it smoother, faster and more enjoyable for both sides. The goal would be to improve this line: "That's true and it sucks from audio's part, because audio needs to be worked and listened "in real time" to make decisions". my bet is that it could be a reasonably easy fix: since the beg, the lead programmer creates few specific scripts to accomplish implementation/file swap + volume management and make them ready for the audio guy to have access to.
    – Dollosyntax
    May 28, 2013 at 16:24
  • these two, as far as my experience, have always been what I've badly missed during the dev. and also thought that, in proportion, the time spent on creating those scripts and instructing the audio guy VS the time spent on passing the ball between the audio guy and the programmer, the latter would much probably be much longer, time consuming and less precise work (and less fun) from the audio guy. That's always been my suspicion.
    – Dollosyntax
    May 28, 2013 at 16:32
  • @Dollosyntax It depends on whether the programmer's know how to (and want to) implement scripts for their game and tools though, because I'm not sure if there are some general guidelines for scripting pipelines. Some prefer to write whole graphical editors for the game or parts of it to make e.g. level editing easier. All of this gets quite involved depending on what the game is built on and what is required from the scripting interface and how the builds are managed, so again, the programmers ought to have ideas for how to solve your problem, if they aren't using middleware or...
    – Internet Human
    May 28, 2013 at 16:57
0

At the dev studio where I work it's pretty much like that.

We use Wwise with a proprietary game engine that has a pretty powerful node-based scripting tool akin to Unreal's Kismet and a very GUI-driven workflow so it's pretty accessible for our sound designers to implement sounds autonomously without having to rely on programmers all the time.

However we still do rely on programmers to code us sound hooks for situations that can't be scripted out (AI, systemic stuff, physics etc.).

Improve this answer
0

I illustrate why only implementation - volume tweak should be an imperative skill for me (at least the way I've always experienced so far) What happens to me is that, say, I'm working on the GUI .. I render the sound at the correct loudness for an SFX and send them to the programmer to be implemented. This is why I've added the word "mixing" to the title: I'm also a sound engineer and to me it's pretty much like mixing a song..you record all the tracks at their correct volume and the you mix them. and most of the time you'll spend time lowering the volume of lots of tracks to make the "sit in the mix" and blend things beautifully and correctly

Back to the videogame world, once the programmer has those sounds he has to set the correct volumes to blend those GUI sounds perfectly with the rest (ambience, music, other SFXs etc..). But they need to be quieter for sure so he's in charge to do find the sweetspot. And finding the sweetspot doesn't require just a good ear: it requires a well trained ear, and also trained to listen critically..and it requires time..and it's so important since an SFX with a "wrong" volume won't tell if it works or not.. it just sounds wrong... and every attempt that needs a minor tweak is a new build to be baked and uploaded for me to test...and this has always sounded like a huge waste of time, if only I had the chance to set them myself in first place..

This can happen with everything else, as long as there are multiple audio assets to be blended/mixed together.

Again, this is what Iv'e experienced on all 4 games I've been working on and it's something I strongly feel can be improved.. by simply learning those 2 features only:

  • being able to implement sounds in the build
  • having access to the volume for every sound

so that you can test audio in context...which equals better overview, better judgement, better, quicker workflow = everyone's happier. no doubt.

In this last project I'm working on, I pushed this thing up and now I got access to them and I'm able to work on the build. I'll see if it improves the workflow the way I suspect.

Improve this answer
3
  • "Learning these features only" is not straightforward. If you're an audio guy, then chances are that you're jumping from project to project and game studio to game studio, the tools, game engines and people change all the time. You can and should know the common middleware (practically Wwise, FMOD and maybe Unity/UDK/XACT if you think you'll work with those) tools to be ready to use them, when they're available. But you can't know what everyone is using and the programmers always know their own tools the best. If there's an in-house developed audio tool, then you'll be instructed about it.
    – Internet Human
    Jun 4, 2013 at 9:39
  • FMOD and Wwise (and other game audio tools) were essentially developed in order to allow the kind of flexibility that you descibe for the audio team (and free programmers from the mundane task of audio file handling), but the problem is, they are expensive to utilize and so you won't see them everywhere.
    – Internet Human
    Jun 4, 2013 at 9:47
  • @Internet Human I get your point. Taking in consideration all the variables (tools, engines etc...) from project to project/studio to studio is correct. but, no matter the tools, I'd still think about asking the programmer to make these 2 features available for the audio guy in whichever platform he's using. Of course whenever this is actually realistically possible. If it's not, then, yeah .. we do the best we can with what we have as usual :)
    – Dollosyntax
    Jun 4, 2013 at 21:21
0

These are two very different things. It is like it belongs to a different area or level of expertise. One cannot overlap the work of another so it is best to designate different people for the tasks.

Improve this answer
-1

Please don't start adding tasks like this to our job description . We have enough of a work load as is . I don't want to have to go back to school just so I can absorb more responsibilitys in the process. Every other department has 20-30 people in it . Audio / music department has THREE and one of those us a producer !

Improve this answer
0
-2

@Origami Audio

Sounds like your team could use more people...what kinda project are you on?

Improve this answer
2
  • Use comments .
    – Internet Human
    Jun 1, 2013 at 9:57
  • I would've, but there wasn't the option to use it. imgur.com/B5ZfP3e Someone enlighten me?
    – adsr
    Jun 2, 2013 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.