К этапу прототипирования мы можем прийти в разной степени подготовленности.

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

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

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

• выдвижение гипотезы;

• первичная документация и исследование;

• прототипы отдельных механик;

• прототип игры.

* * *

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

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

Чтобы начать самостоятельную работу над прототипом, необходимо уточнить набор игровых механик и ресурсов для игровых циклов. Суть проблемы заключается в том, что концепт-документ хоть и служит основой всего проекта, но все же не является документацией игры и не объясняет того, как игра должна на самом деле играться. К решению этой задачи есть два подхода. Нам в любом случае придется разработать какую-то предварительную модель игры, но заниматься этой разработкой мы можем как полностью самостоятельно, так и используя чужой опыт.

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

Деконструкция – это более общее исследование, применяемое к целой игре. Здесь изучается, какие в игре есть механики, ресурсы, какова их взаимосвязь, устройство экономики игры, как работают (если они есть) социальные механики, монетизация, различные акции и события. Деконструкция помогает выявить набор дополнительных механик и других элементов игры, которые могли быть упущены на этапе проработки идеи.

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

* * *

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

Создание декомпозиции – более сложная работа, в которой следует уделить внимание часто скрытым, неочевидным элементам игры. Изучение камеры аркадной игры может потребовать буквально измерения экрана линейкой. Шутеры крайне редко показывают значения урона, наносимого разным оружием при попадании в разные части тела противника или техники. Многие игры имеют прогрессии опыта, уровней, стоимости предметов и уровней построек, соотносимые с бонусами, которые эти предметы или постройки могут давать: более сильное оружие, более производительная постройка. При декомпозиции элементов игр необходимо понять не только то, какие значения используются для настройки этих элементов, но и почему: какое влияние эти значения или их рост оказывают на игру. В работе над декомпозициями неоценимую помощь могут оказать сообщества фанатов исследуемой игры: википедии, форумы, группы в соцсетях, чаты. Игроки знают игру не хуже разработчиков, но в отличие от разработчиков, всегда готовы поделиться своими знаниями.

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

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

* * *

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

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

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

Таким образом мы получаем некие коэффициенты роста цены каждого уровня относительно предыдущего или относительно первого уровня. Естественно, нам нужно убедиться в том, что эти коэффициенты работают на всех постройках. Некрасивые, некруглые числа и разница в коэффициентах для разных построек легко объясняется тем, что разработчик оригинальной игры округляет цены до тысяч. При желании мы можем даже выявить формулу, по которой эти коэффициенты рассчитываются: например, (0,5 + 0,1 × (N – 1)) × N, где N – это номер уровня постройки, начиная со второго. Но исследования следующих деревень покажут, что коэффициенты не меняются ни от постройки к постройке, ни от деревни к деревне, а значит, их можно принять за константы.

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

С ценой первых уровней каждой из построек можно поступить примерно так же: делением.

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

Эта цифра оказывается очень близка к корню игры – основе ее баланса и всей идеи, а значит, простого коэффициента там, скорее всего, не получится. Нам необходима формула роста. Придется потратить какое-то время, чтобы собрать всю необходимую информацию для ее выведения: цены первых уровней первых построек, например для первых десяти уровней: 60 000, 101 000, 180 000 и так далее.

Но какую роль на самом деле играет формула роста стоимости построек в игре? Дело в том, что кроме роста стоимости построек, конечно же, в игре есть рост наград, получаемых игроком в боевой части игры. Так как награды выдаются там случайным образом, выявить формулу роста наград в обозримое время невозможно: для этого нужно несколько десятков раз начать игру заново, собирая статистическую информацию о каждой битве. Формула же роста стоимости построек не предполагает никаких случайностей и позволяет нам опосредованно оценить и то, как растут награды. Но все же мы не можем знать всех подробностей устройства изучаемой нами игры, и полученные нами выводы остаются лишь предположением. Когда мы будем восстанавливать оригинальную математическую модель в своей игре, мы сможем проверить достоверность этого предположения на собственном опыте.

* * *

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

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

Сама по себе работа над документацией игры в значительной степени похожа на те же деконструкции и декомпозиции других игр. Только в этот раз нам придется провести деконструкцию игры, которая пока существует только в нашей голове, что значительно усложняет задачу. Ведь у нас пока нет даже макета интерфейса, который мог бы подсказать, все механики мы описали или нет. Есть множество методик, помогающих в составлении документации, чтобы не забыть ничего важного: например, ментальные карты (mind map). Они позволяют представить буквально всю предстоящую работу в виде дерева логических связей или шаблоны уже готовых диздоков успешных проектов.

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

