Глава 11. Планирование и итерация

Как отмечает Ханс Гроте, строительный подрядчик, тренер по футболу не скажет кому-то из форвардов, что тот точно забьет гол, если на шестой минуте игры приблизится к воротам противника справа под углом 22 градуса и в 17 метрах от цели забьет мяч под углом подъема 10 градусов и 11 минут… Если тренер хочет определить позиции, с которых должен забивать каждый игрок команды, он должен помнить, что к бутсам может прилипать влажная земля. Комок грязи между бутсой и мячом может нарушить угол запланированного удара. Поэтому было бы разумно изучить средний размер комков грязи и частоту их появления, а также места на бутсах, где они прицепляются с наибольшей вероятностью. Но если учесть, что футбольные поля на севере, как правило, песчаные, а на юге – глинистые, нам нужно… Думаете, никто бы никогда не стал заниматься подобным? Стал бы еще как!

Дитрих Дернер

Перепланировщик

Вот вам история, которая случалась много раз.

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

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

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

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

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

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

Основная ошибка этого дизайнера в том, что он слишком много планировал.

Недостаточное планирование

А вот еще одна история, которая случалась много раз.

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

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

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

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

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

Основная ошибка этих разработчиков заключается в том, что они недостаточно планировали.

Недостаточное и чрезмерное планирование

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

К счастью, есть решение. Но прежде, чем мы его рассмотрим, мы должны рассмотреть проблемы с недостаточным планированием и чрезмерным планированием более подробно.

Цена недостатка планирования

Недостаточное планирование создает несколько характерных проблем.

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

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

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

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

Цена чрезмерного планирования

Существует распространенное убеждение, что небольшое количество лишнего планирования никому не помешает. Но это совсем не так. Чрезмерное планирование разрушает проекты разными способами.

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

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

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

Например, представьте, что согласно первоначальному дизайн-документу персонаж игрока может прыгнуть на 3 метра вверх. Согласно этому плану, дизайнер уровня строит уровень, ограниченный стенами высотой 3,3 метра. Если план правильный, все должно сработать, поскольку персонаж игрока не может преодолеть стену высотой 3,3 метра при том, что он может прыгнуть вверх только на 3 метра. Но затем дизайнер решает, что игра станет намного лучше, если персонаж сможет прыгнуть на 4,5 метра вместо трех. А вот теперь проблема. Либо нужно подгонять уровень для обработки 4,5-метровых прыжков, либо прыжок должен соответствовать запланированному изначально. Один из вариантов заставляет отказаться от хорошей работы. Другой – ухудшает игру.

И далеко не всегда все так просто, как в этом примере.

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

Геймдизайн выделяется среди современных творческих поисков тем, что в каждой системе заложена неопределенность.

Как сказал Сорен Джонсон, ведущий дизайнер Civilization IV: «Быть геймдизайнером – значит быть неправым». Дизайнер может только догадываться, как будет работать система или уровень, но он никогда не сможет сказать это наверняка. Обычно когда игра готова, игровая система работает совсем не так, как предполагалось. Вот почему отличные игры склонны значительно меняться в процессе разработки.

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

BioShock – это исследование подводного города, построенного в стиле ар-деко. Город под названием Восторг был попыткой создания утопии, основанной на принципах философии объективизма Айн Рэнд. Персонаж игрока прибывает в город в 1960 году, утопия потерпела крах, и Восторг погрузился в гражданскую войну. Игра прославилась этим богатым и уникальным нарративом о мире. Но с самого начала события игры BioShock происходили не под водой и не имели ничего общего с Айн Рэнд. Это была научно-фантастическая игра на космическом корабле. Позже они переместились в заброшенный нацистский бункер, кишащий мутантами. Прошло всего несколько лет, и игра превратилась в подводный город в стиле ар-деко и обрела свою тему объективистский утопии. Дизайнеры не планировали этот мир на бумаге; они разработали его за годы работы над самой игрой.

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

