Инструментарий:

Документация
Григорий Лысов
Lead Game Designer
Red Rift / Atlant Games
Документация на проекте
Основная ответственность
профессионального ГД на проекте -
написание и поддержание документации.
В документации может быть отражена
абсолютно любая информация, но чем
большее будет тем лучше.
ГД несет ответственность за 90%
документации на проекте.
Особых правил и секретов в написании
документации нет, есть только некоторое
количество общих понятий.
Документация на базе времени и детализации
Классическая схема:

ПитчДок -> КонцептДок -> ДизайнДок(ГДД) -> Техническое задание

—------------------------------------------------------------------------------------------------------>
Время и детализация
Питч
Питч - самое короткое продающее описание идеи игры.
Занимает пару минут. Бизнес тренеры часто упоминают
“elevator pitch”. Подразумевается, что можно успеть
продать идею несчастному стейкхолдеру который
оказался с вами в одном лифте.

Питчдок - самое короткое записанное описание игры.

Обычно не больше страницы. Содержание не сильно
отличается от самого питча, обладает некоторой
“продающестью”.

Цель питча - показать преимущества идеи, похвалить

ее, рассказать об ее уникальности и всячески продать. На
этом этапе не принято упоминать ограничения.
Хороший питч
1. Геймплей кажется увлекательным даже
по описанию

2. Описано почему игра

конкурентоспособна, какую нишу
займет продукт в текущем рынке

3. Описаны USP

4. Описано насколько ресурсозатратна

разработка подобного проекта

5. Спрогнозированы метрики, описаны

преимущества монетизации.
Концепт
Концепт-документ - геймдизайнерский фундамент игры. Обычно
простирается на 3-10 страниц текста В нем описаны:

1. Геймплей
2. Отдельные механики
3. Взаимосвязь и системность механик
4. Монетизация
5. Референсы(как визуальные так и геймплейные)
6. Сеттинг, история, сюжет, лор
7. Плюсы и минусы, вызовы*

*про выделенное жирным поговорим отдельно

Концепт: геймплей
Обычно разделяют описание core - геймплея и meta - геймплея.
Много кто из гд любит поспорить, что такое кор и мета, но я советую вам хотябы по первости
использовать следующее разделение.

Кор:
Основной повторяющийся геймплей. В CS:GO это матч. Кор геймплей в ксго это все что происходит от
спавна персонажа до выхода в меню - стрельба передвижение, покупка предметов на матч,
установка/обезвреживание бомбы и так далее.

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

1. За счет чего игра будет зарабатывать

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

Помните: Вам нужно написать пару абзацев. Будьте сдержаны, у вас

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

Круто когда в концепте обозначены не только плюсы, но и минусы и трудности

с которыми можно столкнуться. Поскольку, концепт появляется на ранних
этапах разработки, это позволяет всем(не только гд) подстелить солому в
потенциально проблемных местах. А еще это демонстрирует ваше понимание
процессов и игр.

Если это проект для стороннего заказчика, то этот раздел лучше опустить. Про
вызовы и минусы можно говорить только “своим”
Концепт: примерная структура
1. Краткое описание кор геймплея и мета геймплея(с референсами,
если возможно)
2. Корлуп
3. Значимая механика 1
4. Значимая механика 2 и тд
5. Сюжет/история
6. Монетизация
7. Плюсы и минусы
Дизайн документ (ГДД)
● В общем-то расширенный в 5-10 раз концепт.
● На каждую отдельную, даже небольшую механику в ГДД выделен
отдельный раздел.
● По ГДД должно быть понятно всё что будет в игре.
● Описания механик должны быть со схемами(мокапами) интерфейсов.
● Системность, демонстрация целостности видения и всякое такое
чаще всего в гдд не обязательна, это уже рабочий документ.
● В гдд должна быть четкая структура и последовательность разделов.
Технические задания
● Еще более детализированная версия
описания механики с прямыми
указаниями, что нужно сделать.

● Обычно создается отдельным от гдд

документом

● Чем более подробное тз тем лучше,

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

● “Без тз - результат хз”

ГДД: вики vs гуглдоки
Обычно бывает 2 способа вести документацию, на вики движке или в
гуглдоках, это извечный спор геймдизайнеров
Ответ на этот спор прост - если вашей команде удобно, то можно вести
документацию хоть на бумаге(но лучше не надо конечно). Попробуйте и
то и другое если у вас будет возможность
Я предпочитаю гуглдоки потому как
● Все знают как они работают
● Можно работать на разных проектах в одном месте
● В отдельном доке быстрее что-то сделать
Домашка:
Подготовить концепт документ на заданную тему

Жанр: Hyper Casual

Платформа: Mobile

Аудитория: разная, но главное, чтобы нравилось девочкам 15+

Это дз пойдет в ваше портфолио