Когда идея наконец сформирована в голове необходимо записать ее на бумаге. Или в Word. Или в Google Docs. Лично я рекомендую последнее по ряду причин:

Google документы имеют все те же функции, что и ворд

Файл Word может случайно удалиться или потеряться, а гуглодок - нет

Доступ к документу с любого девайса и из любого места без специального ПО

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

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

Где писать - разобрались. Теперь надо разобраться что писать.

Содержание и структура любого дизайн-документа отличается в зависимости от целей, которые написание этого самого докумета преследует. Однозначной классификации документации я не встречала, но можно выделить три основных типа документации:
1. Концепт-документ
2. Питч
3. Рабочий дизайн-документ

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

Концепт документ

Для себя и всех. Акцент - общее описание.

Питч

Для издателей и инвесторов. Акцент - уникальность и будущая успешность, монетизация.

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

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

Примерное оглавление обоих документов будет выглядеть следующим образом:
1. Среда разработки, целевая аудитория, системные требования
2. Список фич
3. USP
4. Для питча: похожие проекты мреди успешных (отметить, какие есть плюсы у них, которые также есть и у вас).
5. Сюжет
6. Контент, очень кратко, (для питча нужно сделать дополнительный акцент на времени разработки и стоимости разработки)
7 Монетизация и виральность
8. Примеры графики

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

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

3. Описание геймплея, список фич.
Фича - feature - это игровая механика, особенность игры. Это очень важный момент. Фактически, это первая серьезная информация, с которой столкнется человек, читающий ваш документ (первые два пункта представляют собой один абзац). Здесь вы должны максимально понятно описать, в чем, собственно, и состоит сам процесс игры.
- Начать стоит с описания game loop - игрового цикла - последовательности действий, которые совершает игрок постоянно. Чтобы было понятно, о чем речь, приведу game loop известного мобильного проекта Clash of Clans:

На самом деле, игровых механик в игре Clash of Clans , конечно же, намного больше, но ключевой геймплей, который повторяется каждую гровую сессию - именно такой. Более подробно том что такое game loop я расскажу в следующих уроках.

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

4. USP - Unique Selling Points - уникальные особенности игры.
USP - это уникальные фичи, которые делают вашу игру особенной и которые должны привлечь игрока, заставить его выделить ваш продукт среди конкурентов в том же жанре. Это то, что делает вашу игру особенной. Этот пункт проще всего выделяется из предыдущего. Вы пишете список фич, а затем задаете себе вопросы:

“Что мне нравися в игровых механиках больше всего?”

“Когда я рассказываю другим людям о своей идее, что они выделяют как самое интересное в первую очередь?”

Механики, которые вы выделили из списка и являются особенными для вашей игры. Если же вы затрудняетесь ответитьна эти вопросы, значит ваш концепт недостаточно продуман, и когда игроки запустят вашу игру, они просто скажут: “ну и что, мы видели это уже тысячу раз”. Приведу пример возможных USP: нелинейный сюжет с несколькими концовками (Ведьмак), анимированные диалоги вместо текстовых (Machinarium), одно оружие, которое трансформируется в несколько разных типов оружия (Bloodborne), полная свобода в прохождении уровня (Metal Gear Solid Phantom Pain), уникальный и очень яркий сеттинг (Dishonored). Иными словами, USP - это то, что вы скажете своему другу в первую очередь, когда будете рассказывать об игре (“прикинь, там не надо бегать по дороге, а надо лазать по крышам и стенам и заниматься всяким паркуром!”). Также USP - это то, что будет интересно в первую очередь возможным инвесторам и издателям.

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

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

“3 класса оружия и 2 класса брони, по 10 предметов в каждом классе;

50 уникальных локаций;

30-40 игровых квестов;

70 видов монстров;

...”

Из примера выше видно, что игра будет делать упор на экшеновую составляющую, возможно игра - аркада, т.к. квестовая система явно менее детально проработана, чем система брони и оружия, монстры и локации. Также очевидно, что сюжет для игры не на первом месте, а значит в команде можно обойтись, например, без сценариста, и так далее. Детализация этого пункта также зависит от типа документа.

