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

Генеральный продюсер компании 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% от этой суммы.

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

0
42 комментария
Популярные
По порядку
Написать комментарий...
ObliQ Brutale

зачОтно. все именно так и обстоит. прочитал-понравилось

Ответить
5
Развернуть ветку
Lev Lybin

Хорошая игра — важно. А хороший код — простите, но нет

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

Ответить
2
Развернуть ветку
Илья Пшеничный

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

Ответить
1
Развернуть ветку
Виталий Кривошапкин

Тут можно было сказать иначе так:

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

Ответить
0
Развернуть ветку
Владислав Козуля

Очень грамотно описано. Издержки на создание простенькой игры гораздо выше, чем на создание очередного хипстер-сервиса.

Ответить
2
Развернуть ветку
Павел Губарев

Приятно читать -- внятно и красочно изложено. Спасибо!

Ответить
2
Развернуть ветку
Danila Maltsev

а про сценаристов опять забыли )

Ответить
2
Развернуть ветку
Илья Пшеничный

Внесем их в группу гейм-дизайнеров, ок? :)

Ответить
0
Развернуть ветку

Комментарий удален

Развернуть ветку
Maxim Syabro

Конкуренции нет, если сравнивать с обычным ПО.
У вас есть один гмайл, одна ОС, один календарь, одна ЦРМ, один сервис для бухучета. У очень малого количества ниш есть чего-то по два (в основном месенджеры и соцсети).

У игр, если игра хорошая, то ее купят и позже, когда пройдут ГТА 5.
Тут конкурент это конкурент на неделю.

Ответить
1
Развернуть ветку
Sergey Babaev

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

Ответить
1
Развернуть ветку
Maxim Syabro

Если вышел гуглдокс а сразу за ним другой гуглодокс, то уверяю у второго шансов еще меньше.

А ко второй игре можно вернуться чуть позже или отложить релиз на чуть попозже.

Ответить
1
Развернуть ветку
Sergey Babaev

в этом плане вы бесспорно правы, если проект направлен на решение задачи (а не развлечение) - то у него с конкуренцией все сильно сложнее

Ответить
1
Развернуть ветку
Maxim Syabro

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

PS Я не беру в расчет CoC или Boom Beach — я в ф2п не понимаю, поскольку не ЦА. Я скорее про приставки и стим.

Ответить
2
Развернуть ветку
Sergey Babaev

ритейловые издатели не согласятся с вашим подходом к конкуренции)

Ответить
0
Развернуть ветку
Илья Пшеничный

Виталий, статья больше про сам процесс разработки, а не про бизнес в целом.
А если про бизнес - то геймдев, для большинства участников, все еще лотерея. К счастью, есть исключения.

Ответить
0
Развернуть ветку
Алексей Сотников

Вообщем-то если фантазия есть, то можно самому создать очень крутую игру, а когда в компании работаешь, то хоть у тебя и будет фантазия, но она ни кому не будет нужна, ведь все идет по ТЗ и по плану.

Ответить
0
Развернуть ветку
Charnaus Vlad

Очень поверхностное утверждение

Ответить
3
Развернуть ветку
Владислав Козуля

Брр. Вы точно занимаетесь играми?

Ответить
1
Развернуть ветку
Kirill Nadelyaev

чувак просто ведёт блог про игру Rust, он не её разработчик и даже не тестер :)

Ответить
1
Развернуть ветку
Sergey Babaev

думаете бейдж ошибочно выставлен юзеру как разработчику rust? я что-то даже не подумал что речь может быть об этом, подумал о каком то другом расте)

Ответить
0
Развернуть ветку
Kirill Nadelyaev

Я, честно говоря, не знаю как здесь бейджи выдаются. Увидел Rust - подумал человек из команды разработчиков или маркетинга. Но если кликнуть по этому самому бейджу, то можно попасть на крайне скромный блог по игре Rust с форумом из пяти сообщений. К разработке игр это конечно не имеет никакого отношения.

Всё равно, что я сейчас блог по half-life 3 забубеню на WordPress и радостно припишу его рядом с именем :)

Ответить
0
Развернуть ветку
Алексей Пименов

Ваша фантазия и реалии рынка могут быть осень далеко друг от друга.

Ответить
0
Развернуть ветку
Sergey Babaev

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

Ответить
0
Развернуть ветку
Sergey Babaev

из крутых одиночек я назову пожалуй Сергея Носкова, да Кирилла (фамилию запамятовал), который в одного делает крутейший MOBA-шутер и собрал средства на KS.

Ответить
0
Развернуть ветку
Алексей Пименов

Ох как знакома проблема непонимания между членами команды тех/арт отдел. Потому считаю что мой рост в ГД из тех.дизайнера(скриптование/сборка сцен/нарезка текстур) дал очень хорошие возможности по налаживанию коммуникации между этими отделами.

Ответить
1
Развернуть ветку
Anthony Akentiev

Очень хороший текст. Спасибо.

Ответить
1
Развернуть ветку
Tom Andreevich Zarubin

Что такое обычный ИТ-проект?

Ответить
0
Развернуть ветку
Илья Пшеничный

Наконец-то :))
Только не обычный, а "обычный". Не бывает же, скажем, обычных музыкантов. Или программистов.

Ответить
1
Развернуть ветку
Tom Andreevich Zarubin

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

