Working in a development that consists of different teams is already difficult, but having an audio team adds additional complexity. The basis of this complexity is educational and cultural. On the one hand, it’s educational because training centers don’t do the best job of educating how important this branch is within a development: what it consists of, what the options are, how to get a professional solid finish, how to work with people trained in this section etc. And on the other hand, it’s cultural, because the issue of sound is generally not considered that important by the developers. Having one or more sane people in a development is something the Spanish industry isn’t very far into at the moment (with exceptions proving the rule). In this post I’m going to talk a little about my experiences and give advice that may or may not be useful to ensure that working with an audio device ends satisfactorily.

The most common and widespread problem is, on the one hand, the developer’s distrust of the sound manager. It’s really too complicated to convince a team to use middleware in the project. The audio middleware is a fantastic tool with absolutely professional options which, when used correctly, will ensure that the game has a professional and high-quality sound finish.

But usually the audio team is not the one who decides which technologies to use. Usually the programming team is the one who decides on the tools to use for the sound and it should be noted that in all the cases where this has happened to me it is not because the programming team knows about these tools, but rather due to mistrust arose from ignorance of this technology.

For example, recently it happened to me that a team of programmers insisted that I couldn’t use Wwise in the project “so I wouldn’t touch anything I shouldn’t” (text words). Of course, the programmers heard about Wwise for the first time. A similar simile (not exactly the same, but it can be used to put things in context) would be like me, a music composer and sound effects designer, telling the artist that he can’t use Photoshop or Illustrator and that he can use Painter must use, for example, no matter what the artist thinks. Something absurd.

The middleware is a marvel of technology that is free to use in stand alone developments and allows the sound crew to get the best out of themselves and what is also important to develop professionally. My advice on the matter is this: if a development team decides to work with an audio person or people, listen to their suggestions and know how to tell them about their personal opinions (which are usually 99% ignorant). ) can consider cases) because they can save themselves sound programming work (the implementation is done by the appropriate sound person), they will encourage the designer and/or composer to work on their possibilities in a trusting environment and they will be able professionally to grow because they will learn new things with each development.

Unfortunately in Spain it is technically very easy to hit a ceiling in development as we are usually denied many job opportunities. If you have a person (or people) with experience in clay, training and knowledge of the tools that could make a quality leap into the product, the best thing that can be done is to give them the confidence and reins needed to run the clay part of the Execution. . Or at least listen to them, don’t decide for them what to do.

This is to tie in with the following additional problem that is usually encountered in developments involving sound equipment. The studio usually doesn’t know where a sound professional comes from, they don’t know what they studied, how they know what they know and if they can really trust them. There are cases when the healthy person remains suspicious despite their experience. I have colleagues who had to modify something out of a sense of duty because the programmer had a friend who said it sounded loud, another even asked if the designer used compressors. And they were forced to change it following the advice (toxic, very toxic) of these third parties. And so it happened.

When you work with a solid person on a development, it’s because no one else on the team is qualified to do it with a positive end quality and at the level of the project.

At this point, there’s no point in downplaying the audio engineer’s opinion by giving it to a friend, family member, or another developer. They’re just opinions, and as Clint Eastwood said, “Opinions are like butts: everyone’s got one”. Getting feedback is essential in any development, but you can’t give the sound team’s decisions any more weight than it should, let alone without consulting them first. I recently found myself in a situation within development where the team had spoken to developers and others about sound (9.5 out of 10 of whom are not in the business) and had made a number of completely unbiased decisions in sound development without prior consultation with the sound team.

In conclusion, I recommend that you try to work with people who specialize in sound whenever possible. Not only because of the personal enrichment that comes with sharing a stretch of road with other people, but also because of the professional enrichment that comes with it. When working with a person dedicated to sound (or more) it’s best to consider them to make all decisions from the start, listen and value their opinion as one more. This will usually be an experienced person who knows what is best for the project in their area. And if he doesn’t have experience, it doesn’t matter, let him acquire it, we all want to improve.

On the other hand, if you don’t think that the sound engineer is someone who should stay out of development, please involve them in the process from day zero: let them familiarize themselves with the equipment, with the technology, let them see process he follows and participate in it. For example, if you have 5 months to work on a demo, don’t leave the sound department for the last 2 weeks or everything will go wrong. Very bad. Terribly bad.

Nor do you decide for him what is best for his work and the final quality. It hurts a lot to work on an elaborate sound design and see that the implementation is not right. The person making the sound should be the one implementing it, because that person is the one who has in mind how the game should sound and why they’re making that particular sound, not a programmer. And if he asks you to use middleware, please let him use it, as it not only makes things easier for him and the rest of the team, but also produces a far better end result. A game is an artistic work that usually consists of a series of contributions from different people. It is fundamental that everyone offers the best of themselves.