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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При низкой стоимости тестирования необходим краткосрочный горизонт планирования.

На начальном этапе проектирования боя я мог очень быстро скомпилировать и протестировать идею боя. Зачем тратить час на анализ идеи, если я могу создать и протестировать ее за 15 минут и получить гораздо больше информации? Оно того не стоит. Поэтому я не думаю слишком много, а просто делаю игру.

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

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