7. Монетизация и виральность.
Монетизация - это то, что вы собираетесь продавать в вашей игре и как, иначе говоря, каким образом на вашей игре можно будет заработать (если речь идет о free-to-play проекте, для всех остальных этот пункт будет называться “бизнес-модель” и будет описывать то, как вы будете продавать вашу игру: по подписке, или за единоразовую покупку, или, может быть, и то и другое). Виральность - это способы комуникации между игроками, предусмотренные в вашей игре. Обмен подарками, общение в чате, приглашение друзей, пвп - все это виральные составляющие вашей игры.

8. Стиль графики с реферансами (примерами).
Теперь, когда понятно как, во что и про что играть, для завершения полной картины надо понять, как это все будет выглядеть. Лучше всего дать вашей графике небольшое текстовое описание, и попросить художников сделать для вас несколько красивых скетчей. Помимо этого, было бы неплохо проиллюстрировать все предыдущие пункты, снабдив их скриншотами или даже просто скетчами по теме.

2.5D action / beat"em up с элементами RPG в киберпанк-сеттинге с фокусом на рукопашные схватки (графическое оформление в стиле pixel-art).

Аудитория

• Мужчины 12-35, женщины 15-25.
• Подростки/хардкорные игроки/medium.
• Любители хайтек-технологий, с интересами: футуризм, киберпанк, проблемы экологии и перенаселенности, биоинженерия, генная инженерия.
• Любители жанра retrowave, киберпанк-вселенных, слэшеров, файтингов, ролевых игр, игр с нелинейным сюжетом.
• По схожим играм: Deus Ex, Remember Me, Prototype, RUINER, Golden axe, Streets of rage, Mother Russia Bleeds etc.

Основные особенности (USP)

• Смесь из киберпанка и элементов (по большей части визуальных) постапокалипса в стиле “Mad Max встречается с Blade runner”
• Яркая пиксель-арт графика с совмещением ретро-стилистики и современных визуальных приемов (совмещение 2D спрайтов с трехмерным окружением)
• Атмосфера города будущего
• Нестандартный мир киберпанка, совмещенного с элементами сеттинга в жанре пост-апокалипсис
• Динамичная боевая система
• Продуманная вселенная, сюжет, нелинейное прохождение

Сюжет

Год 2084. Ресурсы Земли практически полностью исчерпаны. Земная экология разрушена, население планеты проживает исключительно в огромных мегаполисах, находящихся под управлением мега-корпораций. Действие игры разворачивается в городе, находящимся под контролем корпорации MegaZet. Она специализируется на производстве нанороботов.

Главный герой по имени Макс Блондски – бывший член элитного подразделения наемников ЧВК, оснащенный новейшими имплантами, владеющий техниками взлома сознания. По роковому стечению обстоятельств ему стало известно о связях практически всех силовых структур с мафией. Многие аугментации в теле Макса блокируются, как только он теряет связь с армейской сетью. Власти города и «подпольная империя» объявляют на него охоту, вынуждая скрываться. Наш герой опускается почти на самое дно огромного мегаполиса и попадает к местным радикалам-хакерам. Им как раз и нужен человек, который обладает навыками ведения войны. Этот «Фронт техногенного освобождения» решает помочь Максу и укрывает на своей подпольной базе, в обмен на услуги хакера/киллера.

По ходу сюжета игрок раскрывает тайный план корпорации MegaZet (подумать над названием), производящей нанороботов. В 2084 году новая технология, заключающаяся в введении в организм особых наномашин, усиливающих обычные способности человека, внедрена повсеместно. Особенно популярна она в кругах военных, полиции, а также мафиозных структурах. В ходе расследования Макс обнаруживает, что нанороботы, производящиеся MegaZet, могут использоваться для контроля сознания человека, в которого внедрены. Главный герой раскрывает план корпорации, заключающийся в создании «совершенного» общества, где любое проявление свободомыслия карается, а воля человека жестко контролируется «во имя высшего блага». Герой так же узнает, что глава правления корпорации является искусственным интеллектом, занявшим место своего создателя. Последние уровни игры проходят в штаб-квартире корпорации, а финальный босс, которого предстоит победить игроку – это ИИ, управляющий огромным роботом.

Gameplay

