• Бизнес-модель игры: продажа отдельных копий игры, продажа дополнительного контента, внутриигровые покупки, реклама.
• Каким образом игра будет издаваться: самостоятельно или через издателя.
• Каким образом игра будет распространяться: цифровая дистрибуция и/или продажа на физических носителях.
Основные характеристики позволяют уже примерно представить, о чем идет речь: что это за игра, для кого, кем и как она будет делаться, как она будет зарабатывать деньги и как распространяться.
Дальше следует развернутое описание идеи.
• Описание игровых механик: какие механики будут в игре, какие ресурсы, игровые циклы.
• Описание игрового мира: описание мира и места, в котором происходит действие игры, которые обосновывают выбранный графический стиль и сеттинг и являются базой для сюжета.
• Краткое содержание сюжета (если он будет): описание основных персонажей и основных сюжетных поворотов.
Описание идеи должно показывать, чем наша игра будет выделяться среди других игр. Если жанром игры выбран шутер с открытым миром, то возникают референсы – одна-две игры с вполне определенным набором механик типа захвата форпостов и поиска древних реликвий по дальним закоулкам карты. Эти механики можно перечислить, чтобы понимать, что они будут в игре, но их необязательно объяснять, так как они уже являются стандартным набором для современных шутеров с открытым миром. Если же в игре будут относительно оригинальные для жанра механики, то им стоит уделить больше одной фразы. Например, для шутера с открытым миром это может быть механика починки транспортных средств и поиска запчастей для этого.
Основные характеристики и развернутое описание хорошо бы расписать, даже если проект является просто хобби, и обязательно это делать, если проект планируется как бизнес. Во втором случае еще необходимо прояснить ряд моментов.
• Сравнение с конкурентами: финансовые показатели конкурентов и какое-то преимущество, которое будет у нашего проекта по сравнению с проектами конкурентов.
• Описание имеющейся команды или имеющихся ресурсов: оно должно показывать, что наша команда со своими навыками соответствует выбранному проекту (что, если мы собираемся делать многопользовательский автосимулятор, у нас есть кому делать модели машин, писать сетевой код и настраивать поведение автомобилей).
• План разработки: он должен показать не только дату планируемого релиза игры, но и понимание того, из каких этапов вообще состоит процесс разработки игры и сколько эти этапы могут потребовать времени, специалистов и денег.
Содержимое концепт-документа зависит от типа игры, которую мы делаем. Его цель – коротко объяснить, какие механики будут в игре и как они будут использоваться, а также почему именно эти механики и использоваться именно так. Почему именно эта игра. Почему именно в таком стиле. Почему именно для этой аудитории. Может показаться очевидным, что мы выбираем делать небольшой сюжетный симулятор ходьбы, потому что хотим сделать игру в одиночку, ограничены в ресурсах или времени. Но есть довольно много жанров игр, за которые можно взяться в таких условиях. Например, мы решили делать симулятор ходьбы потому, что есть компонент управления персонажем, есть ассет с персонажем и набор ассетов для создания локации, хочется попробовать сделать что-то законченное.
Не на все вопросы получится ответить без определенного опыта. Не все ответы удовлетворят тех, кто эти вопросы будет задавать. Это нормально. И все же чем больше игра, чем больше людей над ней будет работать, чем больше денег вам будет нужно от инвесторов, тем больше будет вопросов и тем серьезнее придется продумывать ответы на них. Потому что варианты «Я так хочу», «Хочу попробовать реализовать эту механику» или «Мне интересен жанр» уже не подойдут. Все нужно будет обосновать.
В результате этой работы по поиску идеи и ее формализации в виде концепт-документа нужно будет принять собственное решение, если мы работаем самостоятельно, либо получить решение от инвестора или издателя о том, что разработка игры может переходить на следующий этап (или нет). Можем ли мы приступать к разработке прототипа или начинаем все сначала: искать новую идею, заново исследовать рынок.
Прежде чем переходить к следующему этапу, сделаем важное замечание: разработанная и утвержденная концепция игры не должна меняться в процессе ее реализации. Концепция – это фундамент, на котором строится игра. В западном геймдеве эти постулаты называют Core Pillars, ключевые принципы игры. И они могут только дополняться и уточняться скетчами или цифрами сравнения с другими играми. Если в идее игры что-то меняется, то это уже другая идея, которая может потянуть за собой изменение многих других важных частей игровой концепции. Например, стиль графики влияет на аудиторию, какие-то изменения в механике могут повлиять на позиционирование игры и на группу конкурентов.
Концепция игры – это то, что должно быть сделано один раз. Вся дальнейшая работа над игрой будет вестись только в соответствии с утвержденной концепцией. Более того, могут даже измениться методы разработки, условия, в которых разработка ведется, но на концепции это никак не должно сказаться. Например, работа над игрой может быть начата в маленькой команде собственными силами после основной работы, но в результате посещения какой-нибудь выставки или конференции игра может привлечь внимание издателя. К этому моменту у нас, безусловно, уже должен быть концепт-документ, который может быть лишь дополнен какой-то важной для бизнеса информацией.
Важно также понимать, что изменения в компании, типа появления инвестора или издателя, могут произойти в любой момент существования проекта. Мы можем захотеть выпустить игру на закрытом рынке типа Китая, и тогда появится необходимость в поиске партнеров для этого. Наличие готового концепта позволит ускорить процесс налаживания работы и покажет нас как надежного и подготовленного партнера.
Прототипирование
К этапу прототипирования мы можем прийти в разной степени подготовленности.
Стремиться надо к тому, чтобы к этому моменту у нас уже была разработана концепция игры, но ее может и не быть. Из-за этого в самой основе этапа могут находиться кардинально разные цели.
Если концепция еще не выработана, то целью этапа может быть поиск механик, которые могли бы натолкнуть на идею для игры. Это могут быть те же эксперименты по развитию собственных навыков. В случае успешного завершения этапа, когда основа для идеи будет найдена, придется вернуться обратно на этап формализации концепции, чтобы собрать остальной фундамент для будущего проекта.
Если же у нас уже есть утвержденная концепция, то целью этапа будет техническое подтверждение этого концепта. Это важно как с точки зрения самой возможности реализовать отдельные механики и весь проект, так и с точки зрения интересности игры. Да, концепция может оказаться не такой интересной, если попробовать в нее поиграть. И вопрос подтверждения концепта состоит из нескольких шагов:
• выдвижение гипотезы;
• первичная документация и исследование;
• прототипы отдельных механик;
• прототип игры.
Прежде всего нам необходимо выдвинуть набор гипотез, которые мы будем проверять разрабатываемым прототипом. Это может быть проверка основной механики игры: работает ли она так, как задумано, удобно ли управлять персонажем, насколько легко освоить механику. Может возникнуть и вопрос технической реализации, если какая-то игровая механика настолько оригинальна, что требует исследовать возможности игровых движков.
Гипотезы необходимо задокументировать. В процессе работы над прототипом можно будет сверяться с заявленными гипотезами, чтобы не тратить время на реализацию ненужных механик. А когда прототип будет готов, нужно будет дать конкретный ответ по заявленным гипотезам. На основе этих ответов будет приниматься решение о продолжении работы над проектом.
Чтобы начать самостоятельную работу над прототипом, необходимо уточнить набор игровых механик и ресурсов для игровых циклов. Суть проблемы заключается в том, что концепт-документ хоть и служит основой всего проекта, но все же не является документацией игры и не объясняет того, как игра должна на самом деле играться. К решению этой задачи есть два подхода. Нам в любом случае придется разработать какую-то предварительную модель игры, но заниматься этой разработкой мы можем как полностью самостоятельно, так и используя чужой опыт.
Еще на этапе работы над идеей мы искали похожие игры, на основе которых можно было бы оценить перспективы нашей игры. Но теперь на этапе работы над прототипом нам необходимо найти игры, в которых нужные нам механики будут реализованы максимально подходящим нам образом. То есть игра в целом может вообще не быть похожа на нашу концепцию, но в ней могут присутствовать интересующие нас механики: управление, квесты, кланы и т. п. Нас интересует метод реализации механики, и для этого нужно провести некоторое исследование того, как эта механика работает. Эти исследования бывают двух типов: деконструкция и декомпозиция.
Деконструкция – это более общее исследование, применяемое к целой игре. Здесь изучается, какие в игре есть механики, ресурсы, какова их взаимосвязь, устройство экономики игры, как работают (если они есть) социальные механики, монетизация, различные акции и события. Деконструкция помогает выявить набор дополнительных механик и других элементов игры, которые могли быть упущены на этапе проработки идеи.
Самый простой способ составить деконструкцию – это следовать за интерфейсом игры. Он подскажет, что в игре есть: например, несколько режимов битв, кланы, магазин, инвентарь и механизм прокачки персонажей – и вот мы получаем список механик, из которых состоит игра. В мобильных играх битвы часто используются как источники ресурсов, но имеют какие-нибудь ограничения, связанные с энергией или другими ресурсами, – это основа для игрового цикла, а значит, его также необходимо описать и исследовать. Нам остается лишь описать то, как работают эти механики и как устроены циклы, уделить внимание интересным элементам, которые имело бы смысл перенять.