Как сделать дизайн документ

Как написать дизайн-документ для игры

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

Дизайн-документ (сокращённо — диздок) — это документ, в котором содержится вся информация о создаваемой игре. Он нужен, чтобы команда, которая будет работать над проектом, понимала, что в итоге должно получиться.

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

Подготовкой диздока занимается гейм-дизайнер — человек, который решает, какой будет игра. Но это не значит, что после составления диздока гейм-дизайнер больше не нужен: он контролирует процесс и принимает новые решения, если во время разработки что-то меняется.

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

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

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

На мой взгляд, нет инструмента лучше чем Google Docs — он бесплатный, позволяет всем иметь актуальную версию документа, добавлять комментарии, предлагать правки и так далее.

Обычно я создаю папку для проекта и добавляю в неё всё: сам диздок, папку с референсами, технические задания и прочее.

Если нужно составить какую-то схему, то я пользуюсь бесплатным сервисом draw.io. В нём можно создавать что-то подобное:

Для подготовки референсов я использую GIMP (графический редактор с открытым исходным кодом) или просто делаю скриншоты и записываю экран.

Диздок — это не:

Диздок — это

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

Можно добавить и другие пункты, лишними подробности не будут.

Описание игровых механик и управления

Все игровые механики важно описывать очень точно. Например, вы можете указать, что игрок будет сражаться с врагами, убивать монстров и захватывать замки. Под это описание подходят как Heroes of Might and Magic, так и World of Warcraft, а они сильно различаются.

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

Кнопка E — взаимодействие с предметом или персонажем.

Взаимодействие с предметом или персонажем: игрок наводит курсор на объект и нажимает клавишу E. Тип взаимодействия зависит от типа объекта:

При этом на разделы нужно прикреплять ссылки, чтобы членам команды было удобно ориентироваться в диздоке.

Сами же взаимодействия можно оформить в виде таблицы:

Источник

Как написать диздок

Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.

Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.

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

Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.

Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.

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

На этой радостной ноте моя краткая статья заканчивается. Надеюсь, она была вам интересна. И можно переходить к комментариям!

Источник

Как я писала геймдизайнерскую документацию на свою игру

В 2015-2016 гг. я задалась задачкой разработать геймдизайнерскую документацию для своей игры, которую хотела бы когда-нибудь сделать. Под катом вы найдете краткое описание того, что мне удалось.

Определяем задачи и цели

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

Концептируем

Для краткого описания игры достаточно сделать Vision-документ – о том, что это такое и как это делается есть статья на хабре: вот она. По ходу подготовки проекта идей становилось все больше и больше, и необходимо было объяснить ключевые фичи и дать более детальное представление о механиках игры, поэтому я остановилась на следующей структуре своего дизайн-документа, который по сути и составил весь проект.

Концепция игрового проекта

Содержит Vision, описание сюжета игры, список фичей и технологических решений. Можно сказать, что основная цель этого раздела – дать общее представление о проекте, ответить на предполагаемые вопросы по проекту «в двух словах». Например, в разделе про сюжет описывается завязка и обязательно дается небольшой глоссарий – для объяснения терминов, понятий и названий, которые используются далее. Featurelist содержит ключевые особенности игры, в том числе и те, которые отличают проект от других подобных. В разделе о технологиях описывается, на чем разрабатывается игра, какое ПО используется для графики, аудио, и т.д.

Игровые элементы

Игровые элементы – это все то, с чем игроку предстоит взаимодействовать тем или иным образом в игре. Персонаж игрока (или несколько персонажей в случае мультиплеерного режима игры), неигровые персонажи, враги, а также определение и список объектов и предметов – все это описано в общем виде и для удобства разделено на группы и категории (например, для предметов – к какой группе относится, где встречается, каковы возможные типы взаимодействия с предметом, и т.д.).

Игровые механики

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

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

Например, при создании классов и способностей персонажей я ориентировалась на классические архетипы персонажей ролевых игр, которые нашли воплощение в классах Защитник, Друид и Тень.

Дизайн окружения

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

Вот, например, небольшой коллаж из артов с моего любимого deviantart.com, которые я подобрала в качестве референсов:

Проводим анализ

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

Геймплей моего игрового проекта сильно опирается на кооперативное прохождение двумя игроками. Поэтому исследование рынка игр проводилось для сегмента игр на ПК и консолях, с режимом мультиплеера для двух-четырех человек. Были проанализированы пользовательские отзывы выборки игр в Steam, рейтинги на metacritic, статьи популярных игровых порталов, таких как pcgamer.com.

В результате всестороннего анализа удалось определить, в чем же преимущества данного конкретного проекта, и будет ли он достаточно привлекателен для целевой аудитории. Также полезно наметить «пути развития» — очевидно, что для игры с одиночным или кооперативным режимом, которая оставила после себя хорошие впечатления, создание серии игр в единой вселенной может стать достойной целью и проектом дальнейшей разработки.