Ответить
1
Развернуть ветку
Tom Andreevich Zarubin

*..всегда есть и она очевидна..

Ответить
0
Развернуть ветку
Леонид Сиротин

Один вопрос - а проекты автора статьи можно увидеть?

Ответить
0
Развернуть ветку
Илья Пшеничный

Можно :)
FIFA Street (PS3, X360)
Sims 4 (PC)
Wheels of Destruction (PS3)
Smash Cars (PS3)
Wakeboarding HD (PS3)
Alone in the Dark (NDS, PSP) - не вышел, отменили
ATHF (PS2)
Coded Arms Contagion (PSP)
American Chopper 2 (PS2, XBOX, NGC)
American Chopper
Smash Cars (PS2)
Ну и по немногу - FIFA13, 14 и еще несколько
Это из игровых. Возможно, я что-то забыл

Ответить
0
Развернуть ветку
Tom Andreevich Zarubin

А ваша роль в них?

Ответить
1
Развернуть ветку
Илья Пшеничный

Снизу-вверх: программист, страший, ведущий, со-продюсер, продюсер, продюсер внешних команд

Ответить
1
Развернуть ветку
Tom Andreevich Zarubin

Зачот.

Ответить
0
Развернуть ветку
Леонид Сиротин

Я сорри, не очень в курсе, в мало что играл из списка - а что-то из этого фритуплей?

Ответить
0
Развернуть ветку
Илья Пшеничный

Good point :)
Думаю читатели скажут спасибо, и мы сможем заметно повысить качество материала, если вы дополните положения статьи, основываясь на вашем опыте.

Ответить
0
Развернуть ветку
Леонид Сиротин

Я просто уточнял для себя, потому что мне показалось, что в статье идет речь о законченной разработке коробочного продукта прежде всего. По сути о пайплайне изготовления контента. А фритуплей он не только про контент, он про то как "продать" контент и как сервис строить постоянно работающий - в этом его индустриальная уникальность.

Ответить
0
Развернуть ветку

Комментарий удален

Развернуть ветку
Иван Вербицкий

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

Ответить
0
Развернуть ветку
Илья Пшеничный

Варианты решения местами там предложены. Не для всего правда. Но тут каждая тема - отдельная большая статья.

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

Вы удивитесь :)

Ответить
0
Развернуть ветку

Комментарий удален

Развернуть ветку
Andrey Kostyushko

Хорошо все описано

Ответить
0
Развернуть ветку
Olga Grabovsky

"К примеру, скрестить Jenkins и Unity — задача решаемая, но не совсем простая. "

Почему?

Ответить
0
Развернуть ветку

Комментарий удален

Развернуть ветку
Читать все 42 комментария
Новый дизайн «Секрета фирмы» учтёт пользовательские сценарии потребления и поиска контента

О трендах бизнеса и экономики можно прочесть коротко и ясно в удобных форматах

«Комитет» объявил о планах продать сервис коротких видео Coub Статьи редакции

Компания, владеющая vc.ru, dtf.ru и tjournal.ru, планирует в ближайшее время найти нового владельца для проекта, сообщил на своей странице в Facebook сооснователь «Комитета» Влад Цыплухин.

«Если клиенты видят халяльный логотип, это придаёт им уверенности в продукте»: как устроен исламский банкинг в Индонезии Статьи редакции

Местные финтех-стартапы могут развиваться только после одобрения представителей исламского духовенства. Какие сложности преодолевают предприниматели, чтобы создать приложение по законам шариата, — в пересказе Rest of World.

Как выпустить заменитель соли на Boomstarter.ru и попасть в список Forbes

Сёстры из Астрахани запустили на Boomstarter.ru продажи нового продукта — зеленой соли. После этого их продукцию начали продавать в сетевых магазинах, а само бизнес-начинение журнал Forbes включил в список лучших стартапов.

«Купи сейчас, плати потом»: новая классика или мимолетная мода

Сервис рассрочек рассказывает о новом финтех-тренде.

Мощные сервисы для быстрого машинного обучения: от GPU SuperCloud до суперкомпьютера

В последние три года мы видим рост спроса на технологии искусственного интеллекта (ИИ) и машинного обучения. Они проникли практически во все сферы нашей жизни, начиная от различных колл-центров и городских систем видеонаблюдения, заканчивая системами медицинского скрининга и диагностики заболеваний. Даже для оплаты проезда в столичной подземке…

Кейс Таргет. Как привлечь 379 заявок на покупку мужских костюмов и предотвратить закрытие ателье

Как я за 4 месяца привлек 379 заявок по 350 рублей на покупку мужских костюмов при среднем чеке 80 000 рублей

Wildberries лично ответил на обвинения покупателей о вранье с платным возвратом. Мы провели блиц-опрос с площадкой
No-code подход в мобильной разработке: будущее или мелкая ниша?

Меня зовут Алексей Жилин, я основатель агентства мобильной разработки SMD Agency, а также сооснователь стартапа Wiby, размышления о котором и натолкнули меня на написание этой статьи. Wiby - это сервис, в котором рестораны и доставки еды могут получить нативное мобильное приложение с бэк-офисом и интеграциями с основными CRM этой отрасли для…

Как сделать работу компаний и фрилансеров удобной

С помощью сервиса «Рокет Ворк».

null