Как создать эффективный Game Design Document

В конце ноября 1992 года Том Холл, один из основателей id Software, закончил дизайн-документ для новой игры студии. В нём были сюжет и предыстория, герой по имени Бадди, военная база на планете Тей Тенга. Учёные открывают портал, оттуда лезут пришельцы, и пришельцы оказываются демонами. Документ назывался Doom Bible.

К началу 1993 года команда им почти не пользовалась. Джон Кармак считал, что сюжет в игре только мешает действию. Джон Ромеро хотел игру быстрее и жёстче Wolfenstein 3D. Уровни Холла остальным казались скучными, и летом 1993-го ему пришлось уйти из id. DOOM вышел 10 декабря. От библии в нём остались база и демоны, а сюжет уместился в руководство и несколько экранов текста между эпизодами.

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

GDD до сих пор часто называют библией проекта, а мне это слово не нравится. Библию не правят. Дизайн-документ, который не правят, умирает к первому плейтесту. Расскажу, как устроена моя документация и откуда я взяла её части.

Сто страниц

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

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

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

У каждого свой вопрос. Самый придирчивый читатель такого набора — человек, который пришёл в проект вчера. Он прочитает документ буквально, а переспросить в коридоре, решили мы это или нет, постесняется.

Видение

Видение занимает один файл. В нём есть адресат и пять-шесть пунктов «во что мы верим». Дальше идут фазы развития с метриками успеха, а в конце раздел о том, чего в игре не будет никогда.

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

Раздел «чего не будет никогда» работает как предохранитель. Его пишут, пока все помнят, зачем затевали игру. Через полгода очередная фича покажется хорошей идеей, и этот раздел напомнит, от чего команда отказалась сознательно. Формальный запрет проверяет скрипт. Он ищет запретные слова по всем текстам игры. Видение под таким присмотром не нарушишь нечаянно.

Метрики тоже стоит писать в видение, причём конкретные. «Игрокам нравится» не метрика. «Вернулся ли человек на третьей неделе» уже метрика: у неё есть день, когда её проверяют.

Реестр решений

Видение отвечает на «зачем». Реестр отвечает на «что мы решили». У каждой записи есть номер и дата. Ещё у неё есть источник, откуда пришло решение, и статус: «принято», «предложено», «отменено». Из реестра ничего не удаляется. Если правило отменили, строка остаётся на месте, у неё меняется статус, а рядом записана причина.

Программисты успели первыми. В 2011 году Майкл Найгард описал записи архитектурных решений, ADR: контекст, решение, статус, последствия. Реестр в геймдизайне устроен так же. Только записывает он правила игры.

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

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

Рядом с реестром живёт список открытых вопросов. Каждая развилка записана в нём вместе с тем, что стоит в игре прямо сейчас. Ответить можно одной строкой. После ответа пункт переезжает в реестр. Если бы каждый вопрос ждал автора, прежде чем кто-то сделает хоть что-нибудь, проект стоял бы неделями.

Карта экранов

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

Для каждого экрана записано, в каком он состоянии: есть только в макете, уже собран или сверен с макетом. Карта живёт, пока в неё возвращается всё, что нашли руками на плейтестах. Перестали возвращать — умерла.

Мастер-таблица

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

Главное правило такое. Контент растёт вниз, строками, а не вправо, колонками: рецепт из десяти ингредиентов записан десятью строками. Отдельный лист формулами проверяет ссылки между листами. Для игры таблица выгружается в JSON, поэтому число меняется без правки кода. Число, вписанное в код из головы, считается ошибкой.

У каждой строки есть статус, и один из статусов значит «не решено». Случайное число туда нельзя. Пустая клетка честнее правдоподобной выдумки, которая через месяц притворится решением.

Таблицу не читают. По ней сверяются.

Один лист

Для чтения нужно другое. Стоун Либранд, тогда креативный директор в EA/Maxis, на GDC 2010 показал доклад «One-Page Designs». Его мысль простая: длинные документы и вики не читают, а систему можно нарисовать схемой с короткими подписями на одном большом листе. Такой лист понимают за минуту.

Мне в этом подходе нравится ещё одно. Устаревшую схему видно сразу. Устаревший абзац на тринадцатой странице может врать годами.

Скотт Роджерс в своей книге о дизайне видеоигр предлагает похожую лестницу: сначала одностраничник, затем десятистраничник, полный GDD последним. Мне она служит проверкой. Если игра не помещается на одну страницу, десять страниц её тоже не спасут.

Кабала

Большой документ не обречён. Важно, кто его пишет и в какой момент. Хороший пример — Half-Life от Valve.

Осенью 1997 года стало ясно, что игра к назначенному сроку не готова и в таком виде не работает. Valve выбросила первую версию и собрала группу, которую назвали кабалой. В ней сидели три программиста и левел-дизайнер, а ещё сценарист с аниматором. Геймдизайнеров там не было. Кабала собиралась четыре дня в неделю по шесть часов, пять месяцев подряд.

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

Главная разница — авторы. Библию Холла писал один человек, пока игры ещё не было. Документ Half-Life писали шестеро разработчиков этой самой игры, люди разных профессий. За столом всегда сидел кто-то, кто знал, во что обойдётся чужая идея.

Вторая половина процесса — плейтесты. Наблюдатели Valve сидели за спиной игрока и молчали. Разрешалось только запустить игру и перезапустить её, если она упала. Двухчасовая сессия давала около сотни пунктов на исправление. Half-Life вышла в ноябре 1998 года.

Памятка

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

И один раздел я добавляю в любой документ: «слабое место». Документ, который сам называет своё слабое место, избавляет команду от поисков этого места в прототипе. Прототип найдёт его дороже.

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