Risk in Sound Design

Caught up with one of my old colleagues a week ago and we inevitably got to talking shop.  The sound design scene in Australia feels very small sometimes so any opportunity to exchange thoughts and tips is always eagerly seized upon.

One thing we were talking about which gave me some good food for thought was the role of risk in creating stand-out sound design.

The ultimate challenge for a sound designer is not merely being a good sound designer, but a great sound designer.  And the thing that separates the two is more often that not the one who takes the risk.  There is the way that you know will sound 'right' - the sound and mix that you are certain will work, because it's tried and true and audiences have been trained to accept it.  I think there's a lot of merit to this approach, because sometimes the audio isn't there to be the star, and all you need is something safe and functional.  There's a common saying in sound design, which is 'if you've done your work right nobody will notice it'.  Also known as 'bad drummer syndrome' - you only notice the drummer in a band if they're bad.

However, if this is all you do, you run the risk of falling into being a 'good' sound designer instead of perhaps a 'great' one.  This is where the risk comes into play.  It's the work which does something different that is most often remembered.  The one which chose a novel approach to the mix, which maybe chose unusual sound effects for mundane objects, which pushed the envelope of originality.  Creativity and originality are traits which are often lauded in the sound design profession, but I think it's far better to describe these traits as 'risk-taking'.

Thinking about it in regards to game audio, I think this can manifest most strongly in implementation.  When technical factors become involved, it's very easy to choose the easier solution, the one you know will be implemented correctly and will work and sound right.  But in doing so you often throw away the opportunity to go one step further and do something really impressive.  It's a trap I've often fallen into in the past, especially on projects when I've been frustrated with a lack of code support and so will reach for the basics first and only then try and reach for more ambitious implementation.  While this is a good approach in theory - you have the safety net of at least being able to do the bare necessities - in practice it's more likely the most basic option is the one you will eventually end up with.  It's a far better bargaining position if you reach for the most ambitious option first, and if necessary then work your way down.

Of course, the biggest issue with taking risks, is that sometimes you will fail.  You have to be prepared for that, too.  But just like investment, the biggest risks can also pay the biggest dividends when they work out.

Anyhow, there's a bit of what's been occupying the stream-of-consciousness the past week.