Правила хорошего ГДД
Многие гейм-дизайнеры постоянно задают вопросы и спорят на тему «правильной гейм-дизайнерской документации»
Мы постарались собрать лучшие советы по ведению гейм-дизайнерской документации, и привести пример описания условной фичи, как отдельной статьи ГДД. Надеюсь, этот материал будет полезным и станет основой стандартизации гейм-дизайнерской документации.
СОВЕТ № 1: Структурируй
- Цель — для чего система создается, какие задачи в игре решает. Удержание, монетизация, целеполагание, снижение скуки, эмоциональный отклик и т. п.
- Общее описание — краткое, ёмкое описание сути системы, чтобы с самого начала человек прочитал и понял, о чём далее пойдёт речь.
- Логика работы — подробное описание логики работы системы. Можно в виде юзер-сториз, можно в виде отдельных абзацев-кейсов. Здесь нелишними могут быть схемы/циклы и прочие поясняющие диаграммы и изображения.
- Интерфейс — схематический макет и описание элементов интерфейса. Схема переходов, если в этом есть необходимость.
- Балансировка — комментарии ГД по концепции баланса системы. Диапазоны, пределы, варианты формул/функций, рекомендации.
- Настроечные данные — список всех переменных, которые должны быть вынесены в настроечные таблицы игры.
- Аналитика — список событий, которые необходимо фиксировать в системе сбора и анализа данных по игре (опционально).
- Затронет системы — список всех систем (ссылки на их описание) и изменений в них в результате реализации этой системы.
СОВЕТ № 2: Оставляй перекрёстные ссылки.
Не ленись оставлять перекрёстные ссылки в документе на другие страницы описания других игровых систем, если в этом есть необходимость.
СОВЕТ № 3: Выделяй эффекты, звуки и анимации
Обозначай Эффекты, Звуки и Анимации в описании фичи отдельными выделенными блоками. Это упрощает формирование задач художниками, специалистам по эффектам, саунд-дизайнерам и аниматорам.
СОВЕТ № 4: Используй цветовую кодировку времени изменения
Есть положительный опыт использования цветовой кодировки в описании фичи для обозначения:
- актуальная информация
- текущие последние изменения
устаревшая, неактуальная информация
СОВЕТ № 5: Оставляй шпаргалки
Оставляй подробные примечания к ячейкам таблицы. Каждый раз, когда тебе кажется, что тут и так все понятно, подумай о тех, кто будет читать таблицу в твоё отсутствие.
СОВЕТ № 6: Заведи базу знаний
Вести общую трелло-доску на весь отдел гейм-дизайна. Есть разные колонки, с концептами новых игр, новых фич, подборки визуальных референсов, интересные статьи и видео про игры или гейм-дизайн, которые нашли и решили что они полезные.
Отдельно вести доску с лайфхаками внутри проекта. Там содержатся всякие подсказки как выполнять какие-то редкие задачи, или как выполнять какие-то рутинные задачи быстрее. Доска ведется в виде FAQ. Заголовки — вопросы, а в описании подробный ответ.
Например тебе нужно заменить содержимое одного лутбокса в игре. Последний раз это делали 3 месяца назад, да ещё и не ты. Заходишь в шпаргалку отдела и видишь кем-то оставленную заметку как это сделать буквально в пару кликов. Благодаришь всех богов за лучшую команду на свете.
СОВЕТ № 7: Избегай дублирования
Максимально избегать дублирования информации. Любая информация должна быть только в одном месте в ГДД, все остальные места должны либо подхватывать из первоисточника, либо ссылаться на него. Если пренебрегать этим правилом, рано или поздно кто-то обновит диздок в одном месте и забудет про другое, а еще через пол года команда начнёт путаться в разных данных.
Если избежать дублирования никак не возможно, необходимо выбрать первоисточник и во всех второстепенных местах указать ссылку на первоисточник. Чтобы было понятно какой документ главнее, в случае расхождений.
СОВЕТ № 8: Помечай настраиваемые константы и переменные
Всегда стоит помечать параметры и константы, которые должны быть вынесены в настроечные таблицы проекта. Если есть хотя бы малейший шанс, что цифру в диздоке понадобится в будущем поменять (то есть практически всегда) нужно отмечать цветом или символом или как угодно еще, что это параметр, который может меняться. Иначе есть риск, что цифру захардкодят. И это будет вина ГД.
СОВЕТ № 9: Используй изображения и анимации
Не лениться делать гифки и тратить время на оформление ТЗ. Иногда 3 гифки в ТЗ на анимацию вместо тысячи слов, как рафаэлло!
СОВЕТ № 10: Не перекладывай ответственность на исполнителя фичи
Не указывайте в диз.доке варианты выбора на усмотрение исполнителя. В стиле «тут можно сделать любого цвета, какого захочется, неважно» или «строка может быть длиной от 30 до 400 символов».
Исполнитель, берущий в руки тех.документ пришел не ребусы отгадывать и не принимать решения за гейм-дизайнера, а узнать что конкретно нужно сделать. «Сколько вешать в граммах». Обычно такие свободные формулировки гейм-дизайнер оставляет от того, что сам не знает как нужно сделать. В этом нет ничего страшного, знать все на свете не возможно. Но правильней будет проконсультироваться с теми, кто знает и в ГДД указать уже точные данные для исполнителя.
То же самое касается и призывов к обсуждению в ГДД, в стиле «как думаешь, 5 строк рейтинга в окне будет нормально?» Обсудите этот вопрос заранее в чате, а в диз.док запиши уже конкретные данные. Когда кто-то откроет документ через несколько месяцев, он будет совсем не в восторге от того, что ему придется читать еще и какие-то ветки решенных комментариев, чтобы докопаться до нужных данных.
СОВЕТ № 11: Обозначай исключения
Если есть особое требование к функциональной логике системы, которое обозначает исключительные случаи, лучше эту информацию отдельно выделить для разработчика.
СОВЕТ № 12: Пиши кратко и ёмко
Текст описания логики работы системы в фиче должен быть максимально ёмким и концентрированным, при этом раскрывать все аспекты системы, чтобы программист и другие специалисты могли в полной мере реализовать функционал.
