Глава 6. Мониторинг и изменения курса
Вообще-то, эта глава должна была называться «Эй, ямщик, поворачивай к черту!», поскольку на практике термин «изменение курса разрабатываемого проекта в ходе его разработки» скрывает за собой крайне драматические события. Это судьбоносный момент, когда на капитанском мостике вашего атомохода в яростной схватке за рулевое колесо сцепились инвесторы, генеральный директор, продюсер, ведущий гейм-дизайнер и прочие принимающие решения лица, а от исхода этой борьбы часто зависит судьба всего проекта. Но начнем мы не с изучения практики проектного галсирования, а с такого термина, как «производственный ад», поскольку чаще всего именно за входом в этот режим следуют попытки взять новый проектный курс.
В игровой индустрии есть такое понятие, как «производственный ад» (Development hell). Чаще всего его применяют к тем играм, чья разработка затянулась на долгие годы или была настолько напряженной, что вспоминается она как страшный сон. Упоминание страшного сна тут совсем не фигурально, обычно для всех участников проекта это реально травмирующий опыт, который потом аукается долгие годы.
Таким образом, производственный ад является той локацией на карте игровой индустрии, куда точно не хотел бы попадать ни один разработчик (но почти все там регулярно оказываются). Это стадия разработки проекта, когда уже запущенное производство перестает работать эффективно и КПД ваших командных действий все время снижается. Вы вроде бы делаете очень много, но при этом сам проект почти не сдвигается с места. Это можно сравнить с попаданием в зыбучие пески – все ваши активности только ухудшают положение, и чем больше вы дергаетесь, тем хуже становится проекту. Парадоксально, но рецепт по выходу из этой проектной ситуации такой же, как и по выползанию из зыбучих песков – не суетиться и изменить сам вектор приложения усилий.
В моей практике самыми «адовыми» в этом плане были «Агрессия» (почти 5 лет разработки) и «Блицкриг 3» (7 лет, из которых я был на проекте чуть больше 3-х). Причины попадания в такую ситуацию у этих игр, что характерно, были разными.
«Агрессия» оказалась там из-за неверной оценки масштабов и сложности проекта – команда разработки на тот момент не могла сделать такой проект в нужном уровне качества. Мы об этом уже говорили в предыдущих главах. Что нам нужно было делать на тот момент?
Во-первых, срочно остановить производство проекта, где уже штамповались юниты (при том что движок игры еще толком не работал и не позволял их даже протестировать). Далее – собрать работоспособную core team (вспоминаем главу, посвященную этапу препродакшен), то есть закрыть все ключевые позиции. Затем сформировать нормальное позиционирование проекта, исходящее из 2–3 точек, в которых команда была объективно сильна. В-четвертых, использовать спрайтовый движок от предыдущего проекта студии и не пытаться всеми силами «перейти в 3D», так как при таких данностях это грозило серьезной потерей качества. Далее максимально ограничить масштаб проекта. Получилась бы у нас в итоге еще одна игра в стиле популярных в ту эпоху «Казаков», но заточенная под Первую Мировую и близкие к ней эпохи. То есть «Антанта 2», более качественная и, вероятно, с какими-то опциями на несложном стратегическом уровне.
С «Блицкригом» ситуация была другой – выйти из производственного ада там мешали постоянные смены курса проекта и проблемы на стыке управления, продюсирования и целеполагания. Грубо говоря, руководство не могло до конца определиться, куда же мы плывем, а команда разработки при этом продолжала выполнять весь список прошлых распоряжений.
А вот как бы сложились события, если бы у нас была машина времени и мы смогли прогнать через это замечательное послезнание ситуацию на «Блицкриге 3» образца весны 2011 года? У нас есть небольшая команда (15–20 человек), готов прототип на Unity, где аккуратные танчики ползают по карте и умеют красиво друг друга взрывать, есть много дизайн-документации, и на этом почти все. При этом у нас нет серверной технологии, нет блока искусственного интеллекта, нет адекватной жанру меты, нет четкого понимания системы монетизации (нет даже понимания, ПК проект мы делаем, браузерный или мобильный). Грубо говоря, у нас есть только базовый геймплей, ядро, вокруг которого надо построить все здание игрового проекта. При этом где-то уже делается Clash of Clans, который выйдет всего через год (в августе 2012 года) и создаст новый формат стратегии реального времени, адаптированный под мобильные платформы. Кажется, что путь очевиден – нужно брать зернышко геймплея «Блицкрига» и адаптировать его под мобайл. Пройти прежде всего весь технологический процесс впихивания «корпускулярного геймплея RTS» в экран телефончика. В таком случае на момент выхода Clash of Clans мы были бы готовы встроиться ему в фарватер и где-нибудь к осени 2013 года выпустить свой аналог Boom Beach (правда, про аудиторию оригинального «Блицкрига» в таком случае лучше даже не вспоминать – она бы нас прокляла на веки вечные).
Либо второй вариант – обратить внимание на то, что к этому времени World of Tanks уже триумфально прошел этап открытого тестирования и всасывает в себя всю мировую военно-историческую аудиторию. В этом проекте уже есть работоспособный мета-уровень, понятные широкой аудитории правила игры на тактических картах, и это достаточно близко многопользовательским боям в оригинальном «Блицкриге». Этот путь также открыл бы для проекта очень широкие перспективы. Хотя и здесь пришлось бы пожертвовать частью аудитории оригинального «Блицкрига», приближая формат сражений к многопользовательским боям WoT.
Вместо этого мы пошли своим путем, собирая свои же уникальные грабли, которые перед этим сами и разбрасывали. Концепция «асинхронного RTS/base building» игрового процесса (когда один пользователь расставляет на карте оборону, а второй его атакует в асинхронном режиме) была взята из браузерных игр и не соответствовала ожиданиям ядра аудитории франшизы. Она же делала экономически невыгодным многопользовательский режим (так как один серверный инстанс запускался, по сути, для одного игрока). Вообще, история «Блицкрига 3» – это история безнадежной борьбы продюсирования с реальностью рынка, закончившаяся логичным поражением. В процессе разработки игра кардинально менялась несколько раз даже за свою первую половину жизни, пока я руководил проектом, а уж потом изменения были постоянными, резкими и подчас очень неожиданными (от полной и тотальной казуализации игрового процесса до возвращения к истокам, с которых все начиналось). Я не буду сосредотачиваться на проблемах и конфликтах, так как в целом про причины уже рассказано, а в деталях мало интересного. Кроме этого, производственные проблемы игры были достаточно специфичными и могут быть полезными читателю, только если он сам занимается разработкой классической RTS в 2023 году.
Как вы уже, наверное, поняли, причины попадания в производственный ад могут быть самыми различными, а вот средство выхода обычно общее – перепланирование проекта и изменение его концепции/формата/объема или команды.
Поэтому для того, чтобы продолжить разговор, мы пробросим мостик от прожект-менеджмента к производству и попытаемся выяснить, а как меняется наша документация уже после начала процесса массового производства игры?
Об этот вопрос поломано немало копий, и по нему есть целый ряд школ управленческого кунг-фу. Я являюсь сторонником школы пьяного мастера, который не усложняет жизнь ни себе, ни команде. Мы хорошо потрудились на этапе препродакшена и делали документы ДО того, как начали возводить здание проекта в материале, поэтому теперь можем немного снизить прессинг команды по части документации. Тем более что в процессе разработки не так уж и много действительно критичных точек, которые обязательно должны быть задокументированы.
Кстати, пользуясь случаем, размещу в этой главе достаточно лаконичную методичку, посвященную тому, как справиться с проблемами планирования проекта. Итак, самое главное соблюсти принцип – на любом этапе жизни проекта у него должен быть следующий набор планов.
Первым делом это очень высокоуровневый идеологический план, который также можно считать «концепцией проекта». Он указывает на некую точку в идеальном мире, в которую нам надо прийти (и описывает то, с чем мы должны туда прийти). Тут может не быть четких сроков, это план «примерно на год» (а по факту обычно на 1,5–2 года работы по трудоемкости). Эту точку очень важно иметь в сформированном виде и иметь впереди, независимо от стадии проекта. Даже имея уже выпущенную игру, необходимо, изредка поднимая голову между окончанием боевого пропуска и скидочной акцией, смотреть на этот свет далекой звезды, иначе проект утонет в оперировании, которое не равно его развитию. Наличие такой «сверхидеи» также будет вас немного страховать от фокусов конкурентов – в случае появления у них реализованной «звездочки» вам будет чем ответить.
Далее следует план на следующие 3–6 месяцев, назовем его достаточно условно «дорожной картой». Здесь самое важное – задать правильный «ритм проекта», то есть разбить часть глобальных задач из первого плана на адекватные возможностям именно для вашей команды куски. Делается этот план в зависимости от проектных мощностей отделов (сколько – одну, две или больше – крупных фичей в релиз могут себе позволить программисты, какое количество типового контента ежемесячно выдает арт-отдел, какова усредненная скорость работы дизайнеров карт/локаций и так далее). Крайне важно здесь задать именно ритм, то есть чередование периодов разработки, отладки и вывода версий проекта. Именно в этот план закладываются буферы на тестирование и отладку (без них будет происходить постоянное накопление задач и потребных исправлений, и все планы будут ехать).
Третьим пунктом у нас будет детальный план на следующий релиз, то есть уже тактический уровень документации. Это обычно табличка с фичами и оценками, сделанными на основании технических заданий. Это самый подробный этап планирования, который делается от оценок исполнителей, к которым добавляется буфер на всякие неожиданности. Он должен максимально полно описывать работу всей команды на ближайшие 2–3–4 недели (зависит уже от того, как плотно у вас релизы или версии).