Чем отличается разработка игр от разработки «обычных» ИТ-проектов

Генеральный продюсер компании AminiLab Илья Пшеничный, занимающийся разработкой игр последние 13 лет, написал для колонку о том, в чем разница между разработкой в «обычных» ИТ-компаниях и в игровой индустрии .

Разница в том, что делаем

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

В играх ситуация отличается кардинально. Причина кроется в том, что игра должна приносить сложноформализуемое понятие Fun. Причем этот Fun она должна приносить огромному (чем больше, тем лучше) числу людей. Сравните формулировку «С помощью нашего приложения пользователь должен иметь возможность забронировать номер в гостинице» и «С помощью нашего приложения пользователь должен получить удовольствие».

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

We have to be predictable — сказал мне один топ-менеджер Electronic Arts, и это — чистая правда. Каждый день опоздания с выпуском игры может стоить вам десятки миллионов упущенной прибыли или уходящего впустую маркетингового бюджета.
Совмещение несовместимого — неопределенности результата с его предсказуемостью — накладывает отпечаток на производственный процесс.

Классический цикл производства вплоть до запуска игрового проекта выглядит таким образом: Idea Generation, Pre-production, Production, Finaling. Эти стадии отличаются составом команды, артефактами и даже подходом к управлению. Если на этапе Pre-production вполне уместна гибкая разработка, то на этапе Production лучше использовать классические методологии.

Основной принцип — раннее прототипирование. Все, что вызывает вопросы, должно быть реализовано как можно раньше. Это заметно снижает цену ошибки. При этом понятие «раннее прототипирование» надо рассматривать достаточно широко. К примеру, делаем игру типа Diablo. В игре есть риск — получить неинтересную боевку. Для того, чтобы оценить эту самую интересность, надо очень много вложиться в production — надо, чтобы был готов персонаж, чтобы были готовы враги (желательно несколько разных), чтобы была настроена обратная связь — визуальные и звуковые эффекты, чтобы был сделан HUD, чтобы была сделана система ревардов. Причем все это должно быть сделано на уровне качества, близкому к финальному, иначе в комплексе не оценить. Поэтому «раннее прототипирование» — это и alpha-beta-версии, и soft launch.

Разница в команде

В «обычных» ИТ-компаниях, занимающихся разработкой хоть b2b, хоть b2c софта, привычный состав проектной команды примерно таков:

менеджер (зачастую, он же и product owner);
аналитики;
тестировщики;
программисты;
UI-дизайнеры.

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

Рассмотрим, для примера, игру типа Clash of Clans. Для производства этой игры потребуются:

продюсер или менеджер-проекта (хотя зачастую эти роли разделяют, и не зря);
гейм-дизайнеры (в разработке оригинального Clash of Clans гейм-дизайнеров не было, но это скорее исключение);
команда маркетинга (да-да, на стадии разработки);
хорошие математики для подсчета баланса (могут быть включены в команду гейм-дизайна);
2D концепт-артисты для отрисовки всех игровых элементов;
3D моделлеры для моделирования игровых объектов (хоть игра и 2D, зачастую дешевле отмоделить все в 3D, а потом делать в Maya или 3D Max скриншоты этих моделек в нужных ракурсах);
аниматоры — 2D или 3D, в зависимости от выбранной технологии;
художники по спецэффектам;
звукорежиссер или звукоинженер;
технический художник — человек, который собирает воедино труды всех художников и моделлеров в игровую сцену, коммуницирует с программистами;
тестировщики;
наконец, программисты (клиентские, серверные, на тулсет и аналитику).

Конечно, для конкретного проекта позиции эти могут совмещаться, пересекаться или вообще отсутствовать, но в среднем как-то так.
Уже по этому перечислению понятно, что, во-первых, программисты далеко не самая многочисленная когорта в коллективе — в среднем 20% от всей команды, а во-вторых, и это, пожалуй, главное — команда состоит из очень ментально разных людей. Всем им надо работать вместе, и это очень непросто.
Как правило, все они замечательные люди, но друг друга совершенно не понимают. Таким образом коммуникационные проблемы — одна из основных особенностей игровых команд.

Мне приходилось сталкиваться с ситуациями, когда художники с программистами не общались никак, а гейм-дизайнеров ни те, ни другие вообще за людей не считали.
Ситуация усугубляется тем, что менеджер обычно вырос из какой-то одной из областей (арт, гейм-дизайн, программирование) и имеет ту же самую «родовую травму» в коммуникациях (автор материала, что греха таить, тоже).