Основные ориентиры: Remember Me (элементы из боевой системы), Deus Ex (система прокачки взаимодействие с персонажами и окружением, диалоговая система), Teenage Mutant Ninja Turtles: Turtles in Time Re-Shelled (боевка), Mother Russia Bleeds (боевка), Double Dragon Neon (боевка)

• Игровой процесс выполнен в стиле Beat ’em up игр с элементами ролевых игр (относительно свободные фрагменты локаций, "спокойные моменты" с возможность взаимодействия с персонажами через диалоговую систему).
• Отличительной особенностью игрового процесса является возможность свободного перемещения по уровню. Игрок может входить в здания и тем самым находить скрытые предметы и побочные задания, многие из которых можно пройти разными путями.
• На определенных участках уровня включается "режим боя", во время которого передвижение по уровню ограничивается до тех пор, пока игрок не уничтожит всех врагов, появляющихся на поле боя. Некоторые бои могут сопровождаться катсценами.
• По ходу прохождения игрок встретится с большим количеством разнообразных врагов, в числе которых: полицейские, панки / еретики и уличная шпана, адепты церкви, мутанты, роботы, киборги, солдаты и агенты корпораций. Причем у каждого противника есть свои слабые и сильные стороны. Так, например, полицейские могут выставлять энергетические щиты и блокировать атаки, в связи с чем игрок вынужден использовать телепортацию, чтобы оказаться у противника за спиной.
• По окончанию уровня игроку предстоит сразиться с уникальным тематическим боссом.
• Помимо приемов рукопашного боя, игроки могут использовать аугментации (лазер, энергетический выброс и т.п.), которые можно разблокировать по мере набора опыта и продвижения по сюжету.
• Предполагается одиночное прохождение. Также рассматриваются кооперативный (hotseat) режим и "Арена" (замкнутый уровень с бесконечным количеством врагов, где побеждает игрок, набравший больше всего очков).

Системные требования

TBA
Тесты на различных конфигурациях еще не проводились.

Сроки

Deadline для демо-версии: TBA
Сроки разработки: 11 - 14 месяцев
Ориентировочная дата начала разработки: октябрь 2017 года

Dec. 12th, 2009 | 02:42 pm

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

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

О проекте

01

Resonance - психологический триллер, игровой проект в жанре adventure действие которого происходит в мрачном sci-fi сеттинге во время загадочной аварийной ситуации на орбитальной исследовательской станции «Провидец» в 2178 году. На протяжении игрового процесса игроку предстоит разобраться в причинах аварийной ситуации, возникшей на станции, встретиться со странными обитателями «Провидца», раскрыть тайну их появления, побывать в открытом космосе и спасти станцию от пожара, а к концу игры совершено по новому посмотреть на произошедшие на «Провидце» события… В техническом плане это игра с видом от первого лица, панорамными локациями с возможностью поворота на 360 градусов, дискретным перемещением между панорамами и point-and-click интерфейсом.

Основные особенности

04

Многослойная динамичная сюжетная линия, постоянно меняющая отношение игрока к происходящим событиям. По ходу игры из научно-фантастического сеттинга с налетом мистики игрок оказывается в атмосфере психологического триллера, постоянного напряжения и паранойи в сюрреалистической оболочке, где на первый план выходят темы внутренних конфликтов и расстройства сознания. Мрачные высокодетализированные интерьеры разрушающейся космической станции. Прекрасные космические сцены - открывающиеся из иллюминаторов туманности, астероидные поля, красивая безымянная планета, на орбите которой находится «Провидец», ощущение бесконечного пространства холодного космоса, окружающего станцию. Динамические постэффекты и авторский подход к стилизации. Эффекты блера, блума, огня и дыма. Различные динамические световые эффекты. Качественные видеовставки в игровые сцены. Все персонажи являются реальными актерами, отснятыми на bluescreen’e, стилизованными и интегрированными в игровое окружение. Большое количество оригинальных паззлов, основанных на поиске закономерностей, внимательности, работе с объектами в инвентаре, нахождении нужной информации во время ведения диалога. Игроку предстоит налаживать работу различных бортовых систем станции, читать техническую документацию, заниматься поиском различных деталей и оборудования.

Часть 1

