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

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

При работе в одиночку можно, конечно, обойтись и “записками сумасшедшего”, чего порой бывает вполне достаточно. При этом не имеет значения, где и в каком виде сделаны записи: в блокноте, на листочке, в электронном документе, в заметках на телефоне.... Главное, чтобы записи были сделаны: всё самое важное, что должно войти в проект и ничего не забыть.

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

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

Правила оформления документа просты:

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

2. Шрифт должен быть Arial или Times New Roman. Реже используют Calibri или Verdana. Не используйте другие шрифты, какими бы эпичными они вам не казались. В том числе не допускайте использования разных шрифтов в одном документе. Размер шрифта желательно ставить 14 кеглей. Больше – слишком крупно, меньше – напрягает зрение и отвлекает внимание.

3. Заголовки и подзаголовки выбирайте из меню оформления. Не нужно изобретать велосипед.

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

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

6. Старайтесь не использовать курсив – он плохо читаем, трудно воспринимается содержимое. Читатель отвлекается на внимательность чтения, и слабо усваивает материал.

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

Пожалуй это самые основные и важные правила оформления документа.

Что же должен содержать в себе концепт-документ?

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

В общих чертах концепт-документ можно составить примерно следующим образом:

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

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

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

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

- И последнее, что нужно ТОЛЬКО для переговоров с издателем, это бюджет на разработку и время его освоения.

Всё вышеперечисленное должно вписаться в 3-7 листов формата А4. Весь текст должен быть написан грамотно, кратко, без лишней “воды”.

Пример концепт-документа я покажу позднее, когда приступлю к рассказу о том, как делать игры.

Если концепт-документ это краткая презентация проекта, то дизайн-документ напротив – максимально полное описание будущей игры.

Дизайн-документ по своей сути “руководство” по воплощению задуманного проекта в готовую игру. Именно руководствуясь данным документом действует вся команда разработчиков.

Структура документа довольно сложная, и о нём мы ещё поговорим позднее в дальнейших текстоблогах. А пока кратко.

Структурно дизайн-документ можно разделить на 2 части.

Часть 1. Это развёрнутый рассказ об игре. Здесь описывается весь сюжет игры, все персонажи, их характеристики, внешность, описание мира, все монологи, диалоги, катсцены и прочее. Всё от А до Я и максимально полно.

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

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

В данной части дизайн-документа утверждаются требования к 3Д моделям – полигональность, метрика, форматы и т.п., требования к текстурам – минимальные и максимальные размеры, форматы и прочее. И всё, всё, всё… Звуковые форматы и качество, видеокодеки… Ну, в общем, ВСЁ! И максимально полно, развёрнуто и чётко.

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

Когда дизайн-документ готов и утверждён, команда может приступать к работе. Но никак не наоборот! Игра делается по дизайн-документу, а не дизайн-документ пишется по этапам разработки проекта. Это важно. И этим нельзя пренебрегать. Иначе проект попросту “завалится”.

Ну и последнее, но не в последнюю очередь, это заметки разработчика (Developer Notice), или проще говоря чеклист.

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

Чеклист – это “живой” документ. Не обязательно его вести в виде электронного документа и уж тем более соблюдать какие-то правила оформления. Часто чеклист ведётся прямо в редакторе кода, в созданном для этого документе, типа “CheckList.txt”.

Сюда в процессе разработки программист записывает свои мысли, чтобы не забыть их воплотить. Например, сделал программист управление персонажем: бег влево-вправо, выстрел и прыжок. И тут он такой: “О! Надо будет ещё выстрел в прыжке добавить.” И добавляет эту запись в чеклист, чтоб не забыть. И так далее. Позднее он заглядывает в чеклист, удаляет то, что уже сделал, и выбирает то, что можно реализовать сейчас.

И так документ дополняется, удаляются записи, и снова добавляются… До тех пор, пока не будут отчеканы все записи. Вот тогда и можно будет с облегчением сказать: “Игра готова!”

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

Подводя итог: как я уже сказал выше, работая малой командой или в одиночку, вы можете забить на дизайн-документ (но лучше бы немного написать, чтоб самому ясно иметь представление о том, что и как надо сделать), можно пренебречь концепт-документом (но воспитывать в себе привычку писать концепты я бы советовал от всей души!), но полениться вести чеклист – это уже апофеоз лени! ИМХО.

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