Читать книгу - "Как делать хорошие игры. От идеи до запуска - Петр Прохоренко"

«производственный ад» (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 году.

Как вы уже, наверное, поняли, причины попадания в производственный ад могут быть самыми различными, а вот средство выхода обычно общее – перепланирование проекта и изменение его концепции/формата/объема или команды.

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

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