Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 28)

Каждый день игрок может проходить сколько угодно уровней башни, продвигаться по миссиям так далеко, как только сможет. Может сражаться на арене, покупать героев – делать практически что угодно. Хотя есть и жестко ограниченные части геймплея, такие как мистический лабиринт – три уровня путешествия, где герои не восстанавливают здоровье после битвы. Пройдя его полностью, ждите два дня до обновления. В большинство остальных активностей можно играть бесконечно. И в начале игры кажется, что так оно и будет. Но вот герои оказываются уже недостаточно сильны для прохождения следующих уровней, а на прокачку ресурсов не хватает, и нужно ждать следующей ежедневной награды. И дейли-квесты засчитываются лишь за первое прохождение той или иной активности в день. Все остальные уже не принесут дополнительных наград. И вроде бы получается, играй сколько хочешь, но на практике игра оставляет лишь 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 (от англ. eXtensible Markup Language). Как мы уже говорили, это язык разметки, то есть, в отличие от кода (языка программирования), мы не отдаем с его помощью никаких команд. Он близок к HTML[70], который используют для создания веб-сайтов и интерфейсов: там тоже нет инструкций как таковых; HTML – описательный язык, позволяющий рассказать, как внешне должен выглядеть сайт.

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

<building name=”zagon_baran”>

     <size width=”2” height=”3”/>

     <upgrade level =”1”>

          <resource type=”iron”>2</resource>

          <resource type=”lumber”>3</resource>

     <money>100</money>

     </upgrade>

</building>

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

Рис. 21. Фрагмент XML-кода, описывающего содержимое лутбокса браузерной игры

XML несложен в написании. Есть специальные программы, например, Notepad++ или Jetbrains WebStorm, позволяющие сделать данные нагляднее, используя отступы, разные цвета и т. д. Можно создавать файлы в редакторах и отдавать в игровой движок, а можно писать сразу в редакторе, который вы используете для работы с Unity (к примеру, MonoDevelop).

Базы данных позволяют создавать не просто текстовые файлы. В отличие от XML, это уже особым образом структурированные данные, работа с которыми происходит через движок базы данных (БД), позволяющий к этим данным обращаться. У каждого движка свой язык, на котором он принимает команды. Самый популярный тип баз данных в игровой индустрии – SQL (от англ. Structured Query Language – «язык структурированных запросов»).

База данных – это набор взаимосвязанных таблиц. В визуальном редакторе создаются таблицы, куда вносятся данные. В SQL это строка с заголовками, значениями и т. д.

Бывают разные вариации этого языка, используемые разными движками СУБД (MySQL, PostgreSQL, MsSQL, SQLite и другие), но логика одна и та же. Основные команды для работы с БД можно пересчитать по пальцам:

SELECT – выгрузить из базы нужные данные;

INSERT – вставить в базу новую запись;

REPLACE – заменить имеющуюся запись;

DELETE – удалить вхождения данных из базы.

Конечно, в работе вы столкнетесь с гораздо большим набором команд для транзакций[71], но при помощи этих можно закрыть 90 % простых задач. Для более сложных запросов – к примеру, хранимых процедур – потребуется либо более глубоко изучить SQL, либо обратиться к вашему аналитику, если такой есть в команде. Аналитик обязательно знает множество команд и нюансов работы с БД.

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

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