Текст книги "Хочу в геймдев! Основы игровой разработки для начинающих"

Игровая экономика

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

Как быстро игрок получает награду в рейде – пример неденежной экономики, которую задает сам разработчик; скидку на «Набор новичка» во время акции обычно определяет уже тот, кто занимается оперированием готового проекта. Мы сосредоточимся на первом варианте, где цель игровой экономики – развлекать игрока, а не монетизировать его. Хотя нередко эти вещи тесно переплетены, особенно во free-to-play играх.

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

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

Если рассматривать ЗАКРЫТУЮ ЭКОНОМИКУ, в теории все относительно просто: ваша задача – уравнять общую сумму всех входящих ресурсов и общую сумму их расхода. Игрок может получить ресурсы за активные действия (например, убийство моба) или пассивно (рудник дает в день 2 руды).

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

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

ОТКРЫТАЯ ЭКОНОМИКА подразумевает возможность обмена ресурсами между игроками. Отсюда следует главная ее проблема: появляются слишком бедные и слишком богатые игроки, а ваша задача как разработчика – по возможности уравнять их, чтобы люди испытывали более или менее одинаковый дефицит ресурсов.

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

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

Отдельный инструмент открытой экономики – аукцион. Если игроки могут влиять на стоимость ресурсов, они сами балансируют экономику, выставляя адекватные, на их взгляд, цены.

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

ЭКОНОМИКА ПО ПРОГРЕССИИ нужна для любой игры, где персонаж проходит игровой путь, двигаясь по какой-то шкале. Для одиночных игр необходимо рассчитать, как персонаж будет получать деньги, очки опыта и пр. Даже для головоломок – игр, казалось бы, совсем не про экономику – нужно продумать, как часто и при каких условиях игрок будет получать подсказки.

ЭКОНОМИКА ДЛЯ МОНЕТИЗАЦИИ ИГРОКОВ составляется таким образом, чтобы стимулировать игроков платить. Одна из основных задач, особенно для f2p игр, – расчет ARPPU (от англ. average revenue per paying user – «средняя выручка с одного платящего пользователя»), то есть какой доход с игрока должна иметь наша игра, чтобы быть успешной. Исходя из этого и считаются все остальные цифры; подгоняем ли мы экономику через дефицит ресурсов или через возможность экономии времени – вопрос второго плана.

ЭКОНОМИКА В КОНТЕКСТЕ ВЗАИМОДЕЙСТВИЯ ИГРОКОВ – это комплексная вещь. Сюда относятся баланс открытой экономики, логика обмена ресурсами между игроками, аукционы и т. д.

ИГРОВАЯ ЭКОНОМИКА КАК ОСНОВА ГЕЙМПЛЕЯ встречается прежде всего во всевозможных градостроительных симуляторах. В рогаликах[66]66
  . Рогалики (от англ. roguelike) – жанр компьютерных игр, поджанр компьютерных ролевых игр. Характерными особенностями классического roguelike являются генерируемые случайным образом уровни, пошаговость и необратимость смерти персонажа.


[Закрыть] и симуляторах выживания острый дефицит ресурсов тоже определяет игровой процесс, влияя на решения и опыт, а также позволяя ощутить неприветливость игрового мира.

Чаще всего гейм-дизайнеру предстоит описать четыре состояния экономики: старт, основной геймплей, хай-энд и монетизация. НА СТАРТЕ игрок только помещен в игровой мир, и необходимо определить, какие ресурсы и возможности у него есть в самом начале пути, чтобы он мог плавно втянуться в игровой процесс. Если это survival, он сразу ощущает нехватку ресурсов; экономика MMORPG, напротив, чаще никак не ограничивает игрока, позволяя ему в свое удовольствие проходить квесты и знакомиться с игровым миром.

Если в вашей игре экономика является важным элементом ОСНОВНОГО ГЕЙМПЛЕЯ, необходимо составить дизайн для каждой шкалы: прогрессия опыта, внутриигровых денег, строительства и т. п. Есть элементы, характерные для конкретного жанра (например, экономических стратегий), им следует уделить особое внимание при проектировании геймплея.

ХАЙ-ЭНД – это этап, когда у игрока уже завершен базовый путь прохождения, который вы заложили. Скажем, в том же survival игрок уже прокачался, построил себе крепкий дом, завел животных, обеспечив пропитание и пр.; или в MMORPG – все возможные боссы побеждены, все желаемые доспехи собраны, а значит, внутриигровые деньги больше не нужны. Хотя в онлайн-играх фаза насыщения обычно сильно отложена из-за долгой прогрессии, связанной с действиями других игроков, необходимо продумать, что же будет удерживать игрока на данном этапе. Если вовремя этого не сделать, то экономика просто схлопывается (пропадают цели и желание играть дальше); при закрытой экономике – валюта обесценивается для одного игрока либо же вообще для всего сервера.

