Как ни странно, но работа игрового дизайнера заключается не только в бесконечной генерации идей, но и в создании различного рода документов, причем документация занимает достаточно много времени и отнимает много сил. Есть мнение, что при разработке игры в одиночку (в дизайнерских кругах это звучит как “пилить в одно лицо”) документация не требуется, но по моему мнению это не так. Ни один, даже самый маленький проект, я не начинал без предварительного описания, схемы экранов и подобных базовых документов. За годы проработки и воплощения идей, написания всевозможных ТЗ, диздоков и презентаций я сформировал некоторый подход к процессу документирования игр. О нем я и хотел бы рассказать.
Когда я пишу рабочие документы, то стараюсь соблюдать преемственность, увеличивать детализацию поэтапно:
- Pitch — одностраничное описание идеи для игры. Как правило такие документы пишутся быстро, начерно, в пару абзацев и с одним-двумя скриншотами из референсной игры и рассылаются внутри дизайнерского отдела. Конечно “пичтить” можно и на словах, но надеяться, что коллега, руководитель отдела или хэд студии играл в похожую игру не стоит. Pitch, который выжил..
- ..переходит в Proposal (иногда этот документ тоже называется Pitch, особенно если он создан для потенциального издателя)— детально расписанная идея с примерами похожих игр (механики, системы, арт-стиль и пр.) В этом документе можно встретить и подробности игровых механик, особенно если они – уникальные, и описание команды, и примерный финансовый план, и целевые показатели и много всего прочего. Если Proposal принят, то работа над игрой начинается и одним из первых документов должен..
- .. стать Game Vision — видение игры, причем в любом удобном формате. От лица игрока или дизайнера, в виде основных систем, дизайнерских “столпов” (desing pillars) или эмоций – не важно, главное, чтобы видение позволяло однозначно воспринимать идею игры всеми участниками процесса разработки. Однажды в роли Game Vision выступала презентация на 220 листов. Показывалась презентация ровно 15 минут, воспринималась легко, но готовить подобный документ достаточно сложно. Лично мне очень нравится формулировать видение как формулируют предмет социологического исследования (классное упражнение), а фичи описывать в формате mindmap. Ориентируясь на Game Vision и создается..
- наш главный Game Design Document — GDD, дизайн-документ или “диздок”, то есть подробное, крайне детализированное описание всех элементов игры. Большую часть этого документа составляют описания систем и фичей, а как структурированы сами описания (а так же формат документа) – зависит от множества факторов, основной из которых – потребности команды.
Далее при помощи дизайн-документа (так как основываясь ) формируются этапы разработки — milestones, — которые делятся на спринты. Хорошие примеры питчей для издателей я приведу прямо сейчас – для free2play игры отлично подойдет этот документ Ильи Еремеева, а для коммерческой игры питч игры World’s Bane. Пример дизайн-документа приводить смысла нет, а про описание фичей я бы хотел сделать большой пост в будущем.
Однако, я хотел рассказать совсем о другом важном документе, который тоже информирует команду о том, как выглядит игра, но немного с другой стороны. В тот момент, когда у команды уже имеется видение и mindmap – схема самых основных фичей и систем, но дизайн-документ находится еще в начальном состоянии, а обьем игры надо уже оценивать, то на помощь часто приходит Game Flow – схема экранов.
Схема экранов на этом этапе нужна, чтобы все члены команды поняли игровую структуру и из каких механик и систем игра состоит. По моему опыту, такой документ вырастает из схематичного отображения Gameplay Loop — игрового цикла типа «собери ресурсы, сделай меч, наруби больше ресурсов». Который я, например, люблю снабжать инконками ресурсов и отмечать откуда какие ресурсы исходят и куда вливаются – набрасывать “sinks and sources”.
Gameplay Loop, в соответствии с методологией G.R.I.P. (Goal->Research->Iterate->Polish) и особенностями развития игровой индустрии (в том, что мета-игр – негеймплейных игровых систем, меньше чем геймплеев и они появляются реже) часто является новой связкой геймплея и известной успешной мета-игры с некоторыми изменениями.
Я приведу пример для игры Metal Sky, которая была разработана разбросаной по миру командой энтузиастов, которым хотелось получить мультиплеерный сайд-скроллер для игры с друзьями.
Для игры была выбрана мета-игра из Brawl Stars (Supercell), как наиболее подходящая. Напомню, что в этой игре контент представлен “картами” персонажей, которые вместе в различными валютами находятся в ящиках. Ящики можно получать в игре разными способами, но основной – открывать их за токены, которые зарабатываются в боях. Фокус в том, что количество токентов в день ограничено, а количество боев – нет. Таким образом, ребята из Supercell жестко контролируют скорость открытия контента, но позволяют играть сколько угодно для прокачки скилла. Очень грубо говоря это вариация их предыдущей мета-игры в Clash Royale. Это отличное решение позволяет избавиться от более традиционной системы энергии, которую часто критикуют как раз за ограничение времени геймплея.
На основе данной меты была придумана своя, которая, тем не менее, отличается от оригинальной. В Metal Sky у игрока в основном режиме игры есть команда из трех самолетов (то есть коллекция самолетов больше), каждый самолет необходимо чинить если он был сбит в бою (или ждать пока он не починится автоматически), самолеты можно прокачивать и улучшать картами апргейдов (увеличивают/уменьшают характеристики). Кроме того, самолеты имеют разные роли в игре (истребители, бомбардировщики, штурмовики и т.п.), что добавляет элемент подбора свой, наиболее оптимальной, команды.
В конечном виде в игре должны были присутствовать разные режимы (до этого дошли) и социальные элементы (до это НЕ дошли), так же как и системы офферов, скидок, игровые события (был придуман отличный асинхронный режим с бомбардировкой нефтедобывающих вышек враждебных кланов). До того как все эти системы были подробно описаны в дизайн-документе была собрана схема экранов – Game Flow. Я поделюсь документом более низкого уровня – Game UI Flow, который уже содержит элементы игрового интерфейса. Такой документ сложнее воспринимать (соррян), зато он предоставляет необзодимую информацию и для UI-художника, а если вести команду поэтапно по всем документам, то разобраться в нем в общем-то не представляет большого труда.
Документы появились именно в такой последовательности и я действительно копировал содержимое предыдущего документа и делал новый на его основе. Таким образом, даже узкоспециализированный Game UI Flow подчиняется законам преемтсвенности документов, я бы хотел привести какое-то смешное сравение с эмбриональным развитием, но не ожидал, что статья получится такой большой и что-то уже “загустел” (Иван, привет!). Для тех, кто дочитал это до конца, сообщаю, что ссылки в заглавиях документов ведут не на картинки большего размера, а на документы в google draw – копируйте и рассмаривайте/редактируйте на здоровье. Так же я оставлю ссылки на документы в разделе Learn на сайте.