Лайфхаки ГДД

Сергей Гимельрейх, гейм-дизайнер, основатель творческого пространства ИНДИКАТОР, делится лайфхаками создания гейм-дизайн документации.

 

 

 

 

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

 

СОВЕТ №1: Структурируй.

Пример структурирования разделов страницы типового описания игровой системы в ГДД:

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

 

СОВЕТ №2: Оставляй перекрёстные ссылки.

Не ленись оставлять перекрёстные ссылки в документе на другие страницы описания других игровых систем, если в этом есть необходимость.

 

СОВЕТ №3: Выделяй эффекты, звуки и анимации.

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

ПРИМЕР:

 

СОВЕТ №4: Используй цветовую кодировку времени изменения.

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

• актуальная информация (обычный черный);
• текущие последние изменения (красный);
• устаревшая, неактуальная информация(светло-серый и вычеркнутый).

 

СОВЕТ №5: Оставляй шпаргалки.

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

 

СОВЕТ №6: Заведи базу знаний.

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

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

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

 

СОВЕТ №7: Избегай дублирования.

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

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

 

СОВЕТ №8: Помечай настраиваемые константы и переменные.

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

 

СОВЕТ №9: Используй изображения и анимации.

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

 

СОВЕТ №10: Не перекладывай ответственность на исполнителя фичи.

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

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

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

 

СОВЕТ №11: Обозначай исключения.

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

ПРИМЕР:

 

СОВЕТ №12: Пиши кратко и ёмко.

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

 

---

ПРИМЕР ОПИСАНИЯ ФИЧИ

---

 

ВЫБОР СТАРТОВОГО КОСТЮМА

Автор: Василий Пупкин [ссылка на профиль с данными для связи] Дата обновления: DD.MM.YYYY

Цель: Стимулирование первого платежа. Создание привязки к личной собственности. Возврат игрока к следующей сессии.

Описание

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

Логика работы

Игрок по специальной команде из стартового сценария игры переходит в форму выбора костюмов.

Форма получает данные о списке доступных костюмов на выбор с сервера.

Список костюмов настраивается гейм-дизайнером в отдельной таблице (описание в разделе Настройки).

В форме игроку на выбор предлагается несколько костюмов (не менее 2-х). Костюмы могут быть платными (за хард- или софт-валюту) или бесплатными.

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

Если игрок на экране просмотра костюма не совершает никаких действий в течение N секунд, появляется выноска с комментарием NPC, который ”говорит” фразу, привязанную к конкретному костюму. Тап по выноске или смена костюма автоматически закрывают подсказку.

Если в настройках костюма нет ссылки на комментарий, выноска не появляется.

Выбор костюма производится тапом на кнопку под ним.

Если костюм стоит хард- или софт-валюты, происходит списание валюты с счета игрока, зачисление всех предметов костюма в инвентарь игрока, затем происходит демонстрации костюма на персонаже в анимации. Далее – выход из формы в сценарий.

В следующем диалоге сценария после формы выбора костюма, персонаж игрока появляется уже в новом выбранном костюме.

ИСКЛЮЧЕНИЕ:
Если не хватает валюты, происходит автоматический переход игрока на покупку недостающего количества валюты за реал. После покупки валюты происходит зачисление на счёт, отъем недостающего количества для покупки сета с счета игрока и финальный эффект выбора костюма (см.описание интерфейса). 

Интерфейс и эффекты

Форма полноэкранная (экран в портретной ориентации), с настраиваемым фоном.

Форма появляется через FADE-эффект при переходе на неё.

В центре располагается персонаж в текущем предлагаемым костюмом.

У персонажа включена анимация idle.

Слева и справа расположены кнопки-стрелки, для смены костюма.

Лучше кнопки расположить в нижней части формы, чтобы удобно было до них дотягиваться пальцем.

В нижней части экрана, под куклой персонажа, расположена кнопка “ВЫБРАТЬ” или “КУПИТЬ ЗА …”. Тап по этой кнопке является подтверждением выбора костюма.

Подсказки в процессе листания

Игроку могут отображаться подсказки после перелистывания на новый костюм спустя N секунд (настраивается), которые отображаются в виде “подвешенного” бабла с текстом и пиктограммой NPC.

Координаты бабла и идентификатор пиктограммы настраиваются.

Контроль

Листать костюмы можно также свайпами влево-вправо.

Смена костюмов карусельного типа,- при достижении последнего костюма, если пользователь листает дальше, ему показывается первый и так по кругу (в обе стороны).

При тапе на кнопку “ВЫБРАТЬ” или “КУПИТЬ ЗА …” отображается эффект вспышки, воспроизводится анимация куклы для подиума, исчезают контролы, вместо кнопок в нижней части экрана появляется мигающая надпись “НАЖМИТЕ ДЛЯ ПРОДОЛЖЕНИЯ”.

ЭФФЕКТ:
Яркая вспышка по аналогии фотовспышки на подиуме. В этот момент убираются контролы (стрелки и кнопка выбора) и появляется мерцающая надпись TAP TO CONTINUE. В момент вспышки меняется костюм на кукле и включается эффектная анимация. В качестве остаточного эффекта осыпается что-то вроде конфетти поверх одетой в новый костюм куклы.

После тапа в любом месте экрана – экран засветляется(FADE через белое), происходит переход в сценарный диалог после формы.

Затронет системы

• Сценарий.

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

Аналитика

Событие	Описание	Кастомные параметры события	Тип параметра
set_form_open	Форма выбора сета открылась	–	bool
set_form_select_set	Выбранный игроком сет	set_ID set_currency set_value	string hard|soft|free num
set_form_close	Форма выбора сета закрылась	–	bool

Настройки

Команда в сценарии:

selectSet

Параметры:

• перечисление ID сетов;
• выбранный сет по-умолчанию.

Таблица настроек сетов костюмов:

• перечисление ID элементов костюма;
• тип валюты (хард|софт|бесплатно);
• количество валюты (не учитывается, если тип “бесплатно”).

 

---

 

Надеюсь, эта подборка будет полезна для вас.

Благодарности тем, кто помог с подборкой:

• Эдуард Малых, Гейм-дизайнер, PlayToSea
• Роман Броницкий, Head of Game Design, WazzApps
• Татьяна Есина, Гейм-дизайнер, Belka games
• Артём Волков, Senior Game Designer, W4