Записки программиста #5. Концепт документ, да или нет?

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

И так, что это вообще такое «Концепт документ» и с чем его едят.

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

Такой документ составляется игровым дизайнером, но в моем проекта я и дизайнер и программист, и спонсор и кем я только не являюсь =))) Но трудности ведь закаляют;-)

Концепт-документ может строиться по следующей схеме:

1. Введение
2. Жанр и аудитория
3. Основные особенности игры
4. Описание игры
5. Сравнение и предпосылки создания игры
6. Платформа
7. Контакты

Во первых определитесь, для чего Вы его пишете вообще, а если не можете ответить на этот вопрос, то зачем Вы его пишете?! Что бы было? Я думаю не стоит…

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

После того как вы это сделайте, стоит взяться за «Дизайн-документ».

Типовой дизайн-документ может иметь следующую структуру:

1. Введение

2. Концепция

2.1. Введение

2.2. Жанр и аудитория

2.3. Основные особенности игры

2.4. Описание игры

2.5. Предпосылки создания

2.6. Платформа

3. Функциональная спецификация

3.1. Принципы игры

3.1.1. Суть игрового процесса

3.1.2. Ход игры и сюжет

3.2. Физическая модель

3.3. Персонаж игрока

3.4. Элементы игры

3.5. "Искусственный интеллект"

3.6. Многопользовательский режим

3.7. Интерфейс пользователя

3.7.1. Блок-схема

3.7.2. Функциональное описание и управление

3.7.3. Объекты интерфейса пользователя

3.8. Графика и видео

3.8.1. Общее описание

3.8.2. Двумерная графика и анимация

3.8.3. Трехмерная графика и анимация

3.8.4. Анимационные вставки

3.9. Звуки и музыка

3.9.1. Общее описание

3.9.2. Звук и звуковые эффекты

3.9.3. Музыка

3.10. Описание уровней

3.10.1. Общее описание дизайна уровней

3.10.2. Диаграмма взаимного расположения уровней

3.10.3. График введения новых объектов

Контакты

Примеров «Дизайн-документ» в интернете ходит много.

Я бы туда добавил бы еще календарный план разработки игры, а также ресурсы которыми обладаем и которые необходимы.

Выводы:

Написав все это, у Вас появиться довольно неплохое виденье проекта в деталях, а также поможет привлечь не достающие ресурсы.

Когда его стоит писать? Насчет того, что начинать стоит с него, если Вы инди разработчик, я не согласился, я его написал перед привлечение новых людей в проект, после редактора физики, к тому моменту идея окончательно созрела в голове;-)

Удачи в разработке;-)