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

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

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

[Jool]: Сверхзадача, стоящая перед составителями, сложна и неоднозначна. В идеале диздок должен быть понятен и удобен для применения:
— в качестве основного документа разработки (как основа игры). Причем каждому подразделению команды интересны разные части этого документа, но все вместе они должны удовлетворять потребности всех;
— издателю (неважно, реальному или потенциальному). Он должен знать, за что же ему придется платить деньги ближайшие несколько лет;
— новым участникам — для изучения содержания проекта на любом этапе разработки.

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

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

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

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

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

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

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

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

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

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

Добавлено (30.09.2009, 10:08)
---------------------------------------------
Структура диздока выглядит так:

[Jool]: В содержании дизайн-документа можно выделить несколько основных разделов:

Краткое описание. В идеале начинать нужно с него, чтобы, прочитав 2-3 страницы, сразу можно было получить общее представление о представленной игре без необходимости изучать все 300 страниц.

Геймплей. Указать жанр и особенности игры. Довольно обширный и разноплановый раздел.

Ролевая система. Описание принципов построения игровой механики, на которых базируется ролевая система игры. Само собой, пункт относится только к RPG.

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

Технические особенности. Здесь говорится о графических и функциональных возможностях движка.

Звук. Опционально. То есть либо все, что связано со звуком, описывается тут, либо выносится в отдельный звуковой дизайн-документ (что более правильно).

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

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

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

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

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

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

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

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

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

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

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

Добавлено (30.09.2009, 10:12)
---------------------------------------------

[B.W.]: Если вам кажется, что потенциал в любом игровом проекте виден невооруженным глазом, то вам можно только позавидовать. В некоторых будущих играх я его совсем не вижу. А в некоторых он закопан настолько глубоко, что стоимость выкапывания зачастую выше стоимости самого потенциала. Да, «Космические рейнджеры» — хороший пример. Только приведите тогда уж и другие примеры — игры, которые были заплеваны игроками и прессой, хотя издатели увидели потенциал и открыли их! А видимо, зря, но потенциал же был о-го-го...

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

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

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

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

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

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

[Zorich]: Известно, что ряд современных писателей посредственно владеет русским языком. В этом нет ничего хорошего, но это факт. Что же касается геймдизайнеров, то они имеют право владеть русским языком хуже, чем писатели (или, скажем, сценаристы игр). От них определенно требуется высокая дисциплина мышления и владение языком на том уровне, которого требует внятное и доходчивое изложение своих мыслей.

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

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

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

Взято с clickforeplay.ru