Можно ограничиться этим, но хорошо, если еще есть свое планирование в отделах и оценки в общих планах являются результатом управленческой работы на местах, а не надиктовываются менеджерскому сословию голосами в голове. Самое главное – это все не очень большие документы, максимум на 2–3 странички. То есть вы с их помощью не только командой сможете управлять, но и ввести быстро в курс дела кого-то со стороны (нового сотрудника, партнеров, инвесторов).
Правильный выход из производственного ада (и вообще любые изменения в идущих проектах) заключаются в уменьшении объема работ, но почему-то повсеместно любое перепланирование приводит к противоположному результату – работы становится еще больше. Это еще один из парадоксов игровой индустрии!
Как сделать хорошую игру, Способ № 20: Примите за правило, что в процессе разработки вашего проекта его объем при перепланировании должен УМЕНЬШАТЬСЯ, а не увеличиваться. Уменьшение объема почти всегда дает возможность освободить ресурсы и подтянуть уровень качества. Помните, что игроки редко считают игры хорошими только за то, что эти игры большие. Качество всех элементов сильно важнее, тем более что судить вас будут по самому слабому из них.
Поэтому далее в рамках этой главы мы посвятим достаточно большой фрагмент текста такому понятию, как «фичакрип». Даже если вы не имеете прямого отношения к игровой индустрии, вы наверняка его слышали, скорее всего в контексте оправданий разработчиков за недостаточное качество финальной игры.
Фичакрип, или «раздувание функциональности». К концу разработки выясняется, что для сдачи законченного продукта требуется реализовать все больше и больше функций, «и все они очень нужны». Это и есть фичакрип (англ. feature creep). Ходят легенды, что это главная причина невыхода программных продуктов и превышения бюджета.
Рассказ про это самое «раздувание функциональности» я начну с личных примеров для того, чтобы вы более явно увидели, как это вообще происходит (и почему помешать этому очень сложно).
Начнем с «9-й Роты», игры по одноименному фильму, которая вышла, кажется, в далеком 2008 году. О проекте «9-я Рота» рассказать можно коротко – мы взяли тактическую часть «Агрессии» и начали значительно ее дорабатывать. И все было бы хорошо, но тут сыграло роковую роль мое неуемное (на тот момент) желание сделать ролевую тактическую игру в стиле Fallout Tactics. Именно отсюда вышел «тактический экран оснащения», самая сложная и вредная фича проекта. Мне нужно было сделать задел «на будущее», и я спроектировал, а потом (пользуясь служебным положением) протащил в проект фичу несоответствующей ему глубины. В общем, проектная команда с моей тяжелой руки получила предназначенный для тактического отряда борцов с мутантами экран, где нужно было ручками снаряжать каждого персонажа вплоть до того, какие гранаты и магазины в какие карманы ему засунуть. Только в моем будущем пост-апокалиптическом проекте планировалось всего 6–9 персонажей в партии, а в «9-й Роте» под управлением игрока находился целый взвод Советской Армии, почти 40 человек. Но это досадное обстоятельство никого из нас тогда не смутило.
Как сделать хорошую игру, Способ № 21: Не загадывайте слишком сильно вперед, не пытайтесь заложить в текущем проекте какие-то идеи «для будущего». Конечно, нужно использовать весь свой опыт предыдущих проектов в последующих, это абсолютно нормально, но настоящее не должно страдать в угоду так и не случившемуся будущему. Та игра, над которой вы работаете сейчас, – безусловный приоритет!
Впрочем, игра получилась на вполне хорошем среднем уровне для того времени, и все ее проблемы после релиза были связаны скорее с жесткой конкуренцией «игр про девятую роту» – их на тот момент было как минимум три. До сих пор у игры есть поклонники, которые ценят ее уникальный геймплей, возникший вследствие сочетания случайных факторов: дисбаланса экрана оснащения, боевого режима с управляемой паузой, физической модели локаций.
Игра была достаточно реалистичной (все-таки частично это был идейный наследник «Сталинграда») и представляла возможность пройти набор миссий с достаточно глубоким погружением в этот мало известный в мире военный конфликт. Вот что нам пишет современная Википедия: «Игра посвящена 9-й роте 345-го отдельного гвардейского парашютно-десантного полка – элитному подразделению советского десанта, воевавшему в Афганистане весь период конфликта. Как и в картине, главные герои игры, вчерашние призывники, отобранные для службы в 9-й роте, пройдут через обучение военному ремеслу, выполнят ряд боевых заданий, среди которых – масштабное сражение на высоте 3234».
Вообще фичакрип как бессистемное и бесконтрольное раздувание функционала продукта есть безусловное зло, но тут нужно конечно отделить зерна от плевел и понимать, что фича фиче рознь. Когда речь заходит о мелких, но судьбоносных добавлениях, я обычно привожу в пример одну историю (а точнее, небольшую фичу) еще из времен разработки «Сталинграда». Тем более что у нас был уже отрицательный пример про фичакрип, пусть теперь будет еще и положительный.
Особенностью этого проекта было то, что он был построен на движке Enigma от Nival (на этой же технологической базе был сделан и первый «Блицкриг») и являлся, говоря строго, не полноценным продуктом, а «тотальной конверсией» (разновидность игровых модов, при который вся «родительская» игра визуально изменяется и камуфлируется так, что получившийся результат лишь отдаленно на нее похож). Разработка «Сталинграда» шла прямо в поставляемом с «Блицкригом» редакторе, и поначалу никаких технических изменений команда не вносила, потому что даже не имела для этого программистов. Единственный случай технических работ на проекте «Сталинград» был связан с судьбоносными «двумя неделями программиста», которые достались мне от щедрот между большими апдейтами сайта для игровой индустрии The Daily Telefrag (не путать с современным сайтом DTF). Нужно сказать, что распорядился я этой «серебряной пулей» просто феерически удачно, но узнал об этой своей удаче лишь много лет спустя. Дело в том, что меня всегда бесила «фича» простреливаемости зданий в «Блицкриге» – это не давало создать классные танковые дуэли, когда танки выезжают из-за угла, стреляют и затем задним ходом пятятся (как игрок в серию Close Combat я очень уважаю такую тактику). Ну и я дал задачу нашему единственному программисту это дело исправить, а он взял и исправил всего за две отведенные недели. Поскольку движок «Блицкрига» был не в «полном 3D» (ландшафт карт был трехмерный, но на нем стояли плоские спрайты зданий и объектов), мы привязались к условной «площади зданий», задаваемой в редакторе спрайтов, и таким образом получили желаемую вещественность и непрозрачность для снарядов крупных объектов. Эта фича была запакована в файлик с алгоритмами поведения искусственного интеллекта юнитов для игры, и достаточно быстро о ней узнали мододелы. А затем именно этот «сталинградский» файл был использован в десятках модов, созданных за годы огромным сообществом поклонников франшизы. Всем хотелось иметь у себя эту фичу, а для этого надо было раздобыть заветный файлик, а значит – приобрести «Сталинград». Так игра почти случайно стала популярна в комьюнити «Блицкрига» на много лет вперед.
Как сделать хорошую игру, Способ № 22: И все-таки скажите «нет» фичакрипу. Точка. Отправьте его в wish-list, адд-он, сиквел. В общем, куда подальше. Почти всегда бесконтрольное раздувание функциональности – это то, что гарантированно ухудшит вашу игру.
Мы посетили один из кругов дантовского производственного ада и посмотрели на варящихся там в котлах дизайнеров-фичакриперов, самое время подвести итоги и дать сжатые рекомендации по теме мониторинга качества и проектных изменений в ходе разработки игры.
Говоря проще, как проконтролировать, что все делается правильно?
На самом деле у вас есть не так уж и много направлений, с которых вы можете приступить к этой задаче. Перечислим основные:
• система отчетности (принимающие решения управленцы должны быть своевременно проинформированы обо всех важных процессах, идущих в проекте);
• работа с коллективом (собрания, прозрачность команд, one-on-one и т. д.);
• личные усилия (регулярный мониторинг производящегося контента, будь то арт или код);
• ротации проектного персонала (практика, которая часто незаслуженно забывается, суть в том, что приходящие на проект новые люди часто вскрывают старые проблемы).
Когда говорят об изменениях игровых проектов, часто используют термин «пивот», означающий следующее:
Пивот (от англ. pivot – «вращение») – резкое изменение концепции стартапа с целью его дальнейшего развития и сохранения жизнеспособности. Может быть небольшим или радикальным. Впервые этот термин употребил предприниматель Эрик Рис – первопроходец движения «Бережливый стартап».
Как понятно из самого названия термина, он пришел из индустрии стартапов, которая, безусловно, является частью IT, но находится все-таки в соседней палате и отличается своей атмосферой. Скажу сразу, я против применения этой методики в разработке игр. Дело в том, что игра – это почти всегда крупный и сложный программный комплекс, и уже на достаточно ранних стадиях разработки она не вписывается в требования гибкости, крайне важные для стартапов.
Здесь опять можно привести морскую аналогию: типовой стартап – это драккар викингов, который из-за гибкости своего корпуса может выдержать морские волны и привести небольшую сплоченную команду стартапа к богатым берегам. А большой игровой проект – это океанский лайнер (ну ладно, будем реалистами, обычно это частный пароходик-лесовоз), ему достаточно сложно разворачиваться, и он конструктивно не приспособлен для ударов волной в борт – его просто перевернет. Часто именно это и случается, и, когда руководитель довольно сообщает коллегам по индустрии «мы сделали пивот и формируем новый план разработки, сроки сдвинутся на год», за этим стоит безрадостная картина: перевернутое или севшее на мель судно и команда, уныло бродящая по берегу и собирающая остатки груза. Запустить процесс «пивота» всегда можно, но если руководство само не контролирует этот процесс, то всегда рискует получить полную остановку производства и все сопутствующие с этим системные проблемы.