Рабочий дизайн-документ, который будут читать
Рабочий дизайн-документ - это вещь, безусловно, нужная и полезная. Дизайн-документ помогает дизайнеру сосредоточить все важные игровые знания в одном месте, а также не забыть никакое из принятых решений. Тем не менее, мнение о том, что гейм-дизайнер засядет за многостраничный труд всей своей жизни, чтобы потом, закончив его, передать команде, и тут бац - получается игра - ошибочно. Чаще всего бывает так: дизайнер пишет огромный документ, который никто не читает, зачастую, даже сам дизайнер, и в итоге этот документ забрасывается по причине ненадобности. Вот тут-то и начинается черти что, когда дизайнер не может предоставить никакого письменного описания концепции, которую он разрабатывает.
Очень часто случается так, что вся команда работает в вакууме: художник что-то рисует, а что и зачем - не знает, программист реализует какую-то механику, а зачем она нужна - понятия не имеет. Конечно, отсутствие документации - это не единственная проблема в такой команде, но все-таки одна из наиболее острых. Хороший дизайн-документ - это средство письменного общения между дизайнером и командой. В идеале, дизайн-документ должен быть понятен и интересен любому члену команды, чтобы гейм-дизайнер не работал в вакууме, а постоянно получал фидбек от команды, чтобы описанная им концепция подвергалась здоровой критике и обсуждению, а также чтобы в нее могли быть внесены новые идеи и предложения.
Итак, секрет хорошего дизайн-документа в том, чтобы разбить его на несколько дизайн-документов. Не нужно все валить в одну кучу, у игры есть множество аспектов, каждый из которых заслуживает отдельного внимания. Единого рецепта по созданию идеального дизайн-документа не существует. Все, конечно, очень сильно зависит от того, как структурирована работа отдельной компании. Я опишу более или менее стандартный вариант ведения документации и постараюсь пояснить, почему необходим и важен тот или иной документ.
Тематический список дизайн-документов
1, Документ по игровым механикам
Пожалуй, самый большой и сложный из всех документов - полное описание механик вашей игры. Сразу скажу: ни в коем случае не надо пытаться написать весь документ сразу, и проработать каждую деталь. Здесь надо идти от общего к частному: сначала можно выделить группы механик, например: “база”, “строительство”, “юниты”, затем уже разделить их на отдельные подразделы, которые потом также можно будет разделить на подразделы и так далее. Не стоит особо увлекаться мелочами на первых порах. Нельзя в начале разработки в деталях описать игру, да это и не нужно: ведь для начала необходимо собрать простые прототипы игры и посмотреть, действительно ли реализация задумки похожа по ощущениям на то, что планировалось? Зачем описывать десятки механик до мелочей, чтобы потом одним махом вычеркнуть их на самом старте разработки?
Формат документа остается на ваше усмотрение: возможно это будет табличный экселевский док с множеством страниц, а может это будет множество текстовых документов в отдельной папке на вашем гугл диске - это индивидуально. Главное - это сделать документ понятным для команды, чтобы при желании или необходимости любой ваш коллега независимо от своей специальности мог понять о чем идет речь. Таким образом, я предлагаю в описании каждой механики иметь следующие пункты:
а) Название механики, общее описание (один абзац общего пояснения что это и зачем).
Собственно, это практически единственный пункт, который стоит заполнить в начале работы с документом. Впоследствии общее описание пригодится для беглого ознакомления с идеей, а также, например, для задач художников: стандартное описание “как выглядит” дает большой простор для творчества и идей, если это описание идет в комплекте с “что делает и как”.
б) Техническое описание (детальное описание работы механики со всеми возможными вариантами ее поведения).
Это описание можно использовать впоследствии для постановки задач программистам, также это будет удобно для обсуждения технических возможностей вашей игры. Этот пункт можно дописать, когда механика уже запланирована к реализации. Он пишется, обсуждается с программистом, по результатам обсуждения вносятся коррективы и ставится задача.
в) Визуальные референсы (можно заменить на отрисованные объекты, когда такие появятся).
Этот пункт поможет проиллютрировать вашу идею для коллег. когда слов недостаточно, или вызвать какие-то ассоциации. К тому же, данный пункт будет хорошей помощью для художника. Также, это прекрасное место для идей, иногда подходящий визуальный референс наводит на мысли о доработке механики в лучшую сторону.
г) Ссылки (на другие механики, задачи, связанные документы). Нужны для того, чтобы видеть весь вопрос в комплексе и быстро ориентироваться внутри документации проекта.
2. Документ с сюжетом и описанием персонажей
Документ свободного оформления. Все зависит от того, насколько большой в вашей игре упор на сюжет. Если сюжет объемный, то обязательно нужно разделить документ на два части - в первой написать краткие синопсисы для команды и для быстрого ознакомления, а уже потом расписать все детально.
3. Документ с квестами (если таковые имеются)
Структура этого документа тоже зависит от технических особенностей проекта. Как правило данные из таких документов вручную или автоматически переносятся потом в конфиги, поэтому наиболее удобную структуру вы найдете сами. Что там должно быть - так это классические название, описание, условия, награды, диалоги, следующий и предыдущий квест цепочки, квестгивер и так далее (нужное подчеркнуть).
4. Документ с игровым балансом
Большая табличка со сложными сложными формулами. Некоторые программисты налаживают портирование данных их таблиц с балансом в конфиги игры (шутка ли, поменял один коэффициент - забивай сто значений вручную). Поэтому этот документ структурируется согласно требованиям от программистов.
5. Документ с требованиями к арту (и анимации)
Этот документ пишется арт лидом и программистом совместно. Как правило, при отрисовке арта для игры любой художник должен учитывать две вещи: технические требования и визуальные. У любой игры есть свой стиль арта. и когда над проектом работают несколько художников, они все должны рисовать в одном стиле, в том, который определен для игры. Поэтому арт лид должен собрать все отличительные особенности стиля арта в этом документе и описать их наглядно и с примерами. От программистов же надо получить список технических требований к арту: размеры, форматы и прочее.
6. Документ с идеями для обсуждения
Во время тестирования прототипа или самой игры, а также во время брейнштормов очень часто рождаются интересные незапланированные идеи, терять которые ужасно жалко. Поэтому, силами озаренных или силами самого гейм-дизайнера эти идеи неплохо собирать в одном месте, чтобы в дальнейшем выбрать самые ценные и подумать над их реализацией.
7. Документ с описанием интерфейса и его макетами (хотя бы простейшие схемы)
Практически каждая новая игровая механика требует поддержки интерфейсом. План работ по интерфейсу как правило большой и сложный, поэтому список интерфейсов с кратким описанием, простейшими макетами и ссылками на соответствующие механики всегда очень кстати. К тому же, такой документ позволит проверить все ваши интерфейсы на общность и откорректирвать их еще на стадии схем, если вдруг выяснится, что для одной и той же задачи у вас везде используются разные элементы.
8. Документ с планированием задач по проекту
Тут все понятно: составляем примерный список работ, указываем время, которое нужно на ту или иную задачу, а также человека, который будет эту задачу выполнять. Написать план очень сложно, но на самом деле самое сложное - это его придерживаться. Нужно учесть то, что какие-то задачи могут быть выполнены только после выполнения предыдущих, а также закладываться под некоторую вероятность форс-мажоров. Ваш план к тому же должен быть гибким, чтобы его можно было изменить не разрушив всей системы. Как правило план составляется в табличном документе, который подбивается ссылками на конкретные задачи в специальных задачниках-трекерах.
9. Словарь терминов
Что такое “уровень” в вашей игре? Это уровень игрока? Или это игровой уровень? Или этаж? Каждый игровой проект обрастает некоторыми терминами, которые приобретают уникальное значение, или хотя бы оттенок уникального значения в рамках именно этой игры. Очень часто бессмысленные споры, а иногда и целые неправильно выполненные задачи, получаются из-за недопонимания в терминологии.
Конечно, список документов может варьироваться и быть шире, или уже, в зависимости от проекта и его нужд. Я набросала очень общий вариант ведения документации, чтобы было понятно что к чему.
Правила структурирования информации в документах
Со списком документов разобрались. Они все разные, каждый имеет какую-то особенную структуру, но тем не менее, есть ряд общих правил, соблюдение которых серьезно повысит читаемость вашего документа для самой разношерстной аудитории. Эти правила простые, и, казалось бы, лежат на поверхности, но вы удивитесь, узнав как мало людей их на самом деле соблюдают. В принципе, данные правила можно описать тремя словами: структурирование, структурирование и структурирование. Итак, что же это за правила?
а) Общее описание. Прежде чем описывать детально любую игровую сущность, дайте ей краткое описание, состоящее из двух-трех предложений, чтобы при поиске информации не пришлось перечитывать весь текст. Также необходимо понимать, что некоторым специалистам этого абзаца будет вполне достаточно, чтобы ознакомиться с предметом. Даже в оглавлениях документов стоит давать краткую дефиницию, буквально одно предложение, которое сразу позволит сориентироваться в списке, ведь названия, придуманные вами, будут непонятны 90% читателей.
б) Списки. Сплошной текст очень тяжело читать, особенно, если вы описываете что-то техническое и наполненное терминами. Старайтесь всю вашу информацию всегда структурировать в виде списков, всегда разбивать на какие-то семантические главы, и чем больше будет глав и списков, тем лучше будет восприниматься информация. Так, если в одном абзаце находится одно-два предложения, то читающий воспринимает их как законченную лаконичную мысль, которую легко усвоить. В случае с огромными абзацами без каких либо заголовков… Сами понимаете. Читающему приходится не только усваивать информацию, но и структурировать ее по ходу чтения, что вызывает дикое желание закрыть документ и забиться в темный угол.
в) Оглавления. Всегда ведите оглавления по которым можно будет легко перейти к интересующему вас блоку информации. Если вы пишете текстовые документы в табличном формате, то создайте отдельный лист, где напишите оглавление вручную и подбейте его ссылками на конкретные страницы документа. Если вы ведете документацию в обычном текстовом формате, то создайте отдельный документ с оглавлением, включающем все документы, и внутри каждого документа также вставляйте оглавление (в случае с Google документами, это автоматическая функция, которая подбивает оглавление ссылками внутри документа).
Таким образом, каждый член вашей команды сможет быстро и без особых усилий ознакомиться с вашей документацией через синопсисы и краткие описания а также найти что-то важное для себя, что поможет в выполнении той или иной задачи. Зная все нюансы проекта и разработки, художник в курсе как будет работать то, что он рисует, а программист будет знать, как будет выглядеть его набор кода и какой гейм-дизайнерской идее служить. В такой системе любой член команды будет в курсе работы всех остальных, и сможет не только предложить свои идеи и поделиться своими мыслями, но и лучше понимать и выполнять свою собственную работу, видя ее не как квадрат, а как куб.