Создаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

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

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

* * *

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

* * *

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