Меняется весь дизайн, как это случилось с Halo, BioShock и The Sims. Но даже самый маленький кусочек игры может преподнести сюрпризы. Например, когда я работал над уровнями головоломки в загружаемом контенте для BioShock, в моем уровне была комната с рядом ракетных пусковых установок вдоль стены. Я хотел, чтобы игроки о них узнали, но чтобы при этом их не убило. По этой причине я использовал старый трюк сообщения игроку об опасности: когда он входил в комнату, появлялся враг и бежал на игрока только для того, чтобы ракетные пусковые установки его обстреляли. Отлично сработало. Враг кричал и взрывался. Проблема казалась решенной. Потом я смотрел, как кто-то другой проходит этот уровень. Он вошел в комнату. Враг закричал и побежал на него; так как это был уровень головоломки, у игрока не было оружия. Поэтому он повернулся и выбежал из комнаты, чтобы убежать от врага. Мне пришлось создать вокруг игрока непробиваемое стекло, чтобы он чувствовал себя в безопасности, не отступал и наблюдал за происходящим.

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

ИТЕРАЦИЯ – это практика составления краткосрочных планов, их реализации, тестирования и повторения.

Итерация

Мы не можем вообще не планировать, но мы также не можем планировать каждую деталь до конца проекта. Нам нужно нечто среднее. Нам нужна итерация.

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

Итерация работает иначе. Действия выполняются не поочередно, а циклично.

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

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

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

Пример итерации

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

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

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

Бой больше не прокручивается в воображении. Он вполне реален. Когда человек играет в настоящую игру, держа руки на джойстике, слыша тикающий секундомер, у него возникают мыслительные процессы, которые невозможно воспроизвести любым другим способом. Эта первая версия игры и не должна быть похожа на конечный продукт. Ее единственная цель – стать стартовой платформой к чему-то менее ужасному.

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

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

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

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

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

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

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

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

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

Проведя один плейтест, я пишу список задач, которые нужно решить. Некоторые из них простые (лучше осветить врага, чтобы люди могли его видеть). Другие более сложные (реструктурировать маршрут слева, чтобы его могли использовать как игроки, так и враги). Я приступаю к работе. Спустя полдня изменения внесены, и я готов к следующему плейтесту. Я нахожу кого-то, кто еще не проходил этот бой, и смотрю, как он играет.

Цикл повторяется еще 10–20 раз. К концу цикла проходит две или три недели. Бой идет в хорошем темпе, хорошо сбалансирован и подходит игрокам разных уровней мастерства и с разными игровыми привычками. Мне не нужно догадываться, как будут развиваться события, когда игра попадет к реальным игрокам, потому что я уже и так это знаю благодаря тестировщикам. Но это все еще не похоже на готовую игру – повсюду вы видите плоские серые формы. Самое время художникам вступить в бой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соответствующий горизонт планирования склонен увеличиваться в течение срока проекта.

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

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

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

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

Планируйте более глубоко, если вы ставите своей целью новаторство.

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

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

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

Избыточное планирование: причины

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

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

Привычка, заложенная культурой

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

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

Но геймдизайн отличается, потому что в нем больше неопределенности. Архитекторы плотины Гувера не могли на полпути вдруг решить, что плотина должна была стать небоскребом. Но разработчики Halo обнаружили, что их стратегия, спроектированная по принципу «сверху вниз», должна стать шутером от первого лица. И, как мы уже убедились, такого рода радикальная трансформация не является необычной.

Врожденная самоуверенность

Давайте поиграем в игру об уверенности. Я задам вам десять вопросов, ответы на которые – цифры. Ваша задача – дать завышенные и заниженные оценки так, чтобы по каждому вопросу вы были на 90 % уверены, что ответ попадет в пределы диапазона, который вы указали.

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