Первая задача игрока в начале игры - это восстановление главных элементов жизнеобеспечения станции, налаживание связи с планетарной базой и попытка разобраться, куда пропал весь персонал комплекса, т.е. исследование интерьеров сегментов станции. Игроку предстоит совершить ряд задач, связанных с нахождением путей к недоступным модулям станции, ремонтом оборудования, поиском недостающих деталей и чтением технической документации для выполнения тех или иных паззлов, связанных с работой аппаратуры комплекса. Большая доля игрового процесса первой части – исследование окружающего пространства, знакомство с интерьерами модулей станции, понимание внутриигровой логики, правил игры. Уже на этом этапе появляется подозрение, что за протагонистом кто-то наблюдает... Через некоторое время после начала игры, тут и там в разных сегментах станции начинают появляться (мелькать) призрачные силуэты маленького мальчика и таинственного старца - единственных кроме главного героя обитателей станции, существование которых изначально ставится под сомнение. Сейчас их присутствие это только игра теней, звуки за спиной, упавшая ручка со стола и т.п. Постепенно игрок сможет замечать где-то на периферии образы этих странных персонажей… После провальной попытки связаться с планетарной базой, течение сюжета резко изменяется. Из научно-фантастического сеттинга с налетом мистики игрок оказывается в атмосфере психологического триллера в сюрреалистической оболочке, где на первый план выходят темы внутренних конфликтов и расстройства сознания. Основные паззлы: Наладить работу системы электроснабжения Попытаться восстановить систему связи с планетарной базой

Часть 2

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

Часть 3

Станция на грани уничтожения. У игрока два пути - либо он пытается спасти станцию от разрушения, либо выбирает вариант улететь со станции на челноке. Это кульминационный игровой эпизод. Все окружение, как и сами события, принимает небывалую (для жанра квест) динамичность. Хоть и задачи в этой части (как и во всей игре) неограниченны во времени, но благодаря эффектам тряски, искрящейся тут и там проводке, вращающимся в иллюминаторах частям разрушенных модулей, благодаря звукам скрипов метала и падающего на пол оборудования, у игрока появляется ощущение, что времени у него фактически нет, что станция вот-вот разрушится… Если игрок идет по первому пути, решая попытаться спасти станцию, то в его задачу будут входить паззлы связанные с выравниванием орбиты станции. При этом мальчик, видя, что у главного героя есть шанс спастись, из последних сил с истерикой в голосе всячески пытается этому помешать, постоянно встревая с язвительными нотками в работу протагониста. Но если игрок решит оставить станцию, а для этого потребуется подготовить спасательный челнок, мальчик начинает вести себя несколько по-другому... На его лице хитрая улыбка, речь становится спокойней и сдержанней, как и все его поведение в целом. Единственное, что игрок услышит от второго обитателя станции (независимо от выбранного пути) – это только несколько вздохов по поводу происходящего (как будто все это он видит уже не в первый раз) да пару неоднозначных полных грусти и какой-то опустошенности взглядов в пустоту холодных интерьеров станции… Основные паззлы: Спасти станцию от разрушения (или) Улететь с разрушающейся станции

Варианты концовки

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

Трактовка концовки

Вне зависимости от варианта концовки есть несколько версий объясняющих происходящие на станции событии. При этом все они будут иметь полное право на существование. Игра не отвечает на все поставленные в ней вопросы, оставляя это игроку, но предпосылки, появляющиеся на всем протяжении игрового процесса, могут привести к следующим умозаключениям: Можно предположить, что два странных обитателя станции являются альтернативными личностями главного героя, страдающего «диссоциативным расстройством идентичности». Их присутствие и привело к нарушению работы станции. Точнее, протагонист, находящийся под контролем альтернативной личности, избавился от персонала и нарушил функционирование «Провидца». При этом он просто не помнит совершенные в таком состоянии действия. Само существование главного героя можно поставить под сомнение. В сюжете присутствуют неявные намеки, благодаря которым можно предположить, что сам главный герой является «ложной» личностью, а вот один из обитателей станции как раз объективно существует в реальности. Это может быть как мальчик, который пытается просто разрушить «ложную» личность, так и старик, который потерял контроль над своими альтернативными личностями и оказался больше не способным как-либо препятствовать их действиям. «Провидец», где разворачивается действие игры - плод воображения одного из трех персонажей игры, визуализация его внутреннего мира. При этом протагонист может быть как реальной, так и альтернативной личностью. Такое положение вещей объясняет, почему нет никаких конкретных упоминаний об экипаже, который якобы пропал. Если интерьеры станции ограничивают созданный воображением иллюзорный мир одного из персонажей игры, то становится понятно, почему нет упоминаний о местонахождении станции, почему в бортовых записях не указано название планеты и звездной системы, где находится «Провидец» и почему не удалось связаться с планетарной базой.

