Дизайн и документация
ПРИЗНАКИ ХОРОШЕЙ ДОКУМЕНТАЦИИ
Четкость структуры, релевантность содержания, однозначность толкования, грамотность речь, полнота информации, поддержание актуальности, бла-бла-бла- В доке есть нужная информация... (т.е. релевантная, полная, актуальная и пр. - незачем уточнять, если и так понятно)
- И ее просто понять. (а вот это мы часто недооцениваем...)
Чтобы сделать документацию понятной нужно
- Правильно использовать типы документов (под конкретную задачу и адресата)
- Тулзы и трюки (помогают понять написанное)
- Сруктура (отдельного дока и всей документации)
ТИПЫ ДОКУМЕНТОВ
- Сегодня дизайн-доки уже не путают с техзадачами. Это разные типы документации.
- У них разное назначение и разная “аудитория”. Например, продюсеру не нужны тонкости тех. реализации; программисту не нужна геймплейная мотивация.
ТИП ДОКУМЕНТА ЭТО: КАК ОН ПИШЕТСЯ (формат, детализация, объем), И ЗАЧЕМ (с какой целью, для какой аудитории)
Типы
ДИЗАЙН-ДОКИ - отвечают на вопрос: Как устроена игра?
- Описательные (для представления: vision, concept, pitch, etc)
- Функциональные (для детального понимания: дизайн отдельных фичей и механик)
ТЕХ-ДОКИ - отвечают на вопрос: Как сделать игру?
- Технические задания (для специалистов)
- Направляющие (гайды, инструкции, спецификации)
- Вспомогательные (расчеты, модели)
КОНТЕНТ - отвечают на вопрос: Куда деть остальное?
- Все наполнение: игровые тексты, описания предметов, условия квестов, списки товаров в магазине и тому подобное.
Дизайн-доки
Описательные
Цель: сформировать общее представление.
Могут быть неполными или формально неоднозначными. Главное – понятными и доступными.
- Вижн – больше про общее впечатление
- Концепт – детализирует механики и USP
- Питч – включает маркетинговую информацию
В любом может быть указан жанр, сеттинг и арт-стиль, часто хар-ки целевой аудитории, референсы и конкуренты, механики монетизации и так далее.
НЕ ТАК ВАЖНО, КАК ДЕЛИТЬ ЭТУ ИНФУ ПО ДОКАМ – ВАЖНО ПОНИМАТЬ, КАКАЯ ИНФОРМАЦИЯ НУЖНА.
Функциональные
Документация ко всем механикам и фичам.
Цель: полное и ясное описание на уровне “бизнес-логики” – общих правил и принципов реализации. Не алгоритмы. Не тех.задачи.
- Ключевые механики (системообразующие элементы кора и меты)
- Игровые сущности (что есть аккаунт игрока, что есть юнит, что можно прокачать, чем можно владеть)
- Виды активностей (режимы игры, виды прогресса, типы эвентов)
- UI Wireframes / UserFlow
- Экономика и мета (валюты, ресурсы, базовые, производные, структура дохода/расхода)
- Взаимодействия (коллаборация, конкуренция, типы PvP, лиги-турниры)
- Всякая-разная “обвеска” (механики возврата, логика уведомлений, обособленные типы монетизации, функционал встроенных и соц. платформ, формы фидбека, рассылок и все что не вошло в другие разделы)
Все же, полезно знать, как делают дизайн-доки в разных компаниях.
Универсальных нет, но есть полезные практики и проверенные инструменты.
Технические доки
Отвечают на вопрос: Как сделать эту игру
Тех. доки могут быть детальными и “тяжелыми” для не-спеца.
Но только потому, что дополняют дизайн-доки (дублируют или ссылается на высокоуровневое описание дизайна).
- Технические задания. Живут отдельно от дизайн-документации, но в непосредственной связке.
- Направляющие. Разные инструкции: от art style guide и TDD (тех. спецификация), до пайплайнов и описаний конфигов.
- Вспомогательные. Например, таблицы баланса и экономики — это не техзадачи, не инструкции, и не дизайн-доки. Объединяющий принцип: инструменты моделирования, проверки и балансировки.
Вывод по типам
- Вся типология и структура типов – авторская.
- Не все типы доков перечислены, не все перечисленные – обязательны.
- Ничто из этого не панацея.
- Важно понимать, какие бывают документы и почему они разные. И применять как инструмент.
Пара редких примеров
AERM WORKSHEET
Таблица влияния кора, меты и social фичей на привлечение, вовлечение, удержание и монетизацию. Наглядно покажет синергию системных элементов игры и ключевых показателей. Поможет красиво пропитчить игру и обосновать бизнес-план.
Автор: Александр Штаченко
BEAT-CHART
Одностраничный док-таблица со структурой всей игры.
В примере: контент по локациям.
- Помогает держать в уме весь прогресс игрока
- Следить, чтобы игрок не скучал.
- Поможет в планировании разработки
Автор: Ник Филатов
ТРЮКИ И ТУЛЗЫ
1. Методы
2. Инструменты
Методы
Визуал
Иллюстрируйте блок-схемами и графиками вообще все, что можно так иллюстрировать
Таблички
Если информацию можно уложить в таблицу чисто для наглядности – вероятно, это хорошая мысль.
Списки
Вложенный список – самый простой способ разложить информацию пополочкам.
Иногда со списками можно переборщить
Примеры
С примерами проще уложить в голове сложную концепцию.
Вася жмет “Битва” и попадает на экран
глобальной войны.
<...>
Все происходит в реалтайме. Вот
соседний регион освещается цветом
вражеской фракции, поверх взлетает
иконка победившего врага, а Вася
сознает, что враг уже у ворот и он –
Вася – следующий в его списке.
<...>
Подкат
Раскрывающиеся списки (“кат”, “toggle-list” и т.п.) Прячут ненужное, расставляют акценты, визуально сокращают объем.
- Опциональная и дополнительная информация.
- Разделы в длинных документах. Удобнее, чем обычное оглавление.
Прототипы
Если простая фича требует сложного объяснения – прототип докажет, что все на самом деле просто.
- Интерактивные прототипы интерфейсов (на специалистом софте)
- Прототипы чего угодно на любом знакомом игровом движке (либо html/js/flash и т.п.)
СТРУКТУРА
Можно ли писать легкие, понятные, но полные и детальные дизайн-доки?
Да. Просто не в одном и том же месте.
Сборные советы
- Перед длинным описанием – краткая вводная
- В высокоуровневых доках – цели и предпосылки решений
- Дизайн-доки и тех.задания: линковать, но не смешивать.
- Что можно - не хранить в диздоках
- Когда разумно - дублировать информацию
- Структурирование в апдейтах: когда нужен отдельный раздел?
- Планируйте порядок детализации (из концепта в дизайн-доки).
- Про архивы, гайды по формату и пр. полезности
Наглядные примеры
