- November 20th, 2016, 9:28 am #2581
If you’re making a car game with 1000 cars, how are you going to maintain the audio for that, in terms of consistency, quality and feel? If you make one car a day, then by the 1000th day, your idea of what a good car sounds like will be totally different from when you started, so you’d have to retackle your initial cars to bring them up to the new level of quality and direction that you applied to your 1000th car model. To handle this at DICE , we have implemented hierarchical systems, based on parent and child patches. For example, in a first-person shooter game, we could start with a parent “Weapon”, and that might split into an “Automatic” and “Non-Automatic”, and “Automatic” might lead into an “SMG”, an “Assault Rifle” and so on. If at a later stage we want to add a “Silencer” or maybe a filter to all our weapons, we could add it at the parent stage, so that it then propagates down through the generations to all the children patches. Previously, without this workflow, this could mean that we would have to individually add the functionality to each child patch or create a whole new series of unique patches, which is of course time consuming and error prone. When designing new core systems, we now utilize the power of inherited configurations and shared content. As an example, whilst the initial “bang” of a pistol could sound unique and be made from a unique sample set, the tail and reflection could be shared and be commonly used amongst a group of similar pistols. This reduces the initial amount of work needed to be done and the time needed to maintain such systems, whilst maintaining a consistent feel and sound to the patches within that family, and when it’s time to add additional content via updates or DLC, you just need to add the new unique elements and logic for a specific item, since the default core elements already exist and can be reused.
To be honest, if you’re already doing sound design today, then you are already probably very tech savvy. Most game audio academic courses have a fair degree of technical studies in there. So, it’s not unreasonable to expect applicants to know the basics. We’re not going to ask someone how well they know Frostbite. It wouldn’t make any sense, since it’s a proprietary system that we don’t share with anyone outside of EA, but it’s not always about hard skills. If someone comes for an interview at DICE and has a ton of knowledge, but is competing against another person with half the knowledge that comes across as a better team fit, I’d go with the latter person. You can teach people technical things as long as they’re open to learning, whereas fitting with an existing team is not something you can necessarily learn or even teach.