|

Comments {14}

(no subject)

from: thirteen_thirty
date: Dec. 13th, 2009 08:57 am (UTC)

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

|

(no subject)

from:
date: Dec. 13th, 2009 10:22 am (UTC)

Интересно. Прочитаю обязательно.

Когда писал концепт, я больше ориентировался на реальные клинические истории и несколько известных экранизаций. В целом очень интересна тема расстройства сознания, которая еще не раскрыта в играх.

| |

(no subject)

from: thirteen_thirty
date: Dec. 13th, 2009 05:58 pm (UTC)

Да, тема интересная. Из литературного про расщепление сознания вспомнился "Вильям Вилсон" того же Эдгара Аллана и очень сильное, на мой взгляд, произведение Лавкрафта "За Гранью Времен", ну я вообще Лавкрафта очень люблю, как и многих уже почти позабытых авторов стиля "ужас и сверхестественное"(Мачен, Блэквуд, Смит, Дансани и тд) Практически неисчерпаемый источник для вдохновения, а в играх как-то мало такого, а ведь такая атмосфера мощнейшая, да и просто очень интересный срез настроения/мировосприятия.

| |

(no subject)

from: agent_al
date: Dec. 13th, 2009 11:56 am (UTC)

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

|

(no subject)

from:
date: Dec. 13th, 2009 12:49 pm (UTC)

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

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

> Существует же стандарт составления документации на стадии проектирования, которому учат даже в профтех училищах, не говоря уже про ВУЗы.

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

Разработка игр ,

Разработка веб-сайтов

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

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией 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 . Этот документ уже масштабнее, и обычно включает в себя следующие элементы:

1. Краткое описание игры . Здесь уже не только основная идея, а игра в целом.
2. Жанр игры .
3. Целевая аудитория и исследование рынка .
4. Примеры подобных игр на рынке и отношение к ним: конкуренты они или нет, есть ли пересечение аудитории, заимствование или противопоставление идей.
5. USP (Unique Selling Points) игры – то, что выделит игру на рынке, и что использует маркетинг для привлечения трафика / новых игроков.
6. «Формула успеха» – какие элементы игры будут самыми качественными / важными. Это может быть революционная графика, честная физика и т.д. Здесь в отличие от USP нужна не уникальность, а качество.
7. Составляющие геймплея , вкратце.
8. Сеттинг и стиль игры . Например, жестокий киберпанк в жёлто-серых тонах, светлое эпичное фэнтези в аниме-стиле, только куда подробнее и с примерами арта;
9. Бизнес-модель , в том числе монетизация.

Последовательность и цели написания здесь очевидны: написав концепт-документ, геймдизайнер определяет основную идею. Далее в Vision он описывает, как и почему эта идея будет работать: на какой аудитории, за счет каких элементов проект будет пользоваться успехом, и как он будет зарабатывать деньги. При этом, написание концепта и Vision – итеративный процесс. Написав концепт, можно попробовать продать предложенную в нем идею (инвестору, начальству, на крайний случай – самому себе) и улучшать его до тех пор, пока идея не будет продана. Написав Vision, можно оценить, есть ли у игры шансы на популярность и коммерческий успех, и перерабатывать его, меняя USP, сеттинг, стиль и прочие переменные, пока не будет хоть какая-то уверенность в результате.

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

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

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

Однако в любой крупной компании нужно сочетать три вещи:

• Шаблоны . Да, шаблоны и творчество могут казаться трудно совместимыми, но если на проекте несколько геймдизайнеров, и каждый пишет, как ему вздумается, продюсерам и исполнителям это радости не добавит.
• Связи с другими документами, фичами и задачами . Каждый диздок – это не просто сферический текст в вакууме. Он входит в какую-то группу (например, PvP-фичи), ссылается на другие документы, содержит в себе список задач (в JIRA/Bugzilla/Trello/GitHub/…), оценки готовности, ссылки на отчеты тестеров и результаты плейтестов.
• Собственно, фан и геймплей! За всеми слоями структуры диздока важно не потерять то, что игра все-таки должна быть интересной и увлекательной, фича должна работать в плюс всей игре, а не просто выполнять оторванную от общей идеи задачу.