Коммуникационные проблемы — одна из основных особенностей игровых команд.

Однозначного рецепта, как быть, тут нет. Но общие рекомендации такие:

Ничего не делать не получится. Не стоит надеяться, что все организуется само собой, потому что люди, де, адекватные каждый по отдельности.
Основа основ — неформальное общение и горизонтальные связи. Методологии типа FDD (адаптированной), понятие «игровая фича» и ее владелец — очень важные возможные способы, но основное, что надо стараться делать, — всеми доступными методами провоцировать общение между разными специалистами. К таким методам не в последнюю очередь относится правильная рассадка людей в офисе, а именно — люди, которые должны коммуницировать между собой, должны сидеть рядом. И не беда, если получится, что программист сидит ближе к художнику, чем к другому программисту.
Формальные методы. Их успешное применение может привести к тому, что они станут не нужны, но на первых порах они обязательны. К ним относятся собрания, в которых принимают участие специалисты из разных областей, статус-апдейты в почту и многое другое. Ежедневные и еженедельные собрания лидов, спонтанные собрания людей, работающих над одной «фичей» и прочее.
Сильный лидер. Его задача — формирование в коллективе дружественной атмосферы.
Тим, простите, билдинги.
Ну и не бойтесь увольнять. Бывают такие крайние ситуации, когда надо уволить даже сильного специалиста, просто потому, что он делает отношения во всем коллективе просто невыносимыми.

Разница в подходе

Игра, в особенности если это своя игра, а не заказной проект — это круто. Это то, о чем мечтало большинство разработчиков в детстве, играя в Doom, или художников, играя в Far Cry и WoW. Но еще это и бессонные ночи, это кранчи, это выходные, проведенные на работе. Причем «добровольно и с песнями».
Кранч в игровой индустрии — это не исключение, это правило. И с этим ничего нельзя поделать — из-за той самой неопределенности результата, о которой мы говорили выше.
Позволю себе еще одну цитату: «Если вы думаете, что сможете работать по 8 часов и без кранчей — вы пришли не в ту индустрию».
Это правило не всегда применимо к другим IT-проектам и другим IT-специалистам.

Разница в культуре разработки

Как ни странно, уровень применения обычных инженерных практик, таких как continuous integration, automated testing, да и вообще тестирование, а иногда даже и просто использование системы контроля версий, в игровой разработке достаточно низок.
И тому есть причины.

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

К примеру, скрестить Jenkins и Unity — задача решаемая, но не совсем простая. Что уж говорить об автоматизации тестирования.
В силу этих причин те процедуры, которые можно встретить даже в небольших ИТ-компаниях, в игропроме применяются только в больших корпорациях, да и то не во всех, особенно в России. Эта недооценка, кстати, вызывает взаимное чувство у профильных специалистов (билд инженеров, QA), которые не хотят идти в игропром, где их не будут ценить и будут мало платить.

Разница в технологиях

Игра — сложный и комплексный технологический продукт. В текущих реалиях, как правило — клиент-серверный. Если повезет, то высоконагруженный. Иначе говоря, все эти миллионы треугольников, разваливающиеся на куски дома и сотни тысяч взаимодействующих друг с другом CCU — это все технологически очень сложная задача. Да, и все это происходит в режиме реального времени.

Можно без преувеличения сказать, что игры во многом — на переднем крае технологий.
У этого есть и обратная сторона — тут не любят, да и просто нет возможности использования «высокоуровневых» техник. Начиная с модных языков программирования (до сих пор самый востребованный язык программирования в игропроме — С++), заканчивая даже такими вещами, как использование стандартной библиотеки или специфических алгоритмов и структур данных.

Разница в результате

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

Тема эта очень холиварная и зачастую непростая для понимания даже опытных разработчиков и менеджеров. Я не призываю писать плохой код, не призываю не придерживаться заведенных практик, но всегда помните о цели. Иногда цель «в дальнейшем будет проще поддерживать» — ложная. Давайте делать хорошие игры, а не хорошие библиотеки легкоподдерживаемого кода. То, что придется нанять 50 дополнительных индусов, чтобы выпустить вторую версию игры — не важно, если ваша первая версия заработает $1 млрд. Или 0,1% от этой суммы.

Давайте делать хорошие игры.