Эта игра получила две номинации IGF, выиграла призы Excellence in Design и Excellence in Audio, вышла на PS3 и PC и собрала хорошие отзывы критиков, а студия, которая её сделала, после успешного релиза фактически развалилась, а один из двух сооснователей выгорел и ушёл в найм. Ни провала, ни скандала, ни закрытого издателя, просто четыре года разработки человеческих жизней были потрачены. Что за игра, если не узнаете, напишу в конце.
Историю постмортема я знаю из первых рук. В начале десятых мой знакомый, сваливший в Штаты за длинным баксом, вдруг вернулся в родной Питер без этого самого длинного бакса, зато с Шеви Тахо и долгами, проработав аутсорсером в той студии от первого коммита почти до закрытия. Тахо ему потом пришлось продать, потому что расход небольшого заводика накладывает некоторые ограничения на бюджет, но история не об этом…
Идея игры возникла случайно, когда команда делала техническое демо для совсем другой игры и добавила туда отладочный режим, чтобы отматывать время назад и повторять участки геймплея, обычная сейчас вещь, без которой ловить баги в динамичной игре довольно больно. В итоге они решили превратить саму перемотку времени в кор механику игры.
Контракт, или откуда взялась эта статья
В начале лета со мной связалась Регина из Стратоплана и предложила пройти один из их курсов, в обмен на несколько статей на Хабр, по одной после каждого этапа курса (их всего три). Я потом рассказываю чему удалось научиться, уже на языке и в формате, в котором привык писать.
До этого я уже проходил похожий курс в другой ненашенской школе молодых управленцев, потому что на тот момент мне нужно получить маячившую где‑то на горизонте позицию тимлида, а вместе с ней появилась необходимость обзавестись новыми лычками и каким‑нибудь сертификатом. Для человека, который достаточно долго варится в разработке, новая лычка сама по себе, конечно, вещь довольно забавная и полезная, большей частью новыми связями, но реальный опыт выпасания двадцати котов в боевых условиях увы не появляется автоматически после красивой бумажки с подписью Джона нашего Себастьяновича, скорее это шрамы шипнутых проектов и уволенных тобой коллег.
Предложение я принял, но обозначил одно условие, что статьи будут моими. Они вполне могут оказаться некомплиментарными, а содержание, выводы и подача будут такими, какими я их вижу сам, иначе весь этот эксперимент, назовем это экспериментом, скатится в банальную рекламу, а заказные статьи писать мне неинтересно.
Курсов у Стратоплана несколько, я полез смотреть что та да как. CTO‑трек отбросил сразу, посидев почти полгода в роли ио техдира, и помучавшись на менеджерских созвонах, довольно быстро понял, что это просто не моё болото. А вот курс для молодого тимлида меня зацепил, пусть и не совпадает с моей нынешней позицией, потому что в любой команде есть проблемы и моя не исключение, и не всегда я знаю как их решить. В конце концов, возможность немного систематизировать собственный опыт и посмотреть на проблемы управления командой лишней точно не будет.
Первый модуль такой повод дал, когда разбиралась модель командных ролей Белбина. Но… всегда есть какое‑то но… учебный кейс он на то и учебный, простой, вылизаный, команда с наборрм ролей, описание участников, и все аккуратно разложено по ячейкам, но учебные примеры на то и учебные, потому что люди живые и настоящие кейся ни в какие примеры не влезают.
Разбирать свою команду было неинтересно, соседей тоже, а то обидятся еще, тогда я попробовал сделать наоборот и взял случай из индустрии, довольно известный, но который меня зацепил, скажем так, своей неправильностью и посмотреть, что получится там с этой моделью. А вот получилось или нет и насколько полезно можете высказаться в комментарих. Засим, рекламную часть считаю выполненой и…
Вернемся к игре…
Предложенный вариант вытащили в кор‑механики, так появился ритм‑шутер, в котором игрок как бы проходит космическое сражение задом наперёд, «возвращая» выпущенные снаряды обратно в пушки под музыку. Идея оказалась достаточно оригинальной, чтобы получить номинации Independent Games Festival и призы Excellence in Design и Excellence in Audio. На старте разработки идея и планы выглядели образцовой историей независимой разработки, когда маленькая команда, необычная механика и желание довести её до уровня полноценной коммерческой игры играли на руку команде, придавая сил и стирая границы между ночью и днём. Проблемы начались, когда команда попыталась эту идею довести до релиза.
В июле 2 008 года ребята основали свою студию и набрали часть народа, куда попал и мой товарищ. Игра должна была стать главным проектом студии, и основная команда состояла из двух человек, занимавшихся движком, ещё одного человека, отвечавшего за дизайн и игровое программирование, ещё одного за эффекты и инструменты, плюс несколько художников по контракту. В постмортеме основатель студии приводит цифры, которые показывают масштаб происходившего.
Игра (по материалам GDC 2013)
Разработка версии для PS3 ~4 года
Основная команда ~2 + 1 + 1 + 4 человека
Строк кода ~748 000
Рабочая неделя ~80 часов
Для сравнения с LittleBigPlanet
Строк кода ~527 000
Команда 37 разработчиковФактически четыре человека против тридцати семи, при этом в проекте написали кода в полтора раза больше. Само по себе количество строк ещё ничего не доказывает, и, конечно, код бывает разный, а сравнивать проекты по LOC примерно так же надёжно, как сравнивать красоту машин по весу, но в сочетании с размером команды и сроками эта цифра показывает, сколько технологической работы легло на плечи нескольких человек.
Для меня, как для человека, который много лет занимается движками, видно, что эти монстры успели сделать очень и очень много, учтите, что там на дворе 2008–12 годы, а документация к плойке дружелюбием не славится и частями вообще существуем только на японском. Сделали динамическое освещение и тени, потоковую загрузку данных, декодер текстур, оптимизированный под SPU, систему частиц, процедурную анимацию боссов, инструменты оптимизации шейдеров и ещё много чего. Всё это было написано руками человеков и до эпохи Клавдия, то есть это нереальное количество труда и времени в пересчёте на человека.
Кто читал мою статью про память в консолях, помнит, что SPU на PS3 большинство студий обходили стороной и многие даже не открывали документацию на него, а тут несколько человек пишут на нём отдельный движок с нуля для ритм‑шутера. С инженерной точки зрения это вызывает уважение, с точки зрения продукта это вызывает вопросы. Или как минимум один вопрос о том, сколько из этого действительно требовалось игре, а сколько команда сделала, потому что хотела создать технически выдающийся продукт?
Рекурсия без условия выхода
В презентации на GDC в постмортеме есть слайд с названием Circular Logic, «Порочный круг», и он объясняет, что происходило в команде. Команда вложила в игру практически всё что знала и умела, включая своем время, деньги и надежды, поэтому выпускать её страшно, а неудача ставит под угрозу всё, ради чего работали несколько лет. Чтобы повысить шансы на успех, игру продолжают улучшать, разработка становится дольше, вложенные средства и давление растут, а из‑за выросших рисков выпускать игру становится ещё страшнее.
// Как решение принималось на практике
while (!feels_good_enough(game)) { // критерий живёт в голове основателя
feature = pick_next_cool_thing(); // интересно реализовать
implement(feature); // ещё +3 месяца
risk += months_spent; // цена провала растёт
fear += risk; // и страх релиза вместе с ней
}
release(game); // недостижимо: fear растёт быстрее quality
// Как стоило бы
for (feature : backlog) {
if (now() > feature_freeze) break; // внешний критерий готовности
if (!raises_sales(feature) && !noticeably_improves_ux(feature))
continue; // интересно != нужно
implement(feature);
}
release(game);То есть дополнительные усилия, которые должны были снизить вероятность провала, одновременно повышали его цену. Это рекурсия без условия выхода, только переполнение будет уже не у программы, а у людей. И это уже не технический перфекционизм, а управленческая ловушка, в которой решение продолжать работу выглядит рациональным на каждом отдельном шаге, но вся последовательность шагов оказывается разрушительной.
Представьте, что у вас есть игра, которую можно выпустить прямо сейчас, и вы знаете её недостатки и понимаете, что ещё три месяца сделают её лучше, но на неё уже потрачено четыре года и от её успеха зависит будущее студии. В такой ситуации очень легко убедить себя, что три месяца будут незначительной ценой по сравнению с потенциальным успехом и потраченными четырьмя годами. А потом появляются следующие три месяца, как «ещё пять минут» после будильника, и чем дольше откладываешь выпуск, тем труднее признать, что страх релиза затягивает игру.
Перфекционизм не инструмент
После выпуска у всей команды диагностировали разные психологические проблемы, начиная от обсессивно‑компульсивное расстройства и бессонницы, и заканчивая тяжелой депрессей, которая требовала медпрепаратов. Это важная часть истории, и я сразу оговорюсь, что сводить проблемы проекта к диагнозу команды нельзя, но некоторые врачи считают что перфекционизм тоже болезнь, и сам столкнувшись с парой таких команд в реале, шутить про «остаться на пару часов после работы» в этом месте не буду.
После выпуска игры основатель студии пошёл к психологу, который ему популярно объяснил, что его стремление довести работу до идеала в итоге заразило, и не в хорошем смысле, всю команду, начав влиять на решения о разработке. В нормальной разработке полишинг фичей это рабочий инструмент, и нормально улучшать какие‑то системы, которые влияют на опыт игрока, но нужно и понимать, когда надо остановиться, если дальнейшие вложения перестают окупаться.
А если критерия качества, когда «вот теперь достаточно хорошо», нет, то у процесса нет и естественной точки остановки, потому что любой недостаток можно исправить, любую систему улучшить, любой эффект сделать красивее, и понятия «достаточно хорошо» тоже нет, оно просто начинает расти вместе с проектом.
И очень явно это проявляется именно в маленькой команде технически сильных, может быть, даже гениальных людей, которые способны реализовать почти любую придуманную возможность и сложность. Способность сделать сложную вещь начинает подменять вопрос о том, нужно ли её делать вообще, и сложный движок на плойку появляется просто потому, что вы его может написать, а не потому, что без него не получится выпустить игру.
Один из ключевых выводов основателя студии вылился в постмортем на GDC и сводился к тому, что идеальная игра похоронит вашу студию. Прежде чем тратить дополнительное время на фичу, спросите себя, увеличит ли она продажи или хотя бы улучшит опыт игрока. Для технической команды это нужный фильтр, и можно неделями оптимизировать загрузку, которая и так достаточно быстрая, или делать эффект, который большинство игроков вообще не увидит. Да, инженерная задача может быть сколь угодно интересной, но интерес разработчика не равен интересу игроков. Это не означает, что любую работу надо мерить только прямым влиянием на продажи, но у каждого такого вложения должно быть понятное обоснование, которое можно сказать вслух и вам не скажут, что это фигня.
Почему не получится сказать стоп
Со стороны решение остановиться выглядит простым, если ты не колобок, но если руководитель сам эмоционально заряжен на проект и воспринимает его как личное достижение, боясь неудачи, то он и становится главным человеком, который мешает команде закончить работу.
У такого человека нет внешнего критерия готовности, а его решение о завершении зависит только от субъективного ощущения качества. Нет механизма остановки, и новые улучшения добавляются и добавляются, а старые решения никто не пересматривает. Интересы разработчика и продукта смешиваются, и уже технические решения выходят на первый план вместо игры, становясь снежным комом.
Четыре года работы не делают следующий месяц разработки выгоднее и не оправдывают следующие вложения. Это классическая ошибка невозвратных затрат (sunk cost fallacy). В доступных материалах и постмортеме на GDC нет оснований утверждать, что остальные участники команды пытались остановить основателя студии, как‑то спорили с ним или боялись ему возражать. Это была бы уже моя догадка, просто доклад гораздо лучше раскрывает личные решения основателя, чем внутреннюю динамику команды.
Но вот что можно увидеть по открытым данным, так это кто в команде за что отвечал, и попробовать посмотреть на это через модель Белбина. Сразу оговорюсь, что речь не о том, чтобы по должностям и нескольким слайдам постмортема достоверно определить психологические роли конкретных людей, для этого у нас слишком мало информации. Скорее, модель поможет задать вопросы о том, какие функции были заметны в команде, а какие, судя по доступному описанию, могли остаться без достаточного внимания.
Кто такой Белбин
Мередит Белбин выделил девять командных ролей в трёх группах, интеллектуальные (Генератор идей, Аналитик, Специалист), социальные (Координатор, Командный игрок, Исследователь ресурсов) и роли действия (Мотиватор, Реализатор, Завершитель). У каждого человека обычно две‑три сильные роли, эффективной команду делает баланс между ролями, и у каждой роли есть «допустимая слабость», обратная сторона её силы, которую компенсируют ролью из другой группы.
Состав команды и распределение работы на GDC были озвучены достаточно явно, чтобы попробовать построить предварительную модель по Белбину. Основные роли я определял по функциям, которые люди выполняли в проекте, но здесь важно не перепутать роли с должностями. Специалист по движку не обязательно является Специалистом в смысле Белбина, а руководитель не обязательно Координатор. В таблице ниже не психологический портрет команды, а попытка посмотреть, какие командные функции можно предположить по публичному описанию и какие из них в истории проекта особенно важны.
Интеллектуальные Социальные Действия
Первый Специалист (дизайн, — Завершитель ●●●
геймплейный код) (+ тянет темп на себе)
Второй Генератор идей — —
(перемотка как механика),
Специалист (движок,
эффекты, инструменты)
Инженеры и Специалист (арт) — —
контрактники
──────────────────────────────────────────────────────────────────────────────
Вопросы для Аналитик Координатор, Реализатор
команды Командный игрок,
Исследователь
ресурсовКартина, думаю, знакомая для любого, кто видел, как работает маленькая студия из сильных инженеров. Вся интеллектуальная колонка выглядит очень насыщенной, тогда как по социальным ролям и функциям управления процессом у нас просто нет достаточной информации, чтобы уверенно говорить о балансе. Но именно в этой истории особенно заметен вопрос о том, кто должен был вовремя сказать «стоп» и проверить, действительно ли очередное улучшение нужно продукту.
Здесь интересно не столько отсутствие конкретной роли, сколько отсутствие видимого механизма, который регулярно пересматривал бы решения, соотносил технические амбиции с ограничениями проекта и помогал команде договориться, что работа уже достаточно хороша для релиза. По доступным материалам нельзя сказать, что в команде вообще не было Аналитика или Реализатора в смысле Белбина, но можно сказать, что их функции не проявляются.
Социальная функция тоже не сводится к тому, чтобы все хорошо ладили друг с другом. В контексте инди‑разработки сюда относится и способность удерживать связь между тем, что интересно разработчикам, и тем, что нужно продукту, и умение договариваться о границах работы. Если технические решения начинают жить собственной жизнью, а критерий готовности остаётся субъективным, даже очень талантливая команда может оказаться в такой петле. Собственно ей и дали чуть позже это имя, «мертвая петля перфекционизма», ну вы поняли юмор?
Чем всё закончилось
Retro/Grade вышла на PlayStation 3 и PC, получила положительные отзывы и признание критиков, но хорошая игра и здоровый процесс разработки… это вообще про разное. Команда сожгла свой человеческий ресурс, работая по 80–100 часов в неделю, основатели ушли в найм, кто‑то полежал в больничках, кто‑то, как мой товарищ навсегда ушел из разработки. Вот такие пироги с котятками… Иногда стоит задавать себе неудобный вопрос «а это точно нужно?», но в 24 Caret Games, таких людей не нашлось.
Автор: dalerank
