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

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

Письменный анализ

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

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

Дебаты

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

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

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

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

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

Тестирование

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

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

QA-тестирование выполняется специализированными тестировщиками и направлено на поиск технических ошибок. Оно важно в любом процессе разработки видеоигры.

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

Метрики

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

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

Кен Бердвелл пишет о своем опыте использования метрик для тонкой настройки Half-Life:

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

Когда в 1998 году был разработан Half-Life, занимаясь балансом, другие студии полагались на предположения и самостоятельное тестирование. Эти методы полезны на ранних стадиях разработки, но они не позволяют детализировать более подробные данные, необходимые для идеального баланса степени сложности. Благодаря метрикам качество дизайнерских решений принесло огромное преимущество разработчикам Valve. И им не нужно было быть умнее всех, чтобы создать лучшую игру, потому что они работали на свету, а все остальные работали в темноте.