Что же стоит описать в диздоке? Помимо просто описаний самой фичи, есть немало других элементов:

• Автор и статус (черновик, в работе, сделано, отказались, устарело). Когда на вики сотни диздоков, и за долгие годы работали десятки геймдизайнеров, без этих простых разделов понять, какой диздок актуален, затруднительно.
• Текущая задача . Что хочется получить. К примеру, обеспечить игроков развлечением, пока тренируются войска в казармах.
• Причины возникновения задачи и необходимости решения . Важный пункт, наличие которого спасает от фичей «чтобы круто было» или «у конкурентов есть». Последнее – бич многих геймдизайнеров, когда фичи копируются подчистую, даже несмотря на то, что многие их элементы в разрабатываемой игре лишние, не будут работать или работают в минус, даже если у конкурента это USP и приносит огромный доход.
• Краткое описание решения. Чтобы можно было охватить общую идею.
• Развернутый дизайн . Подробное описание реализации.
• Ожидаемое поведение игрока, типовая сессия. Нужна для того, чтобы ответить на вопрос «А как в это играть?» с позиции игрока. Без этого легко получить фичу, которая вроде бы и имеет смысл, но игроки на форумах пишут “И что это вообще такое?”.
• Место фичи в игре и связь с другими фичами. Очевидно, фича должна поддерживать и дополнять другие фичи или общий геймплей игры, а не повторять или подавлять их собой.
• Задачи на реализацию и ассет лист. Список того, что нужно сделать, чтобы фича заработала: какие функции на уровне кода, что нарисовать художнику, нужно ли написать тексты реплик персонажей сценаристу и т.д. Иногда это составляет продюсер, но нередко и сам геймдизайнер.
• Требуемая статистика. Какую информацию собирать и анализировать с плейтестов и серверов. Как много времени игроки проводят в геймплее фичи? Ездят ли они на лошадях или автомобилях в фиче о средствах передвижения, стреляют ли из Сайги или Вепря в ближнем бою шутера?
• Требуемое тестирование (+ edge cases). На что QA-отделу обратить особенное внимание при проверке фичи. QA могут такое составлять и сами, но нередко только геймдизайнер может сходу сказать, что «если вдруг игрок эксплоитами типа сложения эликсиров наберёт 1000 навыка Торговли, то сможет продать товар дороже, чем купил, и сломает всю экономику! Поэтому нужно убедиться, что такое невозможно даже теоретически».
• Deployment и оперирование. Раздел для оператора. Как описать фичу в patch notes? Нужно ли выложить о ней статью в энциклопедию игры? Требуется ли что-то отобрать у игроков и выдать компенсацию для запуска фичи?
• Планы на будущее. Собственно, все идеи, которые могут улучшить фичу в будущем.

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

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

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

Ни один «гениальный» ночной бред не выдержит испытания бумагой. Останется только то, что действительно можно реализовать, то, что кажется интересным и перспективным. Эта прописная истина известна каждому опытному разработчику. Однако нам регулярно задают вопросы по поводу дизайн-документа: что такое, зачем он нужен, как его написать. В самом ближайшем будущем мы собираемся опубликовать на страницах «Мании» подробный материал на эту тему. Но он будет сугубо техническим, а сегодня про диздок вам расскажут люди, которые не раз писали его сами:

DM - Дмитрий Гусаров , руководитель Katauri Interactive ;

B.W. - Иван Мороз , продюсер компании «Новый Диск »;

Mushroomer - Василий Кашников , менеджер Temporal Games ;

nordman - Сергей Романов , PR-менеджер издательства Play Ten Interactive ;

Jool - Евгений Братков , ведущий геймдизайнер Skyfallen Entertainment ;

Feodor - Федор Мукин , директор компании Arise ;

Zorich - Александр Зорич , писатели-фантасты Дмитрий Гордевский и Яна Боцман .

