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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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