Режим отладки, превратившийся в игру

23 минуты назад Прокомментировать Просмотры: 0

Эта игра была дважды номинирована на IGF, получила награды Excellence in Design и Excellence in Audio, вышла на PS3 и PC и тепло встретила критику. При этом студия-разработчик после удачного релиза по сути перестала существовать, а один из двух основателей выгорел и ушёл работать по найму. Ни громкого провала, ни скандала, ни обанкротившегося издателя: четыре года человеческих жизней просто растворились в разработке. Что это за игра, расскажу в конце, если вы ещё не догадались.

Историю этого постмортема я знаю из первых рук. В начале десятых мой знакомый уехал в Штаты за большими деньгами, а через какое-то время вернулся в родной Питер уже без них, зато с Chevrolet Tahoe и долгами. Почти всё время, от первого коммита и до самого закрытия, он проработал в той студии на аутсорсе. Tahoe ему вскоре пришлось продать: аппетиты такого «небольшого заводика» плохо вписываются в скромный бюджет. Но речь не об этом…

Игра родилась почти случайно. Команда собирала техническое демо совсем другого проекта и добавила в него отладочный режим, позволявший отматывать время назад и повторять фрагменты геймплея. Сегодня это обычная практика: без неё отлавливать баги в динамичной игре довольно мучительно. В итоге ребята решили сделать саму перемотку времени центральной механикой.

Договорённость, или как появилась эта статья

В начале лета со мной связалась Регина из «Стратоплана» и предложила пройти один из их курсов. Взамен нужно было написать несколько статей для SE7ENа, по одной после каждого из трёх этапов. В них я делюсь тем, чему удалось научиться, на привычном мне языке и в привычном формате.

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

Предложение я принял, но с одним условием: статьи будут моими. Они вполне могут получиться неудобными для организаторов, а содержание, выводы и подачу я определяю сам. Иначе весь этот эксперимент (назовём его так) превратится в банальную рекламу, а писать заказные тексты мне неинтересно.

У «Стратоплана» несколько курсов, и я отправился изучать, что к чему. CTO-трек отпал сразу: почти полгода я исполнял обязанности техдира и намучился на менеджерских созвонах, так что быстро понял, что это не моё болото. Зато курс для начинающего тимлида зацепил, хотя он и не вполне совпадает с моей нынешней ролью. В любой команде есть проблемы, моя не исключение, и далеко не всегда я знаю, как их решать. К тому же возможность упорядочить собственный опыт и свежим взглядом посмотреть на управление командой точно не будет лишней.

Повод для этого дал уже первый модуль, посвящённый модели командных ролей Белбина. Но… всегда есть какое-то «но». Учебный кейс на то и учебный: простой, причёсанный, с готовым набором ролей, описанием участников и аккуратной раскладкой по ячейкам. А живые люди и реальные истории в такие схемы не помещаются.

Разбирать собственную команду мне было неинтересно, как и соседние, а то ещё обидятся. Поэтому я пошёл от обратного и взял случай из индустрии, довольно известный и зацепивший меня своей «неправильностью», чтобы проверить, что получится, если приложить к нему эту модель. Удалось ли это и насколько полезно вышло, судить вам, пишите в комментариях. На этом рекламную часть считаю выполненной, и…

Вернёмся к игре…

Эту идею вынесли в основу геймплея, и так появился ритм-шутер, где игрок словно проходит космический бой задом наперёд, под музыку «возвращая» выпущенные снаряды обратно в орудия. Замысел оказался настолько оригинальным, что принёс номинации на Independent Games Festival и награды Excellence in Design и Excellence in Audio. На старте всё выглядело как образцовая инди-история: маленькая команда, необычная механика и желание довести её до уровня полноценной коммерческой игры. Это придавало сил и стирало границу между днём и ночью. Трудности начались, когда идею потребовалось довести до релиза.

В июле 2008 года ребята основали собственную студию и набрали первых сотрудников, среди которых оказался и мой знакомый. Игра должна была стать главным проектом студии. Ядро команды составляли два человека на движке, один отвечал за дизайн и геймплейный код, ещё один занимался эффектами и инструментами, плюс несколько контрактных художников. В постмортеме основатель приводит цифры, которые хорошо передают масштаб происходившего.

Игра (по материалам GDC 2013)
  Разработка версии для PS3   ~4 года
  Основная команда            ~2 + 1 + 1 + 4 человека
  Строк кода                  ~748 000
  Рабочая неделя              ~80 часов

Для сравнения с LittleBigPlanet
  Строк кода                  ~527 000
  Команда                     37 разработчиков

Выходит, четверо против тридцати семи, причём кода написано в полтора раза больше. Количество строк само по себе ничего не доказывает, код бывает очень разным, а сравнивать проекты по LOC примерно так же надёжно, как оценивать красоту автомобилей по массе. Но в сочетании с размером команды и сроками эта цифра показывает, какой груз технологической работы лёг на плечи нескольких человек.

Как человек, много лет занимающийся движками, я прекрасно вижу, сколько эти ребята успели сделать. Учтите: на дворе 2008–2012 годы, а документация к «плойке» дружелюбием не отличается и местами существует только на японском. Они реализовали динамическое освещение и тени, потоковую подгрузку данных, декодер текстур, оптимизированный под 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 такого человека не нашлось.

Источник