7 ошибок начинающего гейм-дизайнера

 

Артём Волков, гейм-дизайнер, написал о типичных ошибках начинающих гейм-дизайнеров и как их избежать.

 

 

---

Меня зовут Артём Волков. Последние полгода я читал лекции для начинающих дизайнеров игр (гейм-дизайнеров, ГД) по процессам производства игр и общую лекцию по гейм-дизайн документации (ГДД). Кроме этого, я занимался проверкой домашних заданий и оценкой дипломных работ. Полученный опыт показал, что студенты совершают приблизительно один и тот же набор ошибок при работе с документацией.

В статье я рассмотрю самые популярные ошибки и расскажу, как их не допустить. Хочу отметить, что я не буду рассматривать вопросы «Как написать хороший ГДД для игры Х?» или «Что описывать в ГДД?». Почему? Ответы на эти вопросы комплексные, и они не гарантируют, что начинающий ГД не допустит описанные далее проблемы. Какие же ошибки являются наиболее распространёнными для начинающих ГД?

Большие документы

Начнём с часто встречающегося — гигантские ГДД, которые содержат всю информацию по игре, на несколько десятков, а иногда и сотен страниц. Почему это плохо?

1. Психология. Когда видишь книгу на 500 страниц, пропадает всякое желание ее читать. Аналогичный эффект при работе над большими документами.
2. Сложная структура. В подобном документе очень тяжело работать над единой структурой, особенно в тех местах, где уже что-то написано. Даже при наличии хорошего оглавления — это заметно сложнее, чем просто создать новый документ по новой фиче.
3. Размер. Такой документ весит заметно больше, чем много отдельных, которые все разом никто качать не будет. А если в нём используются дополнительные картинки, то даже при подгрузке с web будет много проблем.
4. Усложнение внесения правок. Отслеживать правки в данном документе очень тяжело, особенно, если над документацией работает больше одного ГД. В этом случае, вероятность получения ошибки внутри документа увеличивается в разы.

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

То же самое и при разработке игры. Работая над ГДД, помните, что документом будут пользоваться разные люди и специалисты, которым важно получить строго определённую информацию в самом актуальном виде. Чтобы этого добиться, разделяйте вашу документацию на множество небольших документов, которые будут в себе содержать всю необходимую информацию по одной (в идеале) фиче. Не забывайте вести список документации в отдельном каталоге и записывать ваши изменения в них.

Проблемная структура

Вторая проблема — это плохая структура ГДД, как в иерархии документов, так и внутри самого документа.

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

Как избежать данной проблемы? Я придерживаюсь двух правил при написании ГДД:

1. От общего к частному;
2. От core к additional;

От общего к частному

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

От Core к Additional

Я всегда начинаю писать документацию механик с самых основ, которые образуют фундамент выбранной механики (core) и затем уже добавляю дополнительные правила или детали, которые делают её лучше и глубже (additional). Например, у нас есть дробовик:

1. Core — это стрельба и нанесение урона при попадании.
2. Additional — это механика отбрасывания противника при попадании всеми дробинками.

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

Также я считаю, что всем начинающим ГД поможет работа с UI, особенно создание User Flow, т.к. через UI и User Flow можно увидеть будущую структуру игры, а также легко научиться отделять логику от визуала. На основе этого будет проще создавать структуру всего ГДД.

Плохое оформление

Третья частая проблема — это ужасное оформление документации. Разработка игры — это работа с огромным объёмом информации, и чем лучше эта информация оформлена, тем быстрее и качественнее её будет воспринимать команда. Кроме того, умение оформлять текстовые документы и таблицы — самое первое, чему обязан научиться каждый ГД, т.к. это самая распространённая задача в нашей работе. Какие же проблемы встречаются при оформлении документов и таблиц?

Основные проблемы текстовых документов:

1. «Бесконечные» списки. Состоящие из тезисов на десятки пунктов и подпунктов, в которых искать информацию крайне тяжело. Дробите списки, используйте чистый текст для описания фичей, оставляйте списки только там, где нужно попунктное перечисление.
2. Плохое форматирование текста. В частности, неумение использовать стили заголовков, которые позволяют очень хорошо выделить разделы и подразделы документа, тем самым задавая иерархию, которая также используется в оглавлении. С другой стороны, не надо перегибать палку и использовать слишком много форматирования, когда розовый курсив перемежается с красным полужирным текстом.
3. Отсутствие картинок и референсов. Иногда одна картинка может сказать больше, чем сотня-другая слов, не пренебрегайте ими при описании механик.

Основные проблемы таблиц:

1. Плохое форматирование границ ячеек. Ваши таблицы баланса и контента игры будут содержать огромный объём информации, в которой вы должны глазами очень быстро находить то, что вам нужно (вам или кому-то ещё). Отсутствие форматирования (или использования одного стиля) границ будет усложнять читаемость таблицы.
2. Пренебрежение форматированием текста. Принцип приблизительно такой же, как в текстовых документах. Иногда надо выделить разный формат данных или заголовки разделов таблицы, чтобы улучшить читаемость данных.
3. Ужасная работа с цветом. Цвет ячеек — это палка о двух концах, бьёт и тем, и другим. Цветовая дифференциация в таблицах важна, т.к. с её помощью можно выделять информацию и делать её хорошо читаемой, не пренебрегайте этим. Но также надо помнить, что переизбыток цветовой информации может сильно ухудшить читаемость.

