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

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

Первым делом это очень высокоуровневый идеологический план, который также можно считать «концепцией проекта». Он указывает на некую точку в идеальном мире, в которую нам надо прийти (и описывает то, с чем мы должны туда прийти). Тут может не быть четких сроков, это план «примерно на год» (а по факту обычно на 1,5–2 года работы по трудоемкости). Эту точку очень важно иметь в сформированном виде и иметь впереди, независимо от стадии проекта. Даже имея уже выпущенную игру, необходимо, изредка поднимая голову между окончанием боевого пропуска и скидочной акцией, смотреть на этот свет далекой звезды, иначе проект утонет в оперировании, которое не равно его развитию. Наличие такой «сверхидеи» также будет вас немного страховать от фокусов конкурентов – в случае появления у них реализованной «звездочки» вам будет чем ответить.

Далее следует план на следующие 3–6 месяцев, назовем его достаточно условно «дорожной картой». Здесь самое важное – задать правильный «ритм проекта», то есть разбить часть глобальных задач из первого плана на адекватные возможностям именно для вашей команды куски. Делается этот план в зависимости от проектных мощностей отделов (сколько – одну, две или больше – крупных фичей в релиз могут себе позволить программисты, какое количество типового контента ежемесячно выдает арт-отдел, какова усредненная скорость работы дизайнеров карт/локаций и так далее). Крайне важно здесь задать именно ритм, то есть чередование периодов разработки, отладки и вывода версий проекта. Именно в этот план закладываются буферы на тестирование и отладку (без них будет происходить постоянное накопление задач и потребных исправлений, и все планы будут ехать).

Третьим пунктом у нас будет детальный план на следующий релиз, то есть уже тактический уровень документации. Это обычно табличка с фичами и оценками, сделанными на основании технических заданий. Это самый подробный этап планирования, который делается от оценок исполнителей, к которым добавляется буфер на всякие неожиданности. Он должен максимально полно описывать работу всей команды на ближайшие 2–3–4 недели (зависит уже от того, как плотно у вас релизы или версии).

Можно ограничиться этим, но хорошо, если еще есть свое планирование в отделах и оценки в общих планах являются результатом управленческой работы на местах, а не надиктовываются менеджерскому сословию голосами в голове. Самое главное – это все не очень большие документы, максимум на 2–3 странички. То есть вы с их помощью не только командой сможете управлять, но и ввести быстро в курс дела кого-то со стороны (нового сотрудника, партнеров, инвесторов).

Правильный выход из производственного ада (и вообще любые изменения в идущих проектах) заключаются в уменьшении объема работ, но почему-то повсеместно любое перепланирование приводит к противоположному результату – работы становится еще больше. Это еще один из парадоксов игровой индустрии!

Как сделать хорошую игру, Способ № 20: Примите за правило, что в процессе разработки вашего проекта его объем при перепланировании должен УМЕНЬШАТЬСЯ, а не увеличиваться. Уменьшение объема почти всегда дает возможность освободить ресурсы и подтянуть уровень качества. Помните, что игроки редко считают игры хорошими только за то, что эти игры большие. Качество всех элементов сильно важнее, тем более что судить вас будут по самому слабому из них.

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

Фичакрип, или «раздувание функциональности». К концу разработки выясняется, что для сдачи законченного продукта требуется реализовать все больше и больше функций, «и все они очень нужны». Это и есть фичакрип (англ. feature creep). Ходят легенды, что это главная причина невыхода программных продуктов и превышения бюджета.

Рассказ про это самое «раздувание функциональности» я начну с личных примеров для того, чтобы вы более явно увидели, как это вообще происходит (и почему помешать этому очень сложно).

Начнем с «9-й Роты», игры по одноименному фильму, которая вышла, кажется, в далеком 2008 году. О проекте «9-я Рота» рассказать можно коротко – мы взяли тактическую часть «Агрессии» и начали значительно ее дорабатывать. И все было бы хорошо, но тут сыграло роковую роль мое неуемное (на тот момент) желание сделать ролевую тактическую игру в стиле Fallout Tactics. Именно отсюда вышел «тактический экран оснащения», самая сложная и вредная фича проекта. Мне нужно было сделать задел «на будущее», и я спроектировал, а потом (пользуясь служебным положением) протащил в проект фичу несоответствующей ему глубины. В общем, проектная команда с моей тяжелой руки получила предназначенный для тактического отряда борцов с мутантами экран, где нужно было ручками снаряжать каждого персонажа вплоть до того, какие гранаты и магазины в какие карманы ему засунуть. Только в моем будущем пост-апокалиптическом проекте планировалось всего 6–9 персонажей в партии, а в «9-й Роте» под управлением игрока находился целый взвод Советской Армии, почти 40 человек. Но это досадное обстоятельство никого из нас тогда не смутило.

Как сделать хорошую игру, Способ № 21: Не загадывайте слишком сильно вперед, не пытайтесь заложить в текущем проекте какие-то идеи «для будущего». Конечно, нужно использовать весь свой опыт предыдущих проектов в последующих, это абсолютно нормально, но настоящее не должно страдать в угоду так и не случившемуся будущему. Та игра, над которой вы работаете сейчас, – безусловный приоритет!

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

Игра была достаточно реалистичной (все-таки частично это был идейный наследник «Сталинграда») и представляла возможность пройти набор миссий с достаточно глубоким погружением в этот мало известный в мире военный конфликт. Вот что нам пишет современная Википедия: «Игра посвящена 9-й роте 345-го отдельного гвардейского парашютно-десантного полка – элитному подразделению советского десанта, воевавшему в Афганистане весь период конфликта. Как и в картине, главные герои игры, вчерашние призывники, отобранные для службы в 9-й роте, пройдут