Лого vc.ru

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

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

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

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

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

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

0

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

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

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

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

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

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

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

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

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

0

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

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

0

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

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

0

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

0

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

0

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

0

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

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

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

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

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

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

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

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

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

0

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

0

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

0

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

0

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

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

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

0

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

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

0

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

0

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

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

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

0

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

0

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

Почему?

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
FrostBite
ProGamer.ru

Всем. Я за нацию технологий и творчества.

Власти России намерены снизить беспошлинный порог для ввоза интернет-посылок до 500 евро с середины 2018 года
0
Alex Samoylenko

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

Mushroom Wars 2: рассказ российских разработчиков о том, какой путь прошла игра от концепта до релиза
0
reggaejunkiejew

так в том и вопрос, в статье вообще не сказано чего они там такие умные и красивые настартапили и на антрепренировали.

Дом, который построил Питер Тиль
0
Anton Kuchumov
WorkOut

Спасибо, из всего списка как раз хотел начать с неё.

Лучшие книги 2016 года — выбор Билла Гейтса
0
Artem Korsunov

Конечно, их же уже купил Фитбит

Производитель «умных» часов Pebble объявил о своём закрытии после сделки с Fitbit
0
Показать еще