Я настоятельно рекомендую вам взять карандаш и записать свои ответы. Это упражнение работает не так хорошо, если его только прочитать.

Теперь сверьте свои ответы с ответами в конце книги. Что у вас получилось?

Обратите внимание, что ваш результат теста никак не связан с вашими знаниями географии или истории. Чтобы ваш уровень достоверности составил 90 %, вы можете задать любой диапазон, какой только захотите. И если вы это сделали, то почти наверняка получили 8, 9 или 10 ответов, которые попали в предел вашего диапазона.

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

Когда я решал аналогичный тест в книге Стива Макконнелла «Software Estimation: Demystifying the Black Art» (Microsoft Press), я ответил правильно на четыре вопроса. Макконнелл давал подобные тесты сотням профессиональных оценщиков. Это были люди с многолетним опытом оценки сроков реализации проекта и затрат на программные проекты. Даже среди этой элитной группы Макконнелл обнаружил, что фактически менее 1 % тестируемых отвечают правильно на девять вопросов, которые мы должны ожидать от объективной оценки. Более 90 % из них получили пять или менее правильных ответов. Почему так произошло?

Людям присуща самоуверенность.

Психологи называют это оптимистическим уклоном. Что-то в психологии человека приближает доверительную оценку в 90 % к доверительной оценке в 30 %.

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

Подобная необъективность имеет огромные последствия в планировании в геймдизайне. Иными словами, без поправки дизайнер будет уверен в своем дизайне на 90 %, хотя на самом деле шанс, что дизайн будет рабочим, составляет всего 30 %. Так складывается огромный разрыв между ожиданиями и реальностью. Такая самоуверенность заставляет нас думать, что мы можем планировать то, что на самом деле не сможем реализовать. Мы читаем дизайн-документ и думаем, что проект будет работать, хотя вероятность того, что он будет работать именно так, как мы ожидаем, является достаточно низкой. Это толкает нас в сторону избыточного планирования.

Терапевтическое планирование

Вспомните выражение «чувствовать неуверенность». Технически быть неуверенным – значит не иметь определенной информации. Но фраза «чувство неуверенности» перегружена негативными эмоциональными оттенками. Мы рассматриваем неуверенного человека как неспособного и неэффективного. Если мы неуверены, то представляем себя нервными и подавленными. Неуверенность эмоционально неприятна. Ответная реакция на неопределенность часто заключается в желании скрыть неопределенность за терапевтическим планированием.

ТЕРАПЕВТИЧЕСКОЕ ПЛАНИРОВАНИЕ – это планирование не для координации работы, а для того, чтобы мы не беспокоились о неизбежно неопределенном будущем.

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

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

Групповая ошибка планирования

Представьте двух человек, Уверенного Боба и Рациональную Алису, в группе, которая пытается угадать погоду. Рациональная Алиса смотрит на небо и точно помнит, что во всех случаях, когда она видела аналогичные сочетания погодных условий, дождь шел почти половину всего времени.

«Я понятия не имею, пойдет дождь или нет, – говорит она. – Как бы то ни было, мы не можем знать наверняка».

Люди поощряют чрезмерную уверенность и ценят ее выше, чем рациональные сомнения.

Теперь выходит Уверенный Боб. Он недолго смотрит вверх, улыбается, словно наслаждаясь шуткой, понятной только ограниченному кругу людей. Он поворачивается к группе и уверенно объявляет: «Дождя не будет. Не беспокойтесь».

Группа естественным образом выбирает Боба. Боб получает последователей, одобрение и социальный статус. Алису называют слабой, глупой, нерешительной или ленивой, хотя ее ответ и был более точным.

Это групповая ошибка планирования. Люди естественным образом тянутся к лидерам, которые, как им кажется, уверенно смотрят в будущее, даже если это ви́дение будущего не соответствует реальности.

