Геймдизайн - Джесси Шелл

История

12. Руководство по сюжету игры (англ. Story Bible). Можно подумать, что история в игре определяется исключительно работающими над проектом писателями (если таковые имеются), но часто бывает так, что каждый из членов команды вносит осмысленные изменения в сюжет. Разработчику движка может показаться, что определенный элемент истории будет слишком сложно реализовать в техническом плане, и в связи с этим он может внести предложение об изменении этого элемента. У художника может возникнуть интересная визуальная идея для абсолютно новой части истории, которую писатель даже не мог себе представить. Геймдизайнер может придумать новую механику, потребующую изменения истории. Руководство по сюжету игры, в котором четко описываются все возможности и ограничения в мире вашей игры, упрощает задачу для желающих внести свой вклад и в итоге помогает создать сильный сюжет, согласованный с графикой, технологией и механиками.

13. Сценарий (англ. Script). Если неигровые персонажи (от англ. Non-Player Character, NPC) в вашей игре будут разговаривать, их диалоги должны быть где-то прописаны! Для этого нужен сценарий, который может быть как отдельным документом, так и дополнением к ГДД. Очень важно, чтобы геймдизайнер лично проверял все диалоги: существует высокая вероятность того, что некоторые реплики могут противоречить правилам игры.

14. Учебные пособия к игре (англ. Game tutorial and manual). В сложных видеоиграх игрокам необходимо обучение. Интерактивные инструкции в самой игре, интернет-форумы и печатные руководства – самые распространенные средства обучения. Крайне важно содержание этих обучающих материалов: игроки не смогут получить удовольствие от игры, которую не понимают. Скорее всего, детали дизайна вашей игры будут меняться вплоть до последнего момента разработки. Убедитесь, что кто-то в вашей команде постоянно проверяет содержимое учебных пособий и поддерживает их в актуальном состоянии.

Аудитория

15. Прохождение игры (англ. Game walth-through). Разработчики – не единственные, кто пишет документы об игре! Если игрокам нравится ваша игра, они будут писать собственные документы и выкладывать их в сеть. Изучая эти тексты, вы сможете в подробностях узнать, что им нравится, а что – нет, какие части игры слишком сложные, а какие слишком простые. Конечно, к тому времени, когда игроки напишут прохождение, скорее всего, будет уже поздно что-то менять, но вы можете использовать полученную информацию в следующий раз!

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

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

Daniel Cook: Game Design Logs. В этой отличной статье в своем блоге Lost Garden Дэн предлагает эффективные решения для проблемы поддержки документации в актуальном состоянии.

Stone Librande: One Page Designs. Этот доклад из GDC 2010 изменил игровую индустрию за одну ночь. Для всех было настолько очевидно, что метод, предложенный Стоуном, лучше всего подходит для создания обзора геймдизайна игры, что тот сразу стал индустриальным стандартом.

Слайды: http://www.stonetronix.com/gdc-2010/.

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

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

2. QA-тестирование. QA – это «гарантия качества». Это тестирование не имеет ничего общего с получением удовольствия от игры и заключается лишь в поиске багов.

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

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

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