Декомпозиция же направлена на детальный разбор какой-то конкретной части игры. Она может исследовать работу камеры в аркадной игре, или параметры оружия в шутере, или экономическую модель в стратегии. Соответственно, она поможет получить довольно точные параметры настройки отдельных игровых механик еще до начала непосредственной работы над игрой. Настолько глубокое исследование всей игры обычно не нужно, да и слишком трудозатратно.
Создание декомпозиции – более сложная работа, в которой следует уделить внимание часто скрытым, неочевидным элементам игры. Изучение камеры аркадной игры может потребовать буквально измерения экрана линейкой. Шутеры крайне редко показывают значения урона, наносимого разным оружием при попадании в разные части тела противника или техники. Многие игры имеют прогрессии опыта, уровней, стоимости предметов и уровней построек, соотносимые с бонусами, которые эти предметы или постройки могут давать: более сильное оружие, более производительная постройка. При декомпозиции элементов игр необходимо понять не только то, какие значения используются для настройки этих элементов, но и почему: какое влияние эти значения или их рост оказывают на игру. В работе над декомпозициями неоценимую помощь могут оказать сообщества фанатов исследуемой игры: википедии, форумы, группы в соцсетях, чаты. Игроки знают игру не хуже разработчиков, но в отличие от разработчиков, всегда готовы поделиться своими знаниями.
К методу декомпозиции можно обратиться, даже если мы решили не пользоваться деконструкциями: для составления списка отдельных механик, ведь они более универсальны. Также декомпозиция поможет подобрать разные варианты реализации отдельной механики: мы можем изучить несколько аркад с отличающимися настройками камер, которые можно будет попробовать, непосредственно работая над прототипом.
В управлении проектами декомпозицией называется процесс разбора крупной задачи на более мелкие, которые можно распределить между различными исполнителями. Истории эти очень похожи глубиной проработки деталей. Но в случае деконструкции игровой механики исследование ограничивается ее дизайном: интерфейсным решением, балансом.
В качестве примера деконструкции возьмем экономическую систему одной очень популярной и простой игры для мобильных телефонов. Игровой цикл состоит всего из двух элементов: боя, где игрок зарабатывает деньги, и строительства деревни, на которое игрок тратит деньги. Построив одну деревню, игрок переходит к следующей, постройки в которой дороже, чем в предыдущей. В каждой из деревень пять построек, начальная цена каждой из них увеличивается от первой к пятой. Постройки также имеют по 4 уровня развития, каждый из которых дороже предыдущего.
Когда мы только начинаем игру, то видим первую деревню и первые уровни построек. Соответственно, нам нужно сохранить значения цен (очень важно не забывать об этом, иначе придется начинать все сначала) и немножко поиграть в боевую часть игры, чтобы собрать цены уровней всех построек первой деревни.
Разработчики игр очень редко используют какую-то сложную математику при создании баланса. И мы можем, по крайней мере, попробовать подойти к полученным нами цифрам наиболее простым образом: делением.
Таким образом мы получаем некие коэффициенты роста цены каждого уровня относительно предыдущего или относительно первого уровня. Естественно, нам нужно убедиться в том, что эти коэффициенты работают на всех постройках. Некрасивые, некруглые числа и разница в коэффициентах для разных построек легко объясняется тем, что разработчик оригинальной игры округляет цены до тысяч. При желании мы можем даже выявить формулу, по которой эти коэффициенты рассчитываются: например, (0,5 + 0,1 × (N – 1)) × N, где N – это номер уровня постройки, начиная со второго. Но исследования следующих деревень покажут, что коэффициенты не меняются ни от постройки к постройке, ни от деревни к деревне, а значит, их можно принять за константы.
Вывод, который мы можем сделать из этих расчетов, заключается в том, что цена каждого следующего уровня постройки так или иначе зависит от цены первого. Независимо от того, будем ли мы, например, считать цену четвертого уровня относительно третьего или относительно первого. Значит, нам необходимо понять, как формируется цена первого уровня постройки.
С ценой первых уровней каждой из построек можно поступить примерно так же: делением.
Исследования следующих деревень также покажут идентичный рост стоимости каждой из построек относительно первой. Мы сохраним коэффициенты и сделаем вывод о том, что цена первых уровней каждой из построек зависит от первого уровня первой постройки. А значит, нам необходимо построить несколько деревень, собирая информацию о цене первых уровней.
Эта цифра оказывается очень близка к корню игры – основе ее баланса и всей идеи, а значит, простого коэффициента там, скорее всего, не получится. Нам необходима формула роста. Придется потратить какое-то время, чтобы собрать всю необходимую информацию для ее выведения: цены первых уровней первых построек, например для первых десяти уровней: 60 000, 101 000, 180 000 и так далее.
Но какую роль на самом деле играет формула роста стоимости построек в игре? Дело в том, что кроме роста стоимости построек, конечно же, в игре есть рост наград, получаемых игроком в боевой части игры. Так как награды выдаются там случайным образом, выявить формулу роста наград в обозримое время невозможно: для этого нужно несколько десятков раз начать игру заново, собирая статистическую информацию о каждой битве. Формула же роста стоимости построек не предполагает никаких случайностей и позволяет нам опосредованно оценить и то, как растут награды. Но все же мы не можем знать всех подробностей устройства изучаемой нами игры, и полученные нами выводы остаются лишь предположением. Когда мы будем восстанавливать оригинальную математическую модель в своей игре, мы сможем проверить достоверность этого предположения на собственном опыте.
Опять же сам подход с исследованием других игр не означает, что мы обязаны использовать чужие наработки. Однако они могут значительно облегчить нам жизнь в процессе разработки игры, избавить от необходимости самому придумывать схему интерфейса и важные с точки зрения продукта механики. Мы можем уделить больше внимания какой-то механике, которая будет добавлять уникальности нашей игре, и прототипировать именно ее, оставив остальные, которые можно подсмотреть у других разработчиков. Например, оригинальная механика менеджера фабрики по переработке мусора, в то время как остальные механики игры копируют игру в жанре фермы для мобильных устройств.
В начале этапа прототипирования нам нужно составить документацию для основных механик игры, чтобы иметь возможность их проверить. Это фактически и является началом нашей работы над дизайн-документацией (диздоком) игры. В отличие от концепта, она является живым и меняющимся документом, может содержать описания механик, которые по тем или иным причинам не подошли нашей игре. Так что не надо бояться того, что мы, находясь на этапе экспериментов, начинаем заниматься диздоком.
Сама по себе работа над документацией игры в значительной степени похожа на те же деконструкции и декомпозиции других игр. Только в этот раз нам придется провести деконструкцию игры, которая пока существует только в нашей голове, что значительно усложняет задачу. Ведь у нас пока нет даже макета интерфейса, который мог бы подсказать, все механики мы описали или нет. Есть множество методик, помогающих в составлении документации, чтобы не забыть ничего важного: например, ментальные карты (mind map). Они позволяют представить буквально всю предстоящую работу в виде дерева логических связей или шаблоны уже готовых диздоков успешных проектов.
Деконструкция нашей игры должна быть максимально детальной, и она станет такой по мере декомпозиции отдельных механик с целью распределения задач между исполнителями. Но наполняться деталями документация должна по мере необходимости, особенно учитывая, что мы пока еще только приступаем к работе над прототипом.
И вот мы подобрались к началу непосредственной разработки игры, где наконец понадобится работа программиста. На третьем шаге этапа прототипирования у нас есть возможность и необходимость проверить выдвинутые нами в самом начале гипотезы: удается ли реализовать все главные механики игры и будут ли они интересными.
Конечно, далеко не все механики нужно проверять сейчас. Нам необходимо определить приоритеты: какие из них действительно важны, а какие второстепенны. Если игра является аркадой, шутером или гонкой, то управление – ее основная часть, и именно на этой механике нужно сосредоточиться. В игре еще останется место для второстепенных механик, но их отдельным изучением и прототипированием можно будет заняться позже, даже во время этапа производства игры, в более спокойной обстановке.
Этап прототипирования механик самостоятелен, и к нему можно обращаться в любой момент в процессе разработки игры. Например, если наша игра предназначена для мобильных устройств, то, скорее всего, мы вообще захотим выпустить ее в свет задолго до окончания работы над всеми задуманными механиками. В таком случае не надо спешить и тратить время на прототипирование всех возможных механик.
Также не стоит проверять механики, в которых мы уверены, например когда у нас уже есть опыт реализации этих элементов. То есть процесс проверки предназначен для действительно оригинальных вещей, которые либо нигде раньше не встречались и нет возможности удостовериться в их интересности на чужом опыте, либо мы еще не знаем, как именно их реализовывать.
«Бумажный прототип» – это метод разработки механик, программного обеспечения, гейм-дизайна, когда на бумаге создаются наброски от руки. Отсюда и название. Это может быть также настольная игра. Бумажный прототип позволяет проверить гипотезы и идеи реализации продукта, не прибегая к дорогим методам разработки на первоначальном этапе.