Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше - [119]

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

Теперь мы еще больше увеличили цикл, включив в него другие дисциплины разработки. Текстовые окна заменяются на реальные диалоги. Звукорежиссеры передают атмосферу и звуки сцен. Мы ищем способы выразить нарратив о мире через игровое пространство. Писатели переделывают диалоги. Наконец, тестировщики справляются на отлично, мы исправляем технические неисправности и игра поставляется на рынок.

Это один из способов разработки шутера. Другие итерационные циклы могут значительно отличаться в зависимости от проекта и преследуемых целей. Этот конкретный процесс был основан на механике, поэтому начал его дизайнер боев, работающий над балансом и темпом. Для другой игры может потребоваться хороший нарратив, где сначала происходит итерация сюжета, а затем механики. Кроме того, существуют совершенно разные аспекты дизайна: дизайн персонажей, дизайн интерфейса и дизайн систем требуют разных методов. Некоторые будут представлять короткие циклы, сделанные одним человеком. У других будут длинные циклы продолжительностью в несколько недель с участием 10 разных специалистов. Некоторые разработчики тестируют игру в одиночку, другие тихонько наблюдают со стороны, кто-то использует метрики автоматизированного тестирования или отправляется в специализированные лаборатории.

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

Горизонт планирования

Сколько должен длиться итерационный цикл? Нужно ли тестировать игру каждый день? Каждую неделю? Каждый месяц?

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

ГОРИЗОНТ ПЛАНИРОВАНИЯ – это будущее время, на которое планируется работа.

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

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

Давайте рассмотрим некоторые более конкретные обстоятельства, которые влияют на горизонт планирования.

Шаблонные, производные игры могут иметь относительно долгосрочный горизонт планирования, потому что они зависят от имеющихся данных.

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

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

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

Исходные игры позволяют только краткосрочное планирование, так как они зависят от элементов, которые еще не были использованы.

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