МОНЕТИЗАЦИЯ часто связывает все эти части. Если у игрока ничего не забирать, скоро ему хватит ресурсов на все, и игра потеряет смысл. Если есть проблемы с монетизацией, игра лишится смысла куда быстрее: игроки просто не дойдут до поздних стадий. Для многих MMORPG во время прокачки игроку почти не нужно донатить[67]67
  . Донат (от англ. donate – «жертвовать», «дарить») – в играх обычно обозначает оплату игроком реальными деньгами каких-либо дополнительных бонусов, уникальных предметов и прочих благ.


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

КАК СЧИТАТЬ ИГРОВУЮ ЭКОНОМИКУ

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

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

Рис. 19. Расчет экономики

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

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

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

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

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

В итоге есть два противоположных подхода к своим игрокам: или «игрок должен страдать», или «мы стараемся потакать игроку во всем». Для ПК-игр в большинстве своем верен первый подход, а вот мобильные казуальные игры, яростно сражающиеся за удержание аудитории, пытаются всячески игрокам угождать и не напрягать их. Хотя во free-to-play играх довольно часто встречаются paywall[68]68
  . Paywall – система, при которой часть контента в игре доступна лишь за определенную плату.


[Закрыть] или энергия (необходимость заплатить, чтобы поиграть еще прямо сейчас, а не ждать). Конечно, это верно не всегда: есть и мобильные игры с жесткой экономикой, и суперлояльные игры на ПК.

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


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

Бывает, что разработчики пытаются предугадать все действия игрока. Это почти невозможно, и строить на таких предположениях баланс – плохая идея. Эффективнее сосредоточиться на ограничениях, так вы будете уверены, чего пользователь хотя бы точно делать не будет. Яркий пример ограничений можно увидеть в батлерах. Часто их разработчики никак не ограничивают активности игрока, но отлично просчитывают, как далеко может зайти игрок каждый день. Эта механика хорошо реализована в 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]70
  . HTML (от англ. HyperText Markup Language – «язык гипертекстовой разметки») – стандартизированный язык разметки документов в Интернете. Большинство веб-страниц содержат описание на этом языке.


[Закрыть], который используют для создания веб-сайтов и интерфейсов: там тоже нет инструкций как таковых; 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).

БАЗЫ ДАННЫХ И SQL

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

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

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

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

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

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

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

Конечно, в работе вы столкнетесь с гораздо большим набором команд для транзакций[71]71
  . Транзакции в СУБД – атомарные действия над БД, переводящие ее из одного целостного состояния в другое целостное состояние. Другими словами, транзакция – это последовательность операций, которые должны быть или все выполнены, или все не выполнены (все или ничего).


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

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

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

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

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

Базы данных заточены под быструю передачу информации, XML – под удобство описания. Существуют и другие языки, кроме SQL и XML: JavaScript, ActionScript; в Unreal Engine для описания сценариев используют блупринты. Выбор инструментов весьма широкий и зачастую определяется особенностями игрового проекта и личными предпочтениями.

АВТОМАТИЗАЦИЯ РАБОТЫ

Итак, описание XML кода и структуру базы обычно делают программисты или (в крупных студиях) архитекторы баз данных на основе документов от гейм-дизайнера. После того как вся экономика посчитана, для чего чаще всего используется Excel, гейм-дизайнеру предстоит внести в игру получившиеся значения.

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

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

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

На скриншоте приведен пример данных из экономической стратегии. Это пример скрипта на языке VBA, который не только проводит расчеты, заполняя недостающие ячейки в Excel, но и создает SQL, XML или JSON код для экспорта в игру. Простой VBA-скрипт (упрощенная реализация языка программирования Visual Basic) пробегается по этому списку и генерирует текст SQL-скрипта, который можно просто скопировать в SQL-редактор и выполнить. Он сам перепишет нужную часть информации в соответствии с тем, что вы прописали в Excel.

Рис. 22. Пример данных из экономической стратегии

Для многих ГД освоение встроенного языка VBA является относительно трудоемкой задачей. Мы рекомендуем однажды найти в себе силы и изучить его, навсегда упростив себе жизнь. Однако, если вам этого категорически не хочется, Excel позволяет решать подобные задачи и более простым путем, например через обычные формулы:

=”INSERT into `buildings` (” & B1 & ”, ” & B2 & ”);”

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