Чему современная школа продуктовой IT-разработки может поучиться у геймдева?
Взгляд со стороны IT продакт-менеджера на процесс разработки сложных компьютерных и консольных игр.
Процесс разработки сложных видеоигр радикально отличается от процесса создания продуктов в индустрии paas/saas решений, где на слуху такие слова как Agile, Customer Development, MVP и т.д.
В своей книге "Кровь, пот и пиксели. Обратная сторона индустрии видеоигр" Джейсон Шрейер заставит содрогаться от ужаса и кричать "Как так можно?" любого ярого Agile-адепта. В данном случае орудием пытки будет являться набор рассказов, основанных на интервью с создателями различных игр, начиная с тех, которые были созданы одиночками, запертыми в 4 стенах на 4 года (Stardew Valley; $ 21 млн заработанных в Steam), заканчивая ААА-проектами по типу Witcher 3 и Diablo 3, в создании которых принимали участие десятки и сотни дорогостоящих специалистов на протяжении до 10 (!) лет.
Уточнение от автора: Давайте сразу обозначим, что в книге и в данной статье не рассматриваются мобильные игры, различные free-to-play игры, а также DLC (дополнения) с помощья которых зачастую тестируют гипотезы. Автор в курсе, что перевод книги вышел неудачным, в интернете есть качественные статьи, громящий в пух и прах данный перевод, но сейчас мы не об этом.
Возвращаемся к теме.
На мой взгляд для начала стоит тезисно обозначить ключевые различия в подходах разработки двух рассматриваем видов IT-продуктов.
Примеры общепризнанных канонов paas/saas индустрии, в рамках которых осуществляется продакт-менеджмент:
1) Не тяни. Выпускай то, что есть, а в процессе либо закроешь, либо будешь доводить до ума;
2) Гипотезы чаще всего создаются и проверяются после релиза (ядро продукта и изначальная предпосылки основателей не в счёт);
3) MVP (минимально-ценный продукт) обычно разрабатывается и выкатывается на рынок за 3-12 месяцев.
В случае с геймдевом всё отличается на 180° (окей, на 170°):
1) Продукт прорабатывается до полностью готового состояния, только после этого выпускается на рынок;
2) Все гипотезы формируются и уходят в продакшн ещё на этапе разработки, на игроков за раз вываливается всё, что разработчики успели сделать и на что были способны в принципе;
3) На создание сложной и качественной PC/консольной игры уходит от 2 до 10 лет, после чего она в готовом состоянии выходит на рынок.
Причины столь радикальных отличий игровой индустрии:
1) 50% успеха игры заключается в маркетинге на этапе производства игры. Будущие игроки должны быть заранее заинтересованы в новом проекте.
2) В абсолютном большинстве случаев выпущенная игра большую часть денег зарабатывает в первые месяцы после релиза, по этой причине практически нет права на ошибку.
3) Игры сегодня это вид искусства. В работе принимают участие сценаристы, создающий мир и сюжет, на каркасе которых разрабатывается весь продукт. Сами понимаете, нельзя построить 40-этажный дом и сказать:
"Погодите, я передумал! А давайте лифт сделаем в этом месте... Да и фундамент я бы тоже переделал, кстати".
4) Игра всегда создаётся на базе какого-то культурного наследия, новых технологий или идеи создателя(ей), поддержанной миллионами долларов ранних поклонников ещё за годы до релиза. Ничто из этого не типично для продакт-девелопмента paas/saas продуктов, даже технологии.
Прошу не путать новые технологии и новые бизнес-процессы на базе новых технологий (редкие исключения есть, но они статистически не значимы).
5) При разработке игры наибольшую роль играет не качество команды, а инструменты разработки. Важна скорость итераций, насколько всё стабильно и насколько легко производить изменения в системе.
В современной стартап-культуре приоритет отдаётся команде и её системности, выбранные инструменты всегда вторичны.
Чему можно поучиться у хардкорного геймдева?
В силу столь радикальных отличий сложно сформулировать перечень по типу "To do list", который подойдёт каждому. По этой причине я выудил несколько цитат и размышлений из этой книги. Уверен, что специалисты из IT увидят что-то знакомое, но надеюсь, что какие-то полезные заметки для себя и своих проектов вы сможете сделать:
1) Работу над произведением искусства нельзя закончить, её можно только остановить. - Фраза, постоянно гуляющая в компании "Naughty dog"
2) Все сообщения об ошибках должны быть более описательными. Т.е. вот в чём проблема, а вот примерные сроки, в которые вы можете ожидать её устранения. - Ошибка 37, которая не давала поиграть в Diablo 3 всей многомиллионной базе фанатов в течении нескольких дней с момента релиза (игра разрабатывалась парой сотен людей в течении 10 лет).
Ошибка 37 стала чем-то вроде мема в игровой среде. Не надо так.
3) Самый страшный отзыв, который можно получить в геймдеве: "Это неинтересно".
В случае Saas/Paas сопоставимым отзывом от клиента будет : "Это бесполезно".
Когда клиенты присылают развёрнутые отзывы это прекрасно, значит они видят ценность, замечают значительные недостатки и находят время и желание о них рассказать.
4) Одна из самых серьёзных проблем при длительной разработке заключается в том, что, тестируя игру слишком долго, вы начинаете изобретать лишние сложности и добавлять элементы, которые добавлять не следует. - Чистая правда, в вакууме можно начать параноить и страдать галлюцинациями.
5) Компания BioWare в процессе разработки "Dragon Age: Inquisition" придумала очень необычный, но ёмкий термин в процессе общения со своим издателем ЕA - "Слезоточивые предложения". Это перечень элементов/релизов, которые компания может выпустить за дополнительный месяц, шесть месяцев, год и худший вариант, включающий перечень того, что нужно будет сократить, если издатель EA не позволит задержать выход игры.
6) Зачастую необходимо сломать некоторые кости, чтобы вправить их правильно. - Подобное при разработке игр происходит достаточно часто.
7) Способ борьбы с пиратами в игровой индустрии на рубеже 2000ых - положить в коробку с лицензионной игрой что-то ещё помимо самого диска, что-то, что будет ценно для игрока.
8) В процессе создания хорошей игры нет ничего страшного в том, чтобы сделать много лишней работы.Это нормальный элемент процесса отбора лучших идей и фильтрации наиболее слабых (The Witcher 3 - половина придуманных квестов не дошла до релиза).
9) Как создать город в который игрок поверит? Поверит, что это населённый пункт который появился тут не просто так… Создатели The Witcher 3 создали вокруг него развитую инфраструктуру, которая формирует ощущение живой и связанной экосреды. В пригороде можно найти даже маленькую деревеньку, в которой производятся колёса для телег.
Из saas/paas продуктов в этом плане эталоном является Discord (как они сами говорят: “убийца skype и teamspeak”). Это платформа для коммуникации геймеров. Пример, допустим у вас есть игра Starcraft 2, в таком случае Discord во время прелоудера покажет вам надпись: “Charging your pylon….” и множество других красочных примеров, разговаривая с игроками на их языке. В такие моменты понимаешь почему это приложение рвёт рынок и растёт сумасшедшими темпами.
Резюмируя, кому можно порекомендовать эту книгу:
1) тем, кто интересуется игровой индустрией и сам хотя бы иногда играет в игры;
2) хочет расширить кругозор и посмотреть через что проходят игровые компании в процессе создания своих игр.
Читать советую в оригинале. Издательство Эксмо, выпустило книгу в переводе некой Степановой Л.И., бодро штампующей подобные перлы:
"Если же вы любите играть медленно и ПЕЧАЛЬНО, продолжительность игры могла быть ещё большей."
По правде говоря мне теперь хочется посмотреть на человека, который играет в игру медленно и печально, почти артхаус какой-то. Местами исковеркана суть, переводчица явно была не в теме того, что переводит.
Если вы готовы к такому, то рекомендую “Кровь, пот и пиксели” к прочтению.
Ялугин Денис.
Менеджер по продукту inKin.com - Facebook
Буквально с 1 октября в продаже новое издание с отличным переводом. Книгу тоже очень рекомендую — одна из лучших про геймдев, что издавались в России.
Старое издание, кстати, можно в офисе издательства заменить на новое. Или по почте, если куплена в регионах.
я возможно новое издание куплю, чтобы было :)
Издательство то же?
Да: https://dtf.ru/27903
Есть ранний доступ, где игра дается в сыром виде и обновляется. Прямое же использование agile. Не увидел ответ на вопрос в заголовке.
Есть такое. На эти кейсы и заложил как раз те 10 градусов из 180 в статье. :)
Но справедливости ради далеко не все открывают ранний доступ, тем более публичный.
А те кто открывают, делают это в основном не для проверки гипотез, а для массового QA, чтобы найти побольше багов.
Для адептов современной продуктовой IT-разработки, это статья бесполезна. И вообще очень странное сравнение, так как AAA игры ближе к кино и рекламе, а приложения - к приложениям. Вот если говорить о мобилках, то да, если это не франшиза, то очень разработка ничем не отличается от приложений.
Но по поводу сравнения с мобильными играми, тут да, вы правы. Схожие весовых категории.
По этой причине я и указал в дисклеймере, что мобильные игры не учтены, т.к. они не рассматривались в первоисточнике
Статья не писалась исключительно для эджайл адептов
Да я не об этом. Я о том, что подход к созданию продуктов круче чем подход создания игр. Поэтому продуктовым компаниям совершенно нечему учится у игровых студий. Все с точностью наоборот. И продуктовым компаниям бесполезно вникать в подходы ААА игр, так как схожести вообще нет.
Это как сказать, что подход сапожника лучше чем подход художника, пишущего картину )
Хорошая игра – это произведение искусства, формализировать творческий процесс плохая идея.
Управление созданием продукта, это не направление творчества (художество или сапожнечество), это менеджмент, а он везде одинаковый. Есть конечно тонкости, но они не сопоставимы с теми факторами ,которые привносят в этот процесс сами управленцы, начинавшие как ремесленники и реализующие на практике то, что хотели видеть сами.
Менеджмент бывает разный. Есть менеджемент который жестко задает рамки работы.
Ежедневные планерки, continuous delivery, итд можно применить к ремесленикам (сапожникам), но нельзя к художникам создающим предмет искусства.
А что если работающие с предметами искусства захотят высказать пожелания? Программист может захотеть сказать что художники делают слишком сложные модели, а художников при этом не будет. Как это так? Кроме того команда должна знать как продвигается работа всех членов. Плюс общая мотивация. Тем более что художники не делают чего-то необычного и всегда, как и все, жестко ограничены временными рамками.
В этой топике как раз и описывается, что релизы игр очень часто переносят из-за творческого процесса, как могут делать-делать, а потом выкинуть половину работы и начать заново.
Леонардо Да Винчи годами работал над своими произведениями, делая перерывы по пол года и больше, заказчики негодовали, но терпели ))
Формализировать можно только игры на поток, типа создания клонов мобильных игр, но там фактор творчества минимален.
Если кому интересно: на Литрес уже есть новое издание с новым переводом. Даже большими буквами на обложке написано:) пошёл читать, очень заинтересовала книга.
Mvp,если я не ошибаюсь, - это минимально жизнеспособный продукт
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
Говорят и так и так, жизнеспособность выходит из минимальной ценности продукта :)
Но чаще всего используют "жизнеспособный", да.
Но суть не меняется.
Спасибо, интересная выжимка.
В целом все эти охи и ахи во _всей_ софтверной, да и остальной проектной индустрии... никогда такого не было и вот опять (см. ролик с 8-й минуты)
Со своей стороны немного поворчу, что все эти MVP, экстремальные программирования, разработка под локоть с заказчиком, выкатывание десятка релизов с тысячами патчей да еще с DevOps и прочие позаказные производства - это как бы не везде применимы.
Как гибкие и экстремально быстродоходящие до конечного потребителя небольшие функциональности (особенно с учетом АБ-тестирования и прочих софтлончей) могут быть очень полезны.
И как справедливо заметили присутствующие, нет особой специфики у проектного геймдева. Все эти болячки давно прошерстили Брукс, ДеМарко, Деминг, Голдратт и др.
Много интересных докладов было у Дорофеева, который в итоге решил зайти с другой стороны и ушел прокачивать эффективность и работоспособность отдельных человеков (:
Комментарий удален модератором
Комментарий удален модератором
Заплюсую, как-то не вяжется.
Agile, Customer Development, MVP и тд, и тп, и иже с ними это всего лишь инструменты они могут использоваться везде, начиная с улучшения операционки в агентстве ритуальных услуг, заканчивая запуском спутника. (К-мон, канбан растет с японских заводов!).
Какие-то на 170 процентов неверные выводы у вас.
Обоснуйте
Я даже не знаю, что вам ответить. Если бы вы хотя бы больше одного слова мне в ответ написали, ну там “обоснуйте, пожалуйста”, я бы может и что-то написал подробнее. Но в целом ваши выводы не имеют к реальности игровой индустрии никакого отношения. Вы надергали каких-то вас зацепивших фактов и почему-то решили подвести под них какие-то теории. В книге совсем нет никаких попыток сделать выводы, там просто описаны интересные кейсы из жизни нескольких компаний, которые никак нельзя проецировать на остальную индустрию, и уж тем более нельзя проецировать вне ее.
Опять же, какой из моих выводов не связан с индустрией? (плюс выводы по игровой индустрии опираются в первую очередь на мнение автора книги)
Прошу указать конкретные примеры, а не общие слова.
Автор книги - журналист, нахватавший по верхам какие-то факты из жизни крупных компаний, которые будут интересны широкой аудитории. К реальным процессам производства в игровой индустрии почти все написанное имеет очень отдаленное отношение. Ну то есть это как проецировать рассказ журналиста о процессах в компаниях эппл и майкрософт на другие айти компании - надеюсь такая аналогия вам более понятна. А вы даете советы, которые являются мнением человека, не разбирающегося в индустрии, основанным на мнении журналиста, не разбирающегося в индустрии, написавшего книгу, основанную на поверхностных фактах небольшого количества компаний, процессы в каждой из которых абсолютно уникальны не характерны для индустрии в целом.
Комментарий недоступен
Спасибо!)
Комментарий недоступен
Нет, это совсем не так. Везде используются методологии и прочее. Везде человек получает задачу от начальника, обсуждает её, делает, тестирует. Возможно, на этапе бреиншторма фич и построения наратива - да, у дизайнеров и скриптеров свои процессы. Но у тех, кто пишет код - всё везде одинаковое.
Комментарий удален модератором
Привет! Спасибо за статью. Вот пара советов, как можно её улучшить: https://vc.ru/team/28520-how-to-vcru
Интересная статья 👍🏻
Благодарю:)
Да, все так. Уже сейчас в геймдеве самые большие деньги по сравнение с кино, ТВ и СМИ. Людям нравятся произведения искусства, а они даются тяжелейшим трудом. Не удивлюсь, если через несколько лет принципы геймдева распростанятся и на другие сферы. Остальные просто не смогут выдержать конкуренцию
Какие именно принципы?
Комментарий недоступен
игра за 60, лутбоксы за 600 наверное
Не совсем понимаю зачем IT учиться у гейм-дева и наоборот? У каждой из этих отраслей диаметрально противоположные цели и пути их достижения, несмотря на похожий инструментарий и некоторые смежные проблемы в процессе разработки.
Почти у любого человека чему-то можно поучиться, не говоря уже о смежных отраслях)