Чтобы не попадаться на эту удочку, достаточно поймать Боба на том, что он оказался неправ. Как только это случится несколько раз, люди перестанут его слушать. Но такие выводы в геймдизайне не так очевидны, как в прогнозе погоды. В геймдизайне трудно сразу связать причину и следствие, результаты могут проявляться годами, и за это время происходит так много, что мы забываем о своих прогнозах. В обычной жизни, когда мы можем оценить результат такого «предсказателя» практически сразу, наши инстинкты в конечном итоге заставляют нас не доверять Уверенному Бобу. Но в современных задачах дизайна происходит иначе. У нас нет такой подушки безопасности. Таким образом, стереотипы относительно Уверенных Бобов остаются, а подушка безопасности (проверка результатов) – нет. Стереотипы не сбалансированы.

Если мы не будем бороться с этим эффектом, люди пойдут за более уверенным лидером, а не за тем, кто прав. Неопределенность скрывается за бравадой, и начинается избыточное планирование.

Эффект хиндсайта

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

ЭФФЕКТ ХИНДСАЙТА (склонность к запоздалым суждениям) – это когнитивные искажения, которые незаметно перестраивают воспоминания, чтобы прошлые события выглядели так, как будто они были более предсказуемыми, чем на самом деле.

В 1972 году исследователь Барух Фишофф спросил людей, что может произойти во время предстоящей дипломатической поездки президента Никсона в Китай. Будет ли Никсон встречаться с Мао Цзэдуном? Произойдет ли значительный дипломатический прогресс? Он спросил о вероятности этих событий, а также о 13 других.

Когда Никсон вернулся, Фишофф снова попросил тех же людей сказать, с какой вероятностью событие будет иметь определенный исход. Эффект хиндсайта был очевиден. Если чей-то прогноз оказывался верным, человек говорил, что был увереннее в своем ответе, чем это было на самом деле. Если же прогноз оказывался неверным, то он преуменьшал степень своей уверенности. Они скорректировали свои воспоминания, преувеличивая свою способность предвидеть, как все произойдет. Постфактум процесс разработки игр всегда выглядит более логичным и контролируемым, чем это было на самом деле. Наш мозг автоматически редактирует хаос процесса разработки, превращая его в нашей памяти в чистую историю. Когда мы рассказываем о нем другим, мы еще сильнее осуществляем упрощение. Бесплодная трата времени время на тангенсы, бездумные ошибки, ужасные недопонимания и монотонные дни оттачивания работы – все это отпадает, а история становится детской сказкой. На самом деле я описал подобные истории в этой книге.

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

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

Протокол тестирования

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

Цель плейтестинга состоит не в том, чтобы выявить технические проблемы или собрать данные о маркетинге, а в том, чтобы понять, как работает геймдизайн в действии. Это значит, что нужно дать поиграть в игру обычным людям и посмотреть, где дизайн работает, а где – нет. Где игроки в замешательстве? Где слишком легко или слишком сложно? Достаточно ли сбалансирована игра? Есть ли вырожденные стратегии? Понимают ли игроки нарратив?

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

Ключом к получению достоверных данных является использование правильного протокола тестирования.

ПРОТОКОЛ ТЕСТИРОВАНИЯ – это набор правил и процедур для проведения плейтеста.

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

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

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

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

Давайте рассмотрим основные протоколы тестирования.

Самостоятельное тестирование

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

Плейтестинг «через плечо»

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

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

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

Это правило неудобно с социальной точки зрения. Если игрок смущен или расстроен, для него такая игра может быть попросту болезненной. Каждый опытный дизайнер наблюдал, как игрок застревал минут на пятнадцать в поисках двери или кнопки. Вы отчаянно хотите подсказать игроку: «Вот же она! Просто нажмите синюю кнопку!» Но так вы испортите весь тест, дав тестируемому ту информацию, которой не будет у реальных игроков. Это уже будет не тестирование игры, а ее странная версия, в которой дизайнер приходит в определенное пространство и раздает советы. Тесты могут идти более или менее гладко, но только потому, что недостатки скрыты.

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