Сложные формулировки

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

1. Игрок может находить предметы на локациях, либо же они могут выпадать с тел поверженных противников.
2. Игрок находит предметы:
   1. На локациях в специальных ящиках
   2. В трупах убитых врагов.

Смысл тот же, а воды чуть меньше. Важно помнить, что техническая документация — это не описание дуба у Льва Толстого. Чем больше «красивостей» вы накручиваете, тем сложнее они будут восприниматься командой. Пишите сухие и понятные тексты. Чем более простой язык вы используете, тем выше вероятность, что вас поймут именно так, как вы того хотели. Однозначность формулировок — это ключ к более чёткому пониманию требований по механикам, например:

1. При ударе топором может быть нанесён критический урон.
2. При попадании оружием по противнику с заданной вероятностью будет нанесён критический урон.

Перечитывайте вашу документацию спустя два-три дня после написания, вы увидите очень много моментов, которые лучше переписать или переделать.

«Баланс» в описаниях

Ещё одна проблема описаний — это использование  чисел и балансных значений в текстах. Почему это проблема?

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

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

Имена документов и файлов

Маленькая, но проблема — это названия документов и файлов. Часто начинающие ГД называют их как попало. Не надо так.

Вырабатывайте для вашего проекта систему наименования документации и файлов, чтобы у вас не получалось “Копия ГДД_Стрельба_финал_Фин_09.09.2009 (1).doc”

Каких правил я придерживаюсь при работе с названиями?

1. Только на английском языке;
2. Никаких пробелов;
3. Название проекта в названии (если это отдельный документ)
4. Тип документа (GDD, Concept, Art и т.д.)
5. Тема документа (mechanic, character, art, UI, UserFlow)
6. Дополнительная информация (например название окна UI)

Например, GDCUFFS_GDD_UI_MainMenu.doc

Отсутствие диалога и исправлений

Даже если вы учли все предыдущие моменты и избежали проблем с ними, всё рушится если у вас нет диалога с командой и исправлений внутри документации. Существует заблуждение среди новичков в индустрии, что ГДД пишется один раз и навсегда. НЕВЕРНО!

Как только ГД завершает написание документа, например, механики способностей персонажа, всё только начинается. Вы как дизайнер должны убедиться, что:

1. У команды нет дополнительных вопросов по документу;
2. В механике нет никаких дыр и проблем на данном этапе;
3. Описанная механика не будет:
   1. Значительно ломать планы по разработке игры;
   2. Требовать дополнительных ресурсов для разработки;

Как это узнать?

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

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

Очевидно, что по результатам всех этих обсуждений ГДД надо будет обновлять и улучшать, чтобы не было грубых вопросов из разряда “Какого фига?!”.

Напоследок

Статья получилась достаточно объёмной, и все моменты сложно запомнить. Поэтому я подготовил вам памятку с тезисами по написанию документации.

1. Дизайнер пишет документацию не для себя, а для команды;
2. Не пишите всё в одном документе. Дробите ГДД на разные документы, с разными фичами;
3. Ведите каталог документации с ссылками и кратким описанием документов;
4. Следите за структурой всей документации и внутри документов;
5. Оформление:
   1. Это отражение образа мысли дизайнера;
   2. Облегчает восприятие большого объёма информации, тратьте время на него;
6. Визуальные референсы — это ваши союзники. Используйте картинки и даже видео для того, чтобы показать, что вы хотите получить;
7. Пишите и упрощайте. Чем меньше воды в тексте, тем:
   1. Понятнее будет ваша идея;
   2. Быстрее будет донесена до команды;
8. Стремитесь к однозначным формулировкам. Если что-то может быть понято неверно — оно будет понято неверно;
9. Конкретные значения параметров в тексте оставляют впечатление, что это незыблемая константа. Отмечайте, где параметр изменяемый;
10. Перечитывайте документацию через 1-2 дня после написания. С замыленным взглядом сложно увидеть проблемы;
11. Следите за названиями документов и файлов. Как файл назовёшь, так быстро его и потеряешь.
12. Общайтесь с командой
    1. Требуйте с них фидбек. Он поможет сделать вашу документацию лучше;
    2. Слушайте их идеи. Любой человек в команде может предложить отличные вещи для проекта;
13. Исправляйте вашу документацию, держите её в актуальном состоянии;
14. Не оценивайте вашу документацию по размеру (количеству документов, страниц). В шести страничном документе может быть сплошная вода, а программисту хватит описания на трёх;

А есть ли пример ГДД?

Да, есть — это ГДД по игре Dirty Bomb, который можно скачать по этой ссылке.

Как видите, документ весит 134 МБ и занимает порядка 300 страниц, что хорошо показывает, почему в реальной работе так не надо делать. Вероятнее всего, для упрощения демонстрации документации, команда игры собрала в этот талмуд всё, что у неё было из того, что могут свободно показать сторонним зрителям. В остальном, изучайте этот документ, он хорошо демонстрирует, как надо делать ГДД.

Хочу выразить благодарность Святославу Торику, Евгению Судаку, Артёму Турушину, Тимофею Березину и Антону Барону за помощь в составлении статьи, ваши комментарии помогли сделать её лучше. Отдельная благодарность Марии Шелест за редактуру.