Выводы и материалы

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

Понапридумывав способностей, попробовать «упаковать» их в интерфейс и прикинуть, насколько такая система будет удобна и понятна. Не забыть о том, что не только диалоги и катсцены способны рассказывать истории и донести какое-то сообщение до игрока. Озадачиться вопросами экономики игры, балансом классов или стратегий. Кажется, что проблем, которые нужно решить геймдизайнеру, бесконечно много. Со многими из них помогут справиться играбельный прототип (разработку которого не стоит откладывать в долгий ящик, потому что обычно именно на этом этапе становится понятно, стоит ли вообще разрабатывать) и, конечно же, плейтесты. Но это не значит, что о разного рода проблемах и возможностях их решения не стоит задумываться уже на этапе концепции.

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

Источник

С чего начинаются видеоигры (ч. 2): дизайн-документ

Содержание:
1. Теория (что такое дизайн-документ, из чего он состоит);
2. Практика (пример рабочего дизайн-документа);
3. Итоги (видеоигра, сделанная по дизайн-документу).

«Слово „трудность“ совершенно не должно существовать для творческого ума»

Вступление,
которое связывает текст с предыдущей частью
и вносит в него лёгкую философскую нотку

Вооружившись знаниями из первой части и потренировавшись в составлении концепт-документа «на кошках», самое время переходить к дальнейшей работе! На очереди – дизайн-документ. Иногда его ещё называют «диздок», реже – «ДД», а особые языковые садисты именуют «ГДД» (вероятно, от английского Game Design Document) и «Вижн» (от английского Vision – подразумевается «ви́дение игры»). Пожалуйста, не будьте языковыми садистами.

Теория,
которая могла выглядеть сплошной стеной текста,
если бы не две картинки

Дизайн-документ – полное описание будущей видеоигры. От своего предшественника, концепт-документа, отличается максимально возможной детальностью и проработкой каждого затрагиваемого аспекта – это и механики, и уровни, и сюжет, и интерфейс, и вообще всё, что должно быть в игре. В определённом смысле дизайн-документ можно назвать подробным планом, в котором указано, что надо делать, но не указано кем и как (для этого существуют другие документы).
Дизайн-документ составляют для упрощения работы и повышения её эффективности. Большинство видеоигр включают в себя такое количество компонентов и взаимосвязей, которое не влезет ни в одну голову. А ведь есть ещё коллеги, они нуждаются в актуальной информации и если не смогут найти её «на бумаге», то начнут постоянно задавать вопросы. При вербальном обмене информацией сначала что-то забудется, затем вспомнится то, чего не было, потом перепутается всё, что уже есть, – и так снова и снова. Результаты обычно не радостные:
а) многократные переделки одних и тех же элементов;
б) дублирование работы;
в) хаос во взаимодействии с коллегами;
г) постепенное разноплановое изменение общей структуры и, как следствие, нарушение целостности готовой видеоигры.

Разработка игры без документации

С помощью дизайн-документа всего вышеперечисленного легко избежать или, по крайней мере, снизить до терпимого минимума. Ответственным за эту работу назначается игровой дизайнер (он же геймдизайнер, иногда – гейм-дизайнер (от английского game designer) – в общем, название профессии распространённое, но не устоявшееся в написании). Он необязательно будет один – всё зависит от сложности разрабатываемой игры. Так, например, над документацией ролевой игры количество трудящихся игровых дизайнеров может считаться не в «человеках», а в отделах. Небольшие же аркады, головоломки, платфомеры, «сайд-скроллеры» и прочие им подобные видеоигры менее требовательны, и для их разработки порой достаточно не только одного игрового дизайнера, но и вообще одного человека.
Как и в случае с концепт-документами, при составлении диздока опираются не на официальные правила типа ГОСТа (их просто нет), а на здравый смысл и проверенные временем и опытом общие рекомендации.