Как выбрать тестировщиков

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

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

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

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

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

Размер выборки

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

Хорошие решения могут быть приняты только в том случае, если дизайнер понимает все возможные опыты, которые может генерировать игра. Это предполагает множество плейтестов.

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

Чтобы добиться реального прогресса, мы должны решать задачи с одним опытом, не вызывая проблем в другом месте. Это невозможно, если мы увидели только один или два потока, в которые игроки могут попасть. Мы должны знать все, что игра дает игрокам. Тогда мы сможем выбрать подходящие решения.

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

Для этого нет готового списка плейтестов. Разные игры генерируют разный опыт, поэтому некоторые из них нужно тестить дольше, прежде чем дизайнер сможет их понять. Для очень простой, ограниченной игры может потребоваться от двух до трех плейтестов. В боевом шутере – обычно от 6 до 12 плейтестов. В неограниченных системных играх необходимое количество плейтестов может быть весьма большим.

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

Методика опроса

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

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

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

Мой любимый вопрос, который я задаю после тестирования, звучит примерно так: «Расскажите историю о том, что только что произошло в игре». Этот вопрос на проверку памяти. С его помощью можно выяснить, какие особенности игры игрок понял, запомнил и посчитал достаточно важными, чтобы их упомянуть. Вещи, которые он не упоминает в своем рассказе, могут быть баластом дизайна. Часто я обнаруживал, что история, которую помнят игроки, очень отличается от того, что я написал, или от того, что произошло на самом деле.

Дизайнер также может адаптировать вопрос, чтобы определить, понял ли игрок конкретную вещь. Не стоит спрашивать: «Вы заметили дверь слева?», потому что сам вопрос дает игрокам подсказку и ответ может быть необъективным. Они чаще всего отвечают «да», просто чтобы не выглядеть глупо или понравиться интервьюеру. Лучше спросить: «Расскажите мне, почему вы выбрали этот путь». Тестировщик либо упомянет про дверь слева и объяснит, почему он не вошел в нее, либо промолчит. В первом случае это говорит о том, что ее заметили и проигнорировали, а во втором – что ее могут вообще никогда не заметить.

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

Тестирование методом «серого ящика»

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

«СЕРЫЙ ЯЩИК» – это черновой прототип игровой механики, системы или уровня.

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

Когда компания-разработчик BioWare создала Mass Effect 3, дизайнеры тестировали существ методом «серого ящика». На раннем этапе разработки гигантский боевой робот представлялся в виде большого куба с двумя длинными прямоугольниками внизу и двумя кубами, прикрепленными к бокам для оружия. Другой враг – высокий желтый блок – хватал героя с длинными желтыми блоками, прикрепленными к бокам. Это выглядит странно, но именно так и происходит. Эти «серые ящики» позволили дизайнерам BioWare тестировать и итерировать свои работы, не вкладывая средства в графику непроверенных проектов.

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

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

Что не нужно тестировать методом «серого ящика»

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

Поэтому чем более аудиовизуально насыщенным является игровой опыт, тем менее полезным становится тестирование методом «серого ящика». Такие игры, как LIMBO и Flower, сильно пострадают в «сером ящике», поскольку в основном они основаны на аудиовизуальных эмоциональных триггерах. Однако этот метод весьма хорошо подходит для Counter-Strike и StarCraft II, так как эти игры всегда были основаны на механике.

Преждевременный продакшн

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

ПРЕЖДЕВРЕМЕННЫЙ ПРОДАКШН – преждевременное добавление дизайнером графики и звука к дизайну «серого ящика» для того, чтобы получить следующий набор контрольных данных.

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

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

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

Навык оценки «серого ящика»

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

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

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

Миф о сценарии

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

Ближайшим эквивалентом сценария в геймдизайне является не дизайн-документ, а рабочий прототип «серого ящика».

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

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

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

