Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.
О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.
Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.
Почти всегда это вики-движок. Наиболее популярен Atlassian Confluence, но можно встретить и MediaWiki, как правило, с множеством плагинов и используемый в «старых» компаниях, и DocuWiki для небольших pet-project’ов или для маленьких студий. Поэтому готовность работы с документацией крупных проектов стоит начинать с умения работать с принятым на проекте вики-движком. То, что описывается как “диздок”, обычно заменено тремя отдельными документами в вики:
- Концепт-документ – краткое изложение самой идеи игры. Вида «У нас будет онлайн-игра про запуск и перехват ядерных ракет с бесконечным геймплеем, зрелищными спецэффектами и асинхронным PvP!». В нём описывается идея и основные составляющие игрового процесса (очень кратко), а также пара самых ключевых USP («unique selling point», то, что «продаст» идею игроку и уникально на рынке).
- Vision – это уже более развернутый документ, описывающий то, что хочется получить в итоге. Не сам игровой процесс, а всю игру, как конечный бизнес-продукт.
- Feature List (может быть обёрнут в другие документы в зависимости от модели разработки) – список с кратким описанием фичей, того, из чего состоит игра. К примеру, сборка ядерных ракет, аркадный перехват, асинхронное PvP, клановая система, система достижений, и так далее, как правило, со ссылками на отдельные документы с подробным описанием геймдизайна (об этом далее). Также в нем каждой фиче выставляется приоритет, стоимость и последовательность разработки.
Концепт-документ прост и используется для «закладывания фундамента» последующей документации, а также для того, чтобы новый сотрудник, инвестор или журналист могли быстро понять суть проекта.
Теперь переходим к Vision. Этот документ уже масштабнее, и обычно включает в себя следующие элементы:
- Краткое описание игры. Здесь уже не только основная идея, а игра в целом.
- Жанр игры.
- Целевая аудитория и исследование рынка.
- Примеры подобных игр на рынке и отношение к ним: конкуренты они или нет, есть ли пересечение аудитории, заимствование или противопоставление идей.
- USP (Unique Selling Points) игры – то, что выделит игру на рынке, и что использует маркетинг для привлечения трафика / новых игроков.
- «Формула успеха» – какие элементы игры будут самыми качественными / важными. Это может быть революционная графика, честная физика и т.д. Здесь в отличие от USP нужна не уникальность, а качество.
- Составляющие геймплея, вкратце.
- Сеттинг и стиль игры. Например, жестокий киберпанк в жёлто-серых тонах, светлое эпичное фэнтези в аниме-стиле, только куда подробнее и с примерами арта;
- Бизнес-модель, в том числе монетизация.
Последовательность и цели написания здесь очевидны: написав концепт-документ, геймдизайнер определяет основную идею. Далее в Vision он описывает, как и почему эта идея будет работать: на какой аудитории, за счет каких элементов проект будет пользоваться успехом, и как он будет зарабатывать деньги. При этом, написание концепта и Vision – итеративный процесс. Написав концепт, можно попробовать продать предложенную в нем идею (инвестору, начальству, на крайний случай – самому себе) и улучшать его до тех пор, пока идея не будет продана. Написав Vision, можно оценить, есть ли у игры шансы на популярность и коммерческий успех, и перерабатывать его, меняя USP, сеттинг, стиль и прочие переменные, пока не будет хоть какая-то уверенность в результате.
Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.
Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.
Конечно же, написание диздока на этом уровне сильно зависит от конкретной фичи – это может быть как вики-документ из 10 строк, так и целый раздел с десятком вложенных документов, прикрепленными таблицами с расчетами и ссылками на собранную статистику с серверов игры.
Однако в любой крупной компании нужно сочетать три вещи:
- Шаблоны. Да, шаблоны и творчество могут казаться трудно совместимыми, но если на проекте несколько геймдизайнеров, и каждый пишет, как ему вздумается, продюсерам и исполнителям это радости не добавит.
- Связи с другими документами, фичами и задачами. Каждый диздок – это не просто сферический текст в вакууме. Он входит в какую-то группу (например, PvP-фичи), ссылается на другие документы, содержит в себе список задач (в JIRA/Bugzilla/Trello/GitHub/…), оценки готовности, ссылки на отчеты тестеров и результаты плейтестов.
- Собственно, фан и геймплей! За всеми слоями структуры диздока важно не потерять то, что игра все-таки должна быть интересной и увлекательной, фича должна работать в плюс всей игре, а не просто выполнять оторванную от общей идеи задачу.
Что же стоит описать в диздоке? Помимо просто описаний самой фичи, есть немало других элементов:
- Автор и статус (черновик, в работе, сделано, отказались, устарело). Когда на вики сотни диздоков, и за долгие годы работали десятки геймдизайнеров, без этих простых разделов понять, какой диздок актуален, затруднительно.
- Текущая задача. Что хочется получить. К примеру, обеспечить игроков развлечением, пока тренируются войска в казармах.
- Причины возникновения задачи и необходимости решения. Важный пункт, наличие которого спасает от фичей «чтобы круто было» или «у конкурентов есть». Последнее – бич многих геймдизайнеров, когда фичи копируются подчистую, даже несмотря на то, что многие их элементы в разрабатываемой игре лишние, не будут работать или работают в минус, даже если у конкурента это USP и приносит огромный доход.
- Краткое описание решения. Чтобы можно было охватить общую идею.
- Развернутый дизайн. Подробное описание реализации.
- Ожидаемое поведение игрока, типовая сессия. Нужна для того, чтобы ответить на вопрос «А как в это играть?» с позиции игрока. Без этого легко получить фичу, которая вроде бы и имеет смысл, но игроки на форумах пишут “И что это вообще такое?”.
- Место фичи в игре и связь с другими фичами. Очевидно, фича должна поддерживать и дополнять другие фичи или общий геймплей игры, а не повторять или подавлять их собой.
- Задачи на реализацию и ассет лист. Список того, что нужно сделать, чтобы фича заработала: какие функции на уровне кода, что нарисовать художнику, нужно ли написать тексты реплик персонажей сценаристу и т.д. Иногда это составляет продюсер, но нередко и сам геймдизайнер.
- Требуемая статистика. Какую информацию собирать и анализировать с плейтестов и серверов. Как много времени игроки проводят в геймплее фичи? Ездят ли они на лошадях или автомобилях в фиче о средствах передвижения, стреляют ли из Сайги или Вепря в ближнем бою шутера?
- Требуемое тестирование (+ edge cases). На что QA-отделу обратить особенное внимание при проверке фичи. QA могут такое составлять и сами, но нередко только геймдизайнер может сходу сказать, что «если вдруг игрок эксплоитами типа сложения эликсиров наберёт 1000 навыка Торговли, то сможет продать товар дороже, чем купил, и сломает всю экономику! Поэтому нужно убедиться, что такое невозможно даже теоретически».
- Deployment и оперирование. Раздел для оператора. Как описать фичу в patch notes? Нужно ли выложить о ней статью в энциклопедию игры? Требуется ли что-то отобрать у игроков и выдать компенсацию для запуска фичи?
- Планы на будущее. Собственно, все идеи, которые могут улучшить фичу в будущем.
Конечно, этот список может меняться в зависимости от фичи, работодателя и степени срочности написания дизайна. Тем не менее, там, где это нужно и возможно, желательно не забывать о таких пунктах. Как правило, после всех этих пунктов диздока, геймдизайнера ждёт последний пункт… комментарии! Большинство вики-движков имеют такую функцию, и немало коллег — от других геймдизайнеров до программистов и тестеров — с радостью поделятся своими соображениями по поводу вашего геймдизайна.
На этой радостной ноте моя краткая статья заканчивается. Надеюсь, она была вам интересна. И можно переходить к комментариям!
Комментарии (11)
aleks_raiden
07.09.2015 21:22Интересно, есть существенное отличие Wiki от Google Docs — кроме очевидного удобства для работы с текстом во втором варианте (и менее удобной работы с перекрестными ссылками на внутренние ресурсы)
Eligar
07.09.2015 21:46+2Для небольших команд Google Docs в принципе применим — в статье просто речь о крупных компаниях. Для них же поднимаются такие вопросы:
— интеграция с системами отслеживажния ошибок/управления проектом/… принятыми в компании. К примеру, драму насчет решения Atlassian про интеграцию с Google Docs можно почитать тут — answers.atlassian.com/questions/140987/linking-google-docs-documents-to-jira-issue-in-jira-ondemand — и в целом, вики-решения интегрировать как правило намного проще.
— необходимость держать документы в внутренней офисной сети (соображения безопасности, логгирования всего доступа)
— уже упомянутые перекрёстные ссылки на внутренние ресурсы
— на вики-движках намного проще обеспечить распределение прав доступа по компании — соответствующие доступы по отдельным проектам/командам, новые сотрудники и увольнения,… всё решается проще.
И, наконец, в крупных компаниях редко бывают реально коллаборативные дизайн-документы — обычно только один гейм-дизайнер (ответственный за направление либо исполнитель задачи) пишет документ, а коллеги только комментируют. Подход «дизайним сразу всей командой» очень редок.
Кстати, Google Docs нередко применяются и параллельно вики-движку — как раз для общего редактирования текста, к примеру, сбора отзывов после плейтеста. После чего «выжимка» из общего набора мнений перекладывается на вики.
Krypt
07.09.2015 23:04+6Вопрос на 100 балов, перед началом чтения: а что такое диздок? :)
Не отождествляю это название с сущностью.Eligar
07.09.2015 23:16+1В этом-то и подвох: как правило те, кто задают вопрос «что такое диздок?», и так не имеют иллюзий на этот счёт, на развеивание которых направлен текст ;)
К сожалению, эволюция этих иллюзий была весьма печальна, к примеру
www.gamedev.ru/projects/forum/?id=8221 (2005 год)
gmakers.ru/index.php?topic=54.0 (2008)
smartresponder.ru/web_version.php?Action=ShowArchiveMessage&q=001Xja002EXc00ip0N3cb53b0c (2014)
И даже в 2014… «Детальное описание игры… Под детальным описание подразумевается, как и общий концепт так и объектная модель мира т.е опись каждого игрового объекта с его характеристикой.»
В этом нет упрека — можно делать и такие диздоки (наследие старой школы документации геймдизайна на Западе — которой уже почти нет), просто последующий опыт работы в крупной компании может оказаться шокирующим.
Если же у вас нет иллюзий, это отлично! ;) Диздок — дизайн-документ — просто вариант оформления геймдизайна (всей игры или ее части) в проектной документации. И всё. Остальное — уже зависит от проекта и работодателя ;)
Примеры, как сделать это «оформление» более структурированным и удобочитаемым для коллег — это уже тема отдельных статей и курсов.
farewell
08.09.2015 11:26Спасибо.
Пишем всё в гугледоксе — спасибо функции «Вставить оглавление» и стилям текста. Команда небольшая, каждого специалиста по одному экземпляру.
evans2094
08.09.2015 13:57Когда я такое писал (2003-2005) Диздок так и выглядел :)
Просто концепт шел как введение, Вижн был основной частью, а фичелист дроблился на приложения. Не было тогда еще адской моды на викидвижки везде и всюду :)Eligar
08.09.2015 14:4610 лет назад — да, «единый текст» нередко применялся. Но уже тогда в крупных компаниях (на Западе, в основном; хотя, к примеру, документация Аллодов уже была на MoinMoin — 2006 год) распространялся вики-подход и разбиение диздоков на компоненты… а за 10 лет почти все перешли на новый формат. Кроме статей в интернете о диздоках ;)
Возможно, через еще 10 лет парадигма снова изменится, хотя пока очевидных предпосылок еще нет.evans2094
08.09.2015 15:01Общий вид не изменился. Изменилась линковка документов между собой. Возникло дробление.
Тоесть раньше по фичелисту шли уже четкие ссылки на лидов и ответственных за разработку и внедрение. Сейчас тоже самое на вики. Как плюс есть контроль версионности, а так же сразу видно кто где гадит. Подход через вики помоему ближе к agile методикам и упрощает их внедрение, вертикальная работа от документа — это явно ближе к waterfall. При разработке игр логично предположить что более вероятно применение agile-подобных схем разработки и как следствие каша в виде викисклада отлично соответствует требованиям.
viacheslavnu
Хорошая статья, спасибо автору.
Вообще писать качественные ТЗ и диздоки весьма интересная работа. И не только геймдизайнеры это делают :-)
Kallist
На самом деле да, т.к. сколько ищу, толковых статей на эту тему в сети практически нет.
Особенно в теме того, что касается концепт-доков.