Время от времени на форумах начинающих разработчиков вижу вопросы типа: “С чего начать разработку игры?” или “У меня есть идея гениальной игры, что дальше делать?” Нередко на такой вопрос отвечают: “Пиши дизайн-документ”.
И это один из самых худших советов.
Тут два нюанса: во-первых, начинать нужно точно не из дизайн-документа. А во-вторых, про дизайн-документ в его изначальном виде вообще нужно забыть.
В 90-х и 2000-х издатели требовали от разработчиков дизайн-документы игр. Есть даже легенда, что в конце девяностых у одного большого издателя при принятии решения о финансировании разработки менеджеры бросали диздоки на весы. Самый тяжелый выигрывал.
Что такое диздок? Это адский документ, содержащий описания персонажей, уровней, графического стиля, геймплея, оружия, интерфейса, а также сюжет, технические особенности движка и т.д. Документом неудобно пользоваться, в нем сложно находить нужную информацию, его сложно поддерживать в рабочем состоянии и, самое главное, его никто не читает.
Итак, диздок – это описание всей игры. Но для чего и для кого нужно описание всей игры? И тем более для чего оно нужно начинающему разработчику, который даже представления не имеет, как делать игры?
В жизни в целом и при ведении документации в частности нужно понимать, зачем что-то делаешь. Нужно поставить цель, а потом искать инструменты для ее достижения.
Раньше большинство издателей даже не смотрело в твою сторону без диздока. Но времена изменились – издатели понимают, что дизайн документ, написанный до старта разработки игры – это макулатура. Более того, с развитием интернета у разработчиков появилось множество способов ведения удобной документации. И надобность в одном документе отпала сама собой.
Нужно сформулировать для себя и команды о чем игра? Достаточно краткого описания на одну-две страницы (концепт-документ). Нужно объяснить программисту, как работают какие-то механики? Пишите техническое задание (ТЗ). В игре много механик? Пишите много заданий, свяжите их между собой ссылками и организуйте документы в удобную иерархическую структуру. Нужно рассказать издателю об игре? Подготовьте документ, который кратко рассказывает об игре, монетизации и вашей компании (питч).
Документация – это инструмент, который позволяет достичь определенных целей. Не обязательно знать о разных типах документации, чтобы достигать целей. Достаточно иметь только здравый смысл и понимать, что и для чего делаешь. Очевидно, что одним монолитным документом пользоваться неудобно. Значит, нужно сделать удобно: или раскидать по папкам отдельные документы, или завести структурированную wiki, или пользоваться Google Docs. Но только не пишите один большой неуклюжий документ.
Некоторые тезисы:
- Не пишите дизайн документ. Пишите нужную для разработки документацию.
- В сети есть пример дизайн документа, составленный в компании 1C (про курочку Рябу). Он давно устарел. Использовать его не нужно.
- Допустим, у вас есть идея уникальной игры. То, что игра будет интересной – лишь гипотеза. Гипотезу нужно проверять прототипом.
- Невозможно написать диздок, а потом по нему сделать интересную игру. Создание игры – итеративный процесс. Аддиктивность, удовольствие от игры, интерес строятся в процессе создания игры, итерация за итерацией. Заранее нельзя предсказать, куда повернется разработка.
- Ходит мнение, что чтобы научиться игровому дизайну, нужно писать диздоки. Иногда получаю письма: “У меня есть опыт гейм-дизайна, я написал три дизайн-документа для своих игр.” Это не имеет отношения к действительности. Научиться игровому дизайну можно только создавая игры, в которые потом играют люди.
На вопрос: “С чего начать разработку игры?” можно ответить множеством способов. Я, например, предлагаю на одной странице описать игру, скачать бесплатный игровой движок и попробовать сделать прототип. Время не будет потрачено зря. Но не нужно писать дизайн-документ. Не тратьте свое время впустую.
