Hello all, long time lurker whose finally going to start contributing.

It occurred to me, after talking to a client yesterday, that one of the more important skills to develop is the ability to translate what the client has in mind into something tangible. I'm not referring to when a client produces a clear and concise brief, but to the occasions when (usually during feedback) they have a very specific idea in mind but can't express it without resorting to fairly odd descriptions like "Can you make it sort of shine and twinkle?" or "needs to feel more like its about to rip apart".

In those sorts of situations, it can sometimes be fairly easy to translate what the client is after (underwater might mean a LPF, more dirty might mean it needs more distortion) but occasionally I'll need to get my thinking cap on. I guess most of these situations arise where the client is visualising the music, so if possible I'll try to understand the context of the piece, or ask for examples of similar existing music. Failing that, I'll quickly brainstorm a couple of ideas and pass them over to see which is closer to what the client has in mind.

Anyone have any thoughts on this?

Mark

Yeah, describing music and sounds with words happens to be tricky and even misleading sometimes. Apart of collecting as much references and detailed informations I would connect it to "Music Costs" thread too. It is because searching and experimenting with the sounds is an inherent part of creating audio for a game. With enough time given (which is determined by budget of course) the results just come in the end of the work. I mean that's the part of it.

I imagine you're probably still better off just asking quickly what he means exactly, even if that ends up resorting into showing some examples or comparing to what other music does if words won't do it. Better to err on the side of caution with stuff like this if you don't want to waste time.

There's a blog post on AltDevBlog about this, called I want it to sound chocolatey

I think most everyone deals with loose requirements, or with feedback from people who clearly do not have the same vocabulary or frame of reference. Basically, very few people are able to communicate with those outside their own chosen bubble. Programmers and technical folks deal with this too.

Try to get the best, most-concrete requirements you can, get some idea of what the ambiance should be, and do your best detective work to suss out details that the client/whatever doesn't realize are important. Beyond that, communicate with samples--mock-ups, if you will--and get feedback early and often. Don't pour a ton of work into anything that you don't know for certain is right. Fast iteration can be your friend here.