Правила хорошего ГДД

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

• Цель — для чего система создается, какие задачи в игре решает. Удержание, монетизация, целеполагание, снижение скуки, эмоциональный отклик и т. п.
• Общее описание — краткое, ёмкое описание сути системы, чтобы с самого начала человек прочитал и понял, о чём далее пойдёт речь.
• Логика работы — подробное описание логики работы системы. Можно в виде юзер-сториз, можно в виде отдельных абзацев-кейсов. Здесь нелишними могут быть схемы/циклы и прочие поясняющие диаграммы и изображения.
• Интерфейс — схематический макет и описание элементов интерфейса. Схема переходов, если в этом есть необходимость.
• Балансировка — комментарии ГД по концепции баланса системы. Диапазоны, пределы, варианты формул/функций, рекомендации.
• Настроечные данные — список всех переменных, которые должны быть вынесены в настроечные таблицы игры.
• Аналитика — список событий, которые необходимо фиксировать в системе сбора и анализа данных по игре (опционально).
• Затронет системы — список всех систем (ссылки на их описание) и изменений в них в результате реализации этой системы.

Обозначай Эффекты, Звуки и Анимации в описании фичи отдельными выделенными блоками. Это упрощает формирование задач художниками, специалистам по эффектам, саунд-дизайнерам и аниматорам.

Есть положительный опыт использования цветовой кодировки в описании фичи для обозначения:

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

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

Отдельно вести доску с лайфхаками внутри проекта. Там содержатся всякие подсказки как выполнять какие-то редкие задачи, или как выполнять какие-то рутинные задачи быстрее. Доска ведется в виде FAQ. Заголовки — вопросы, а в описании подробный ответ.

Например тебе нужно заменить содержимое одного лутбокса в игре. Последний раз это делали 3 месяца назад, да ещё и не ты. Заходишь в шпаргалку отдела и видишь кем-то оставленную заметку как это сделать буквально в пару кликов. Благодаришь всех богов за лучшую команду на свете.

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

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

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

Не лениться делать гифки и тратить время на оформление ТЗ. Иногда 3 гифки в ТЗ на анимацию вместо тысячи слов, как рафаэлло!

Не указывайте в диз.доке варианты выбора на усмотрение исполнителя. В стиле «тут можно сделать любого цвета, какого захочется, неважно» или «строка может быть длиной от 30 до 400 символов».

Исполнитель, берущий в руки тех.документ пришел не ребусы отгадывать и не принимать решения за гейм-дизайнера, а узнать что конкретно нужно сделать. «Сколько вешать в граммах». Обычно такие свободные формулировки гейм-дизайнер оставляет от того, что сам не знает как нужно сделать. В этом нет ничего страшного, знать все на свете не возможно. Но правильней будет проконсультироваться с теми, кто знает и в ГДД указать уже точные данные для исполнителя.

То же самое касается и призывов к обсуждению в ГДД, в стиле «как думаешь, 5 строк рейтинга в окне будет нормально?» Обсудите этот вопрос заранее в чате, а в диз.док запиши уже конкретные данные. Когда кто-то откроет документ через несколько месяцев, он будет совсем не в восторге от того, что ему придется читать еще и какие-то ветки решенных комментариев, чтобы докопаться до нужных данных.

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