* * *

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

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

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

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

«Бумажный прототип» – это метод разработки механик, программного обеспечения, гейм-дизайна, когда на бумаге создаются наброски от руки. Отсюда и название. Это может быть также настольная игра. Бумажный прототип позволяет проверить гипотезы и идеи реализации продукта, не прибегая к дорогим методам разработки на первоначальном этапе.

Сама проверка механики необязательно должна выливаться в написание кода. Мы можем проверить ее, например, в виде настольной игры. Особенно если нашей задачей является проверка того, насколько механика интересна, а не какова возможность ее реализации. Такая настольная игра может быть сделана буквально «на коленке»: можно взять бумагу из тетради или принтера, нарисовать карту, вырезать карточки действий и персонажей. Генератор случайных чисел в виде игрального кубика можно взять из другой настольной игры или найти в интернете.

* * *

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

Итак, нам нужно немножко поработать руками.

• Так как фабрика, по сути, разделена на отдельные зоны, в которых работают отдельные персонажи, эти зоны у нас будут изображать листы бумаги с названиями зон. Пока зон у нас будет две: зона разгрузки и зона сортировки.

• У нас будет набор карточек с персонажами с разными случайными характеристиками. Карточки мы вырежем из той же бумаги, напишем на них имена персонажей, нарисуем портреты и распишем характеристики. Кому-то достанется +2 на сортировку стекла, кому-то +5 на управление погрузчиком и т. п. Мы можем сделать с десяток таких карточек и ограничим игрока правилом, что из персонажей он может взять только троих случайных. Двух можно поставить в зону сортировки, а одного на разгрузку.

• Мусор у нас будет в виде фишек – клочков бумаги с разными обозначениями: С – стекло, Б – бумага и т. п. Таких фишек нам нужно штук 50.

Дальше идет сам игровой процесс.

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

– Скрытость мусора – это довольно важное уточнение, о котором мы могли не подумать с первого раза. Если мы случайно нарисуем обозначение мусора на обеих сторонах фишки, то нам придется их переделывать. Это маленький урок итеративности.

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

– Уже здесь можно немного задуматься над балансом игры. Игроку в начале хода может прийти и одна единица мусора, и шесть. Иногда игроку будет приходить меньше мусора, чем он может перевезти, а иногда больше. Тогда мусор начнет накапливаться в зоне разгрузки. В среднем d6 будет давать значение 3,5. Соответственно ставить на разгрузку персонажа с навыком меньше 4 довольно рискованно.

• В зоне сортировки мусор можно раскрыть и перевернуть. Сортировщики работают примерно по тому же принципу, что и погрузчик: игрок может переместить столько мусора, сколько очков есть у персонажей, находящихся в зоне сортировки. Если у нас есть два персонажа: на 2 очка стекла и 3 очка стекла – значит, суммарно за ход игрок может отсортировать 5 единиц стекла.

* * *

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

• создаем новую версию;

• тестируем;

• получаем отклик;

• повторяем до тех пор, пока отклик не будет достаточно позитивным.

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

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

На этом этапе у нас пока еще нет ничего, кроме механик. Нет графики, звуков.

Интерфейсы пребывают в зачаточном состоянии и выполняют только базовые, тестовые функции.

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

Для проверки некоторых механик может быть достаточно простых кубиков, которые могут выполнять роль персонажей и объектов сцены. Но в некоторых случаях могут понадобиться более сложные модели: например, если надо проверить какое-то сложное управление персонажем или для наглядности добавить анимации. При отсутствии собственных графических наработок можно использовать доступные в интернете ассеты и бесплатные модели, входящие в комплект игрового движка. Но не стоит увлекаться поиском подходящих ассетов – для этого еще придет время.

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

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

Блокаут (blockout) – это один из начальных этапов проработки уровня. Процесс блокаута состоит из двух частей: грейбокс (gray box – «серая коробка») и вайтбокс (white box – «белая коробка»). Грейбокс – это макет уровня, собранный из примитивов: кубов, шаров, цилиндров обычно серого цвета. Примитивы позволяют выстроить топологию уровня, проработать маршруты передвижения игрока и неигровых персонажей, расставить точки интереса и подчеркнуть их геометрией. Собранный таким образом уровень должен быть прежде всего проходимым и интересным. На этапе вайтбокса к примитивной геометрии добавляется более проработанный декор, который помогает визуально подчеркнуть важные для истории, сюжета и нарратива элементы уровня.

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

* * *

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

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

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

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

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

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