One man army или почему один в поле не воин

Иван Осипенко Статья 3 Comments

Выгорание

Photo by Peter Kraayvanger (pixabay.com)

Идея этой статьи долгое время крутилась у меня в голове, так как все «прелести» работы на крупном проекте в одиночку мне удалось прочувствовать на собственной шкуре. Надеюсь, что этот небольшой материал поможет спасти хотя бы пару заблудших душ от глупых ошибок и уменьшить количество суицидов на почве профессионального выгорания.

Один человек — армия

Для начала давайте разберёмся, что такое “one man army”. В дословном переводе — армия из одного человека. В игровой (да и не только игровой) индустрии таким жаргонизмом обычно именуют людей, работающих по нескольким направлениям одновременно. Например, какой-нибудь программист-геймдизайнер-продюсер-композитор.
В нашей сфере (звук и музыка, если вы забыли) выделяют следующие направления, которые частенько любят «совмещать»:

  1. Создание ассетов. Производство непосредственно самих звуков в виде аудиофайлов.
  2. Написание музыки. Речь может идти как о линейной музыке, так и о наборе ассетов для интерактивного саундтрека.
  3. Имплементация и интеграция как звуковых ассетов, так и музыкальных.
  4. Контроль качества аудио (Audio QC). В том числе, поиск аудио багов.
  5. Сведение. Создание чистого микса, удовлетворяющего требованиям той или иной платформы.
  6. Работа с голосом. Запись актеров озвучивания и обработка записанного материала.
  7. Управление производством аудио. Планирование, бюджетирование, контроль сроков и прочие управленческие задачи.

На небольших проектах объём работы зачастую невелик, и можно без проблем выполнять все перечисленные задачи в одиночку. В случае же средних и крупных проектов, очевидно, что тащить все эти направления на себе не совсем правильно.

Один в поле не воин

Поначалу может показаться, что у такого положения вещей сплошные плюсы. Ты — сам себе начальник, контролирующий как заказ, так и исполнение. При этом контроль со временем улетучивается, а его место полностью занимает всепоглощающий перманентный хаос. Что, в свою очередь, влечёт постоянное перенапряжение, кульминацией которого выступает выгорание — состояние катастрофического падения работоспособности, чреватое рядом психологических проблем.

«Но ведь главное, что продукт на выходе получится первоклассный», — скажете мне вы. Нет, не получится. С таким мастерством многостаночника итоговый материал пострадает по каждому из направлений либо количественно, либо качественно.

Что же может пойти не так?

Пройдёмся по всем вышеописанным областям

  1. Создание ассетов. Если послабление пойдёт по этому направлению, вы либо не успеете к дедлайну и завершите проект с откровенно “дырявым” материалом, либо будете успевать, но начнёте халтурить, снижая качество в угоду экономии времени.
  2. Музыка. Эта область обычно вызывает меньше всего проблем ввиду того, что даже на малых проектах музыкой часто занимается отдельный человек. Но не исключена и ситуация, когда за месяц до релиза вы вспоминаете, что вызвались написать музыку для игрового процесса и главного меню. И теперь нужно хоть что-то родить с учетом того, что вы работаете над РПГ в средневековом сеттинге, а всю жизнь писали только rhythmic noise.
  3. Имплементация, интеграция и QC. Что же может пойти не так с интеграцией и поиском багов? Например, вы совсем не заметили, как пустили всю имплементацию на самотёк и запускали игру только в случае острой необходимости, так как хотели успеть всё сделать в срок. Вы надеялись, что в случае чего остальная команда вам сообщит о проблемах. Только вот неожиданно выясняется, что большая часть команды играет вообще без звука. В итоге вы запускаете предрелизный билд и постепенно начинаете седеть, слыша то пропадающие звуки, то рассинхрон войсоверов, то ещё какую-нибудь дичь.
  4. Сведение. Чаще всего этот процесс откладывается на потом, а когда это «потом» настаёт, уши уже замылены, а до дедлайна осталась неделя. Сами понимаете, какой микс у вас будет в итоге.
  5. Голосовое озвучивание. Типичный пример: вы вовремя не нашли всех актеров, и либо половина реплик осталась неозвученной, либо персонажи говорят одним и тем же унылым голосом, который вы записали на карманный рекордер дома под одеялом.
  6. Управление процессами. Из-за отсутствия документации легко не заметить или забыть, что «вон тому персонажу надо бы было добавить несколько звуков, которые появляются ближе к середине игры». Или же вы половину своего времени тратите на составление задач и взаимодействие с другими отделами, не успевая выполнять основные задачи.
    Помимо прочего, о драматургии и эмоциональном повествовании звуком можно будет забыть. Мозг будет настолько забит решением вышеперечисленных проблем, что вы окажетесь не в состоянии подчеркнуть звуком напряженную сцену или даже создать стоящий ассет.

После осознания масштаба проблемы нередко начинает вылезать рационализация:
«Надо потерпеть. Поработаю пару лет в таком режиме до выхода проекта, а потом и начну искать команду». Только вот подобная «мотивация» не приносит ничего кроме ещё большего вреда. Если вы и не слетите с катушек до релиза, на старте следующего проекта вам, вероятно, скажут: «Ты же до этого один справлялся, зачем тебе ещё люди?»

Как с этим бороться?

Ответ на этот вопрос очевиден: искать помощников. Очевидно, что новые кадры нужно искать, опираясь на ваши «пробелы». Поэтому в первую очередь необходимо выделить свои слабые стороны. Например, у вас вечные проблемы с поиском актёров, или вы не разбираетесь в скриптинге даже на начальном уровне. Именно такие требования и нужно предъявлять к будущему коллеге.

Совсем не обязательно сразу искать нового штатного сотрудника. Для затыкания ваших “дыр” есть и другие варианты. Например, доверить производство ассетов, музыки и голосового озвучивания какой-нибудь аутсорс студии. Или просто посмотреть у себя под боком. Например, практически нереально выбить у начальства позицию аудио тестировщика, но при этом не исключено, что в вашем отделе контроля качества найдётся человек, заинтересованный в звуке. В итоге можно договориться, что баги, связанные со звуком, будут иметь для этого человека наивысший приоритет.

Аналогичная ситуация и с имплементацией/интеграцией. Если у вас за стенкой сидит скриптер, написавший пару синтезаторов на C++, он будет только рад поддерживать звук на проекте.

Наконец, если вы решились расширять команду, готовьтесь писать очень много технической документации, особенно если раньше вы этого не делали. Поначалу это покажется вам адом. Но поверьте, лучше один раз сделать несколько табличек и документов, чем нянчиться с каждым новым напарником по одним и тем же вопросам.

На этом, пожалуй, все. Надеюсь, статья оказалась для вас хоть чуть-чуть полезной и вы смогли сделать для себя нужные выводы. Если возникли какие-либо вопросы, то можете смело задавать их в комментариях.

И последнее, не забывайте отдыхать!

___

Иван Осипенко — старший саунд-дизайнер (Saber int.), искренний фанат процедурного звука и технического саунд-дизайна.