Примеры дизайн-документации
В связи с тем, что одна из самых сложных и не всем дающихся областей работы геймдизайнера - это дизайн-документация, многие меня просят показать примеры тех документов, о которых я говорила в своих статьях и уроках. Попробую ответить на все просьбы в этой статье.
Излагать свои мысли четко, внятно, структурировать их так, чтобы другому специалисту без болезненного вчитывания легко удалось ухватить суть - это непросто. Навык писать документацию приходит с опытом, и причем не только с опытом непосредственно написания, а в том числе и с опытом давания этой документации на прочтение, а также чтения документации чужой.
Дело в том, что дизайн документация - это что-то сугубо личное и особенное для каждого специалиста. У каждого есть свой метод, который зависит от многих факторов: как и от личных пристрастий, так и от коллектива, в котором геймдизайнер работает.
Первое: какая разница, каким способом, с помощью каких материалов и в каком стиле вы доносите свою мысль, если это удобно вам и понятно окружающим?
Второе: если вы уже пришли на чужой, живущий до этого своей жизнью проект, то какая разница, каким образом вы умеете блестяще писать дизайн документацию, если на проекте принят другой формат?
В таком случае можно задать резонный вопрос: зачем я вообще пишу эту статью, если дизайн-документация - это дело настолько индивидуальное? Фишка в том, что тут нужна некая отправная точка, от которой уже вы сами будете отшлифовывать и отрабатывать свой собственный стиль. И в этой статье я попробую вам такую отправную точку дать.
Итак, я сделала два документа: дизайн-документ и питч. Остальные, о которых я говорила в этом видео, в общем и целом, вы сможете смоделировать сами, поняв принципы этих двух. Я написала документацию по уже существующей игре, которая называется Tap Titans 2 - это довольно-таки интересный мидкорный кликер.
Важный момент: перед тем, как читать дизайн документы, поиграйте в эту игру пару дней, чтобы лучше понять, как описаны те, или иные механики.
Tap Titans 2 на Google Play
Tap Titans 2 в App Store
Ну, поехали.
Питч
Тут, в принципе, все понятно, если смотреть по очереди то на питч, то на содержание этой и вот этой статьи. При написании питча важно помнить, что человек, который его будет читать, понятия не имеет о вашей игре, и, скорее всего, вообще не очень заинтересован в том, чтобы что-то читать и во что-то вникать. Поэтому меньше деталей, имен, тонкостей, непонятных слов, несущественных нюансов. Напоминаю главные правила:
1. Предложения должны быть короткими и емкими. Несколько раз подумайте, прежде чем утвердить очередное свое предложение.
Сравните два отрывка:
“Когда игрок нажимает на монстра, он наносит ему урон. Когда у монстров заканчивается здоровье, они умирают, а еще есть герои, которых игрок может нанимать, которые располагаются по двум сторонам экрана и сами по себе наносят урон, игроку не надо тапать”
“Игрок убивает монстров, тапая по экрану, а также покупая армию героев, которые формируют урон в секунду.”
2. Все, что вы говорите, должно быть вкусно, приятно читать.
Сравните два отрывка:
“Питомцы. Это такие сущности, которые тоже наносят урон монстру, когда игрок тапает на экран, а также они обладают своими пассивными навыками”
“Питомцы. Огромный набор питомцев, которые наносят урон, когда игрок тапает, и обладают собственными уникальными пассивными способностями”
3. Все, что вы пишите, должно быть разбито на списки и классификации. Даже если человек не захочет читать весь текст, он прочитает первые несколько слов в строчке и поймет общую суть.
Сравните два отрывка:
“Модель free-to-play. Продажа паков премиум валюты, которую игрок может потратить на покупку бустеров, которые действуют определенное количество времени, добавляя игроку новые возможности и существенное преимущество в бою, а еще на покупку сундуков с рандомными ценными наградами и на покупку питомцев.”
“Модель free-to-play. Продажа паков премиум валюты, которую игрок может потратить на:
- покупку бустеров, которые действуют определенное количество времени, добавляя игроку новые возможности и существенное преимущество в бою;
- покупку сундуков с рандомными ценными наградами;
- покупку питомцев.”
Дизайн-документ
Я уже упоминала, что я люблю вести дизайн-документацию в таблицах - по ним удобно ориентироваться и в них удобно писать. Но можно также и в обычных текстовых документах, делая каждый документ - описанием отдельной механики.
Первая страничка дизайн-документа - это оглавление.
Тип
Впоследствии механик может быть много, поэтому я разбиваю их на типы. Например, “Игровые валюты”, “Персонаж” и так далее. Даже если будут такие типы, в которых только по одной механике - это не страшно.
Название механики
Здесь - непосредственно сама механика. Краткое ее название, которое в то же время будет описывать ее суть.
Ссылка
Если документ разрастется, то будет тяжело ориентироваться между вкладками, поэтому лучше использовать внутренние ссылки.
Статус
Тут все понятно: описано / не описано / в процессе.
Описание
Очень удобный раздел, в котором надо как можно короче дать ответ на вопрос “что это такое”. Пригодится для того, чтобы новый человек лучше ориентировался в вашем документе и быстрее разобрался с игрой. Тут тоже не всегда можно дать четкое определение, но это не страшно.
Обновлена
Некоторые механики устаревают, и когда работы много и она совершенно разная, можно легко забыть, что вы уже обновляли, а что нет. Иногда будет просто полезно пробежаться по датам и перечитать самые старые механики на предмет актуальности.
Автор
Если на проекте работают несколько геймдизайнеров, будет понятно к кому обращаться с вопросами по тексту.
Комментарий
Это поле для каких-то заметок и напоминаний. Если другой геймдизайнер будет читать этот документ, он сможет задать тут вопрос. Также и вы можете оставить памятку для себя, или какое-то пояснение.
Содержание дизайн-документа
Каждая вкладка в табличном дизайн-документе - это описание конкретной механики. С опытом я поняла, что описывать механики лучше тезисно. Короткими, емкими предложениями. Даже если это один абзац текста, относящийся к одному и тому же предмету, то все равно, чаще всего, его можно разбить на конкретные, законченные мысли. Такой стиль написания документов удобен потому, что читающий получает информацию порционно: он прочитывает короткое предложение и думает про себя: “ну окей, кажется все понятно, поехали дальше”.
Нумерация строк призвана облегчить обсуждение документа с другими людьми. Например, если вы будете разговаривать с человеком, работающим удаленно, или у специалиста возникнет короткий вопрос, ему достаточно будет просто спросить: “У тебя в пункте 1.3 написано то-то, можешь мне пояснить вот этот момент”.
Еще таблицы удобны тем, что можно легко выделить какую-то строку и с помощью цветовой дифференциации отметить спорные моменты, или моменты, которые хочется обсудить.
В столбце “Комментарий” можно сделать пометку, или указать ссылку, ведущую к материалам по теме.
Также я добавляю к каждой странице ссылки, которые ведут к механикам, упоминаемым в описании. В таком урезанном варианте документа это выглядит немного комично, но когда документ у вас большой, ссылки будут вести не только на соседние странички, но и по всему документу с механиками, а зачастую и на совершенно другие документы.
Надеюсь теперь дизайн-документация стала для вас прозрачнее и вы, взяв за основу мои идеи, сможете изобрести удобный для себя способ ее ведения.