5. Игровые объекты.
То, что располагается на уровнях, и то, с чем игрок может взаимодействовать. Объекты, на которые можно запрыгнуть, подлезть под них, обойти, упереться лбом (кроме стен уровня). Объекты, которые можно толкнуть, собрать, перетащить, выбросить, уничтожить или пораниться при столкновении. Одним словом – список. В него скрупулёзно вносится всё до последнего пикселя. Если у объектов есть характеристики и свойства, они тоже указываются (вес, количество единиц здоровья, изменение чего-либо при активации – добавление патронов или брони, уменьшение энергии). И чем больше таких вот характеристик, тем менее понятно будет выглядеть список, если делать его в виде простого перечисления. На помощь придут лучшие друзья игрового дизайнера – таблицы.
6. Сюжет.
История мира, описания персонажей и монстров, диалоги, задания – всё, что относится к литературно-художественному тексту.
7. Система звуков и музыки.
Заполнение данного пункта может вызвать проблемы у игровых дизайнеров, начисто лишённых музыкального слуха, но кое-какие действия выполнить придётся. Указать количество музыкальных композиций и, по возможности, их жанровую принадлежность. Перечислить объекты, которые должны издавать звуки, и дать краткое описание: звук падающего камня, звук лазерного выстрела, звук сменяемой обоймы, звук мотора.
При необходимости добавляются данные о персонажах, которых необходимо озвучить: количество, половая принадлежность, возраст, особые приметы (акцент, хрипение).
В некоторых видеоиграх звуки и музыка являются не дополнением, а частью или основой игрового процесса: ритм-игры; представители жанров «стелс» и «хоррор», где важно слушать и слышать. Здесь важно составить и расписать систему от и до: какие действия должен совершать игрок при прослушивании музыки, какая погрешность допускается при ошибочных действиях; на каком расстоянии затихают звуки, каков радиус слышимости у персонажей.
8. Система сохранений и загрузок.
Сохранения условно можно разделить на два типа – автоматические и ручные. Разница между ними в том, что первые происходят при заданных разработчиком условиях и без вмешательства игрока (например, через расположенные на уровне контрольные точки), а выполнение вторых зависит исключительно от игрока – человек должен нажать кнопку «Сохранить», иначе достигнутый им прогресс будет утерян. К типу системы добавляется список объектов и значений, которые должны сохраняться и загружаться.
9. Система социального взаимодействия.
Социум – это люди, и варианты игрового общения с ними должны найти отражение в дизайн-документе. Хороший пример – массовые многопользовательские онлайн-игры, сама их суть сводится к постоянному взаимодействию – и ради достижения целей, и так, из любви к искусству. Однако не ММО едиными! Социальная сторона одиночных видеоигр может выражаться таблицами рекордов, достижениями, локальным и кооперативным мультиплеером, обменом предметами.
10. Система ролевых элементов.
РПГ (от английского RPG – role-playing game) – видеоигра, в которой нужно отыгрывать роли. Абсолютно любые роли – важен сам факт, а не конечный набор. Механики отыгрыша создают относительную свободу действий, вариативность игровых элементов и способствуют многократным повторным прохождениям с отличающимся результатом. Подобные возможности вызывают у игроков настолько большой интерес, что другие жанры нередко заимствуют элементы РПГ для собственного улучшения и развития.
Примеры ролевых элементов:
а) выбор персонажей и прокачка их характеристик;
б) взаимодействие с игровым миром и влияние на него;
в) «деревья» навыков и диалогов (выбор пути развития);
г) свобода перемещения.
При работе с системой ролевых элементов стоит учитывать, что каждый новый вариант развития значительно повышает сложность её составления и последующего тестирования.

На этом основные пункты заканчиваются. Какие-то из них могут оказаться лишними, о других не упомянуто в силу их меньшей распространённости, третьи пока ещё не существуют. Главное, что нужно понимать: чем больше информации об игре упорядочено и записано в дизайн-документ, тем проще будет работать. И речь идёт не столько о игровом дизайнере (хотя проще будет и ему, безусловно), сколько о его коллегах – это те самые люди, которые превращают документацию в рабочий продукт.
Забота о коллегах проявляется и в поддержании чистоты: в дизайн-документе нет места заметкам, размышлениям, сомнениям, неточностям, двояким толкованиям, шуткам (если они не являются частью сюжета). Лишнее должно оставаться в черновиках.

Уже не теория,
ещё не практика

Дизайн-документ – это, в основном, текст и цифры (расчёты, формулы, графики). Инструменты для работы соответствующие – текстовые редакторы и электронные таблицы.
1. Локальные редакторы и таблицы (например, «Ворд» и «Эксель»).
К достоинствам можно отнести расположение файлов (к ним всегда есть доступ) и удобство работы (полный набор возможностей, оформление, простота использования). К недостаткам – сложности с получением доступа у других людей, проблемы навигации (диздок не всегда представляет собой один большой файл, чаще он разбит на логические части, каждая часть – в отдельном файле, и если все они – локальные «вордовские» и «экселевские» документы, то ориентироваться в них непросто).
2. Облачные редакторы и таблицы (например, «Гугл документы», «Яндекс.Диск»).
Плюсы и минусы предыдущего пункта меняются местами. Доступ к облачным документам легко выдать любому количеству людей, проблема навигации исчезает благодаря гиперссылкам и их более удобному использованию. Заплатить за это придётся урезанными возможностями оформления и вечным удалённым доступом (нет интернета? заблокировали учётную запись? увы).
3. Корпоративные редакторы и таблицы (например, решения на основе вики-движка).
Объединение двух предыдущих пунктов – облачный инструмент, который находится в локальной сети.

Пара слов,
которые влезли без очереди

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

Практика,
которая поможет закрепить теорию

Источник