от монетизации pay-to-win[69], в большинстве своем игроки нормально относятся к сложной игровой экономике, если она не подразумевает много гринда. Такие игры могут отпугивать казуальных игроков, но в целом воспринимаются хорошо.

Бывает, что разработчики пытаются предугадать все действия игрока. Это почти невозможно, и строить на таких предположениях баланс – плохая идея. Эффективнее сосредоточиться на ограничениях, так вы будете уверены, чего пользователь хотя бы точно делать не будет. Яркий пример ограничений можно увидеть в батлерах. Часто их разработчики никак не ограничивают активности игрока, но отлично просчитывают, как далеко может зайти игрок каждый день. Эта механика хорошо реализована в AFK Arena.

Каждый день игрок может проходить сколько угодно уровней башни, продвигаться по миссиям так далеко, как только сможет. Может сражаться на арене, покупать героев – делать практически что угодно. Хотя есть и жестко ограниченные части геймплея, такие как мистический лабиринт – три уровня путешествия, где герои не восстанавливают здоровье после битвы. Пройдя его полностью, ждите два дня до обновления. В большинство остальных активностей можно играть бесконечно. И в начале игры кажется, что так оно и будет. Но вот герои оказываются уже недостаточно сильны для прохождения следующих уровней, а на прокачку ресурсов не хватает, и нужно ждать следующей ежедневной награды. И дейли-квесты засчитываются лишь за первое прохождение той или иной активности в день. Все остальные уже не принесут дополнительных наград. И вроде бы получается, играй сколько хочешь, но на практике игра оставляет лишь 10–15 минут геймплея в день. Такие ограничения позволяют разработчикам подключать монетизационные механизмы.

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

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

Производство контента

КОНФИГУРИРОВАНИЕ КОНТЕНТА

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

К счастью, навыки программирования для этого не потребуются. Более того, создание контента программистами считается плохой практикой и называется «хардкодом». Под этим словом мы понимаем ситуацию, когда программист добавляет динамические элементы в код: цифры, объекты, описания и т. д. Во многих случаях в коде допустимо хранить формулы, но продвинутые гейм-дизайнеры производят все расчеты в Excel и отдают уже посчитанные табличные данные. Разумеется, если это допустимо в конкретной игре. Очень удобно посчитать в Excel характеристики всех построек экономической стратегии, но довольно трудно убрать из кода формулы работы заклинаний в MMORPG. Хотя стоит отметить, что это вполне возможно и в идеальной ситуации так и нужно сделать. И, скорее всего, невозможно отказаться от формул при расчете динамики в таких играх, как, например, Overwatch.

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

Рис. 20. Визуальный пример XML конфига

Если в игре лучница должна пройти игровой уровень размером в 1 экран телефона (допустим, поле 12*20 условных клеточек), преодолевая препятствия и убивая врагов, в конфиге этого уровня будет написано примерно следующее: на клеточке [2;2] и [5;6] стоят объекты номер 4 (кубики), на [7;8] – забор (тоже объект с присвоенным ему номером или названием). Игра прочитает эти координаты и воспроизведет препятствия, информацию о которых сможет найти по ссылке на файл «level_1». На этапе загрузки она также «подтянет» файл со списком всех объектов уровня (а может, и всех уровней вообще), где указано, что, например, камень – это препятствие, размером 1×1, «непроходимый», ссылка на изображение такая-то… Для каждой сущности нужно создать такое простое описание. Для мобов указать важные параметры: сколько у него здоровья, количество урона, тип атаки, как он выглядит, с какого расстояния атакует и т. д.

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

В зависимости от средств производства и хранения контента можно пользоваться разными техническими инструментами. Мы приведем наиболее распространенные.

XML

Одним из самых простых и популярных инструментов для описания неких структур считается XML (от англ. eXtensible Markup Language). Как мы уже говорили, это язык разметки, то есть, в отличие от кода (языка программирования), мы не отдаем с его помощью никаких команд. Он близок к HTML[70], который используют для создания веб-сайтов и интерфейсов: там тоже нет инструкций как таковых; HTML – описательный язык, позволяющий рассказать, как внешне должен выглядеть сайт.

Давайте рассмотрим пример. В нашей «Очень счастливой ферме» есть 100 видов ресурсов, 40 различных животных, 75 строений и т. д. Все эти игровые сущности имеют собственные параметры, собираемые из разных компонентов, и должны как-то конфигурироваться и храниться. У нас есть здание «Загон для барашка». Оно обладает параметрами: размер, доступные животные, визуальный арт и т. д. Для его постройки необходимо 2 железа, 100 монет и 3 дерева. Для дальнейшего улучшения – еще какие-то ресурсы. Мы можем описать это в виде списка с соответствиями: уровень здания –