Представители «Игромании» в лице Владимира Болвина , Алексея Макаренкова и Светланы Померанцевой регулярно вставляли в беседу свои пять копеек. К концу разговора денег как раз набралось на три порции шашлыка с лучком и петрушкой.

Игровая документация

[Игромания]: По сообщениям из достоверных источников, в издательствах сегодня строго - на входе все разработчики должны показывать документы. И не диплом, паспорт или свидетельство о браке. Предъявлять нужно игровую концепцию и дизайн-документ. К сожалению, их не получишь в вузе, не купишь в переходе метро, поэтому остро встает вопрос: что это за бумаги и как их правильно составить?

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

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

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

: Сверхзадача, стоящая перед составителями, сложна и неоднозначна. В идеале диздок должен быть понятен и удобен для применения:

В качестве основного документа разработки (как основа игры). Причем каждому подразделению команды интересны разные части этого документа, но все вместе они должны удовлетворять потребности всех;

Издателю (неважно, реальному или потенциальному). Он должен знать, за что же ему придется платить деньги ближайшие несколько лет;

Новым участникам - для изучения содержания проекта на любом этапе разработки.

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

: Диздок - это рабочий документ, с которого все начинается и который редактируется до конца проекта. Скорее даже документище. А если говорить о концепте, то полностью продумать игру изначально не получается. Так не бывает. Бывает отдельная идейка или несколько идеек, которые хочется реализовать. Начинается процесс «лепки» - мысленно берется какая-то игра и изменяется. Ненужное выкидывается. Вставляются идейки. И что-то в итоге получается.

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

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

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

При этом нужно учитывать следующее:

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

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

: Отвечу со стороны издателя. Концепция игры - это представления разработчика о том, что в проекте будет привлекать игроков. Эдакая квинтэссенция диздока. Единого шаблона не существует, но есть вещи, которые в концепции принято отражать, и их уже перечислил Mushroomer. Добавлю только, что если команда имеет опыт общения с западными издателями, то она готовит еще несколько документов. Например, конкурентный анализ. И очень желательно, чтобы концепт сопровождался хотя бы самым ранним артом к игре. Картинки здорово украшают сухое текстовое изложение.

Диздок - максимально полное начальное описание проекта (начальное потому, что в будущем все может поменяться). По сути, он представляет собой развернутое описание положений из концепции с иллюстрациями по ключевым моментам проекта. Наиболее простая аналогия с концепцией и диздоком - курсовая и диплом, соответственно. Диздок должен снять все вопросы по проекту, даже гипотетические. Не мешает сделать к нему FAQ и там расписать, что, зачем и почему.

Структура диздока

: В содержании дизайн-документа можно выделить несколько основных разделов: Краткое описание . В идеале начинать нужно с него, чтобы, прочитав 2-3 страницы, сразу можно было получить общее представление о представленной игре без необходимости изучать все 300 страниц. Геймплей . Указать жанр и особенности игры. Довольно обширный и разноплановый раздел. Ролевая система . Описание принципов построения игровой механики, на которых базируется ролевая система игры. Само собой, пункт относится только к RPG. Сюжет . Подробное изложение сторилайна. Причем написанное не с упором на литературные прибамбасы, а в сторону логики и причинно-следственных связей. Сюда же входит общее описание игрового мира в целом. Технические особенности . Здесь говорится о графических и функциональных возможностях движка. Звук . Опционально. То есть либо все, что связано со звуком, описывается тут, либо выносится в отдельный звуковой дизайн-документ (что более правильно).

Кривая не вывезет

[Игромания]: Какие ошибки бывают на этом этапе работы? Способен ли неудачный концепт превратиться в неудачный диздок и (в последующем) в неудачную игру? Или все обязательно выправится по ходу дела?

: Основная проблема - когда на словах кажется, что все хорошо, а по мере приближения к реализации понимаешь, что ерунда какая-то написана. Все из-за невысокого уровня проработки и недостаточного опыта писателя. Документация - это хорошо, но писать ее чаще всего лень. Гораздо проще сказать словами. От этого возникает множество проблем. Диздок для издателя не главное, значительно больше инвестора интересует вопрос, кто будет делать игру.

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