Парадокс качества

В геймдизайне временное принятие некачественной работы в конечном итоге приводит к более качественной работе. Это ПАРАДОКС КАЧЕСТВА.

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

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

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

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

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

Ошибочность видения

Молодой инженер авиационной и космической промышленности в свой первый рабочий день заходит в кабинет начальника с блеском в глазах и заявляет: «У меня есть гениальная идея для нового типа самолета».

Босс заинтригован.

«Говори», – отвечает он.

Молодой инженер задумчиво смотрит вдаль.

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

Босс откидывается на спинку стула и затягивается сигарой.

«Уволен», – говорит он.

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

ОШИБОЧНОСТЬ ВИДЕНИЯ заключается в приравнивании воображаемого образа опыта к дизайну системы, которая создает этот опыт.

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

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

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

Видение может быть обманчивым и определять опыт. Но игра – это не опыт, это система создания опыта. Точно так же, как не стоит путать идеальный полет с идеальным самолетом, также не стоит путать видение отличного игрового опыта для создания великолепной игры.

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

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

Серендипность

Есть известные известные – вещи, о которых мы знаем, что знаем их. Есть также известные неизвестные – вещи, о которых мы знаем, что не знаем. Но еще есть неизвестные неизвестные – это вещи, о которых мы не знаем, что не знаем их.

Дональд Рамсфелд

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

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

Большинство действительно важных вещей в разработке игр возникают из неизвестных неизвестных.

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

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

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

Например, прародителем видеоигр в жанре RPG является Dungeons & Dragons. D&D генерировала большую часть своего наполнения из своих ролевых элементов, так как позволяла игрокам вербально разыгрывать любую фэнтезийную историю, какую они только могли представить. Как только компьютеры стали способны генерировать аналогичный опыт, D&D преобразовали в видеоигру Rogue. Rogue отображает карту подземелья в текстовой графике. Игрок управляет героем, который исследует просторы сгенерированного случайным образом подземелья, убивая монстров, набираясь опыта и собирая древние сокровища. На первый взгляд Rogue может показаться довольно близкой компьютеризированной версией D&D. Но она создает опыт совсем другим способом. D&D работает в основном через ролевое взаимодействие и социализацию, а Rogue – через эмергентную историю и получение награды по графику. В свое время это были революционные достижения в геймдизайне. Но дизайнеры Rogue этого не планировали. Пытаясь скопировать опыт D&D, они наткнулись на силу режимов подкрепления и эмергентный нарратив, стимулируемый апофенией. Игра работала фантастически по причинам, которые ее создатели никогда не смогли бы предсказать.

Серендипность не является чем-то необычным. Знаменитый персонаж Большой папочка в BioShock изначально был мутантом в водолазном костюме; добавление слабых Маленьких сестричек привело к созданию очаровательных взаимоотношений между огромным големом-отцом и маленькой девочкой-дочерью. Голос GLaDOS в игре Portal, одного из самых популярных игровых персонажей, стал роботизированным только когда Эрик Волпо заметил, что людям больше понравился «серый ящик» в исполнении синтезатора голоса. Безупречный финальный уровень Braid разработчики обнаружили, когда игра была практически закончена, Джон Блоу понял, как он мог использовать механику, сдвигающую время, чтобы обратить вспять не только время, но и персонажа. Игра Tetris появилась из компьютерной версии традиционной русской игры-головоломки «Пентамино».

The Sims были разработаны на основе симуляции архитектуры, когда Уилл Райт заметил, что игрокам нравится играть с персонажами больше, чем строить дома. Даже изначальный хит Райта SimCity был разработан, когда он заметил, что ему нравится создавать карты для вертолетных боев больше, чем взрывать их.

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

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

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

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

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

Геймдизайн – это не просто процесс авторства. Это также процесс наблюдения и открытия.

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

Вера в итерацию

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

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

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