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

УМЕНИЕ СТРУКТУРИРОВАТЬ

Так как над игрой может работать много разноплановых специалистов, у них будут не только разные задачи, но и в целом разные цели. Разные вещи будут для них главными. Для программистов важно описание алгоритма поведения персонажа, для художников – описание его внешнего вида, для сценаристов – описание характера. Если мы сложим все эти описания в одну кучу, две трети информации для каждого из специалистов будут лишними. Поэтому описания должны быть разделены. Как? Есть много вариантов, каждый из которых имеет право на жизнь в зависимости от устройства команды. Тут-то и должны пригодиться коммуникационные навыки, чтобы узнать, какой именно метод структурирования данных будет наиболее комфортен для всех.

УМЕНИЕ ИСКАТЬ ИНФОРМАЦИЮ

Учитывая, что игры вообще бывают разными, для их разработки могут быть нужны разные знания. Если с точки зрения программирования все зависит от выбранных технологий, а с точки зрения арта – от выбранного стиля, то с точки зрения дизайна… все намного сложнее. Чтобы быть понятными, игры симулируют жизненные ситуации и моделируют частички реального мира. Чтобы создать эту модель, эту симуляцию, нужно понимать, что именно мы симулируем: поведение автомобиля, взаимоотношение между государствами, управление футбольным клубом, процесс ловли рыбы, в конце концов. Соответственно, придется разобраться в типах наживок и блесен, в том, где какие рыбы обитают, чем они вообще отличаются по поведению. Без этих знаний модель получится слишком поверхностной, и целевая аудитория может не принять игру. Значит, знания эти придется искать и осваивать.

УМЕНИЕ ВИДЕТЬ КАРТИНУ ЦЕЛИКОМ

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

УМЕНИЕ ДЕЛЕГИРОВАТЬ

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

УМЕНИЕ СЧИТЫВАТЬ ОПЫТ

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

УМЕНИЕ ЗАДАВАТЬ ВОПРОСЫ

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

УМЕНИЕ ОБЩАТЬСЯ

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

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

Некомфортная рабочая обстановка – один из основных факторов, способных привести к выгоранию разработчика. Сюда относятся не только проблемы с коммуникациями в команде, но и переработки, и даже личные проблемы, которые могут мешать человеку полноценно отдохнуть, чтобы возвращаться на работу с новыми силами. Чтобы предупредить выгорание, необходимо общаться с членами команды, понимать их настроение, всем ли они довольны и нет ли у них проблем как на работе, так и вне ее.

Софтскиллы – это о том, как сделать атмосферу внутри команды максимально комфортной, а значит, эффективной. Разработчикам их работа должна доставлять такое же удовольствие, как игрокам – созданная ими игра.

Глава 4. Как делают игры

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

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

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

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

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

• Подготовка производства (препродакшн)

– Идея

– Концептирование

– Прототипирование

– Вертикальный срез

• Производство (продакшн)

– Горизонтальный срез

– Альфа

– Бета

• Релиз

– Поддержка

– Развитие проекта (если это предполагает его бизнес-модель)

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

Желаемым результатом