Другая крайность - расплывчатые описания, подразумевающие множество смыслов. Например, «в игре будут красивые бои на автомобилях и с пулеметами ». Кто сказал, что будут? А почему на машинах, почему не внутри и не под ними? Бои с пулеметами наперевес, в союзе или может против пулеметов? Встречаются и неверно расставленные акценты. Скажем, если игра позиционируется как ураганный экшен, не нужно делать ставку на разветвленные диалоги и дополнительные квесты.

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

: Как правило, окончательный вариант игры сильно отличается от первоначальной идеи. Что-то разработчик меняет по ходу работы сам. Что-то под давлением издателя. Другой вопрос, что можно считать неудачной игрой? Если подразумевается отличие финальной версии от диздока по цепочке, как в «испорченном телефоне», то да, такое бывает. Допустим, геймдизайнер описал одно, художник понял и нарисовал другое, моделлер сделал третье - в итоге между идеей и конечным результатом лежит пропасть. Именно поэтому описание в диздоке должно быть максимально точным.

Если у разработчика есть хороший диздок, то можно сказать, что он на 30% готов к разговору с издателем. Остальные 70% включают в себя следующее:

Играбельную демку,

Умелую команду с длинным послужным списком,

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

При такой подготовке многие вопросы отпадут сами собой.

Противостояние мнений

У разработчиков встречаются полярные мнения по отношению к диздоку: Дизайн-документ - всего лишь циничный способ развести издателя на деньги: мы напишем ему то, что он хочет от нас услышать, а делать будем то, что получится. При этом обе стороны прекрасно знают об этом смешном обстоятельстве. Однако оба участника сделки усердно делают вид, что в этот раз все будет по-настоящему. В конце концов, главное - выпустить игру. А то, на что она в результате будет похожа, глубоко вторично. Дизайн-документ как устав вооруженных сил, где каждая статья написана кровью (сначала разработчиков, а потом издателя). За каждый пункт нужно стоять насмерть и отстаивать, как 28 панфиловцев отстаивали подступы к Москве. Ведь мы придумали отличную игру, подробно описали ее в диздоке, и наша задача состоит в том, чтобы убедить в этом издателя. Какая позиция правильней, сказать трудно. Ясно одно - получить деньги на разработку, не считаясь с мнением издателя, крайне сложно.

Ликвидация безграмотности

[Игромания]: Как стало известно, издатели придают большое значение оформлению диздоков. К примеру, не переваривают тексты с грамматическими ошибками и сильно переживают по поводу пунктуации. Не совсем понятно, каким образом это связано с игровыми идеями, заложенными в дизайн-документе. Разве талантливый геймдизайнер обязательно должен быть знатоком русского языка? Глядишь, за грамматикой и не увидят выдающейся игры. Зачем такое пристальное внимание к второстепенным деталям? «Космических рейнджеров» обвиняли в смешении жанров, гоняли от одного издателя к другому, говорили, что никто в такое играть не будет, и ведь ошибались! Притом, что потенциал в игре виден невооруженным глазом.

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

«Космическим рейнджерам» действительно пришлось трудно. Собственно, игра с первого взгляда никак не поддавалась описанию, классификации, ведь они излишне самобытны. Такие игры трудно оценить, особенно в условиях нехватки времени. К примеру, менеджер из компании «Бука », поиграв немного, сделал вывод, что такого добра им не надо. А вот в компании «1С» смотрели правильно. Сергей Герасев, менеджер по внешним проектам, разглядел игру и сказал, что геймплей есть. Бинго! Получаем контракт.

В наличии человеческий фактор: надо, чтобы начинающему разработчику повезло. Для этого нужно «качать» удачу. Как лучше прокачивать, молодые разработчики должны решать сами, но по опыту скажу, что это много важней, чем толстый диздок. Тем более если он написан невнятно, да еще и с грамматическими ошибками. Полагаю, тут есть над чем посмеяться издателям. Желательно набирать в команду побольше «везунчиков». Судя по опыту, это намного важней, чем любой толстый диздок.

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

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

Что касается ошибок, то они, конечно, недопустимы - как грамматические, так и логические. У издателя впереди месяцы и годы совместной работы с этим разработчиком. Если же он путается в своем собственном диздоке и не знает, что слово «раса» пишется с одной «с», то какую же страшную игру он сделает? Да и сделает ли вообще?

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

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

* * *

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