Для работы над нашими играми мы широко используем программных ботов, наделенных тем или иным интеллектом. Боты помогают нам разрабатывать, тестировать и эксплуатировать наши игры. Я хочу рассказать про несколько примеров такого симбиоза с автоматикой.
Вот так выглядит Ам Ням в игре Cut the Rope 2
Код мобильных игр часто и значительно меняется, чтобы успевать за полетом мысли дизайнеров и художников. Многообразие игровых ситуаций, которые возникают в игре, делает сложным быстрое и надежное проведение сценариев тестирования вручную. Бывает, нужно проверить, что происходит после возникновения редкого случайного события или наложения нескольких факторов. Например, в игре Cut the Rope 2 дизайнер может поменять массу Ам Няма для того, чтобы он слабее реагировал на воздействия других объектов. Это решит проблему дизайнера на уровне, с которым он работает, но возросшая масса может привести к невозможности пройти другой уровень, где Ам Няма как раз нужно было столкнуть с опоры.
Для проверки того, что прохождение не поломалось, мы используем специального бота, который по порядку быстро проходит все уровни ровно так же, как это делал дизайнер при их создании. Он запоминает все касания экрана и происходящие в игре события (такие, как разрезание веревки, нажатие кнопки или съедание конфеты) в специальный журнал. А когда мы запускаем проверку прохождения, он читает этот журнал и эмулирует те же самые касания экрана. Попутно он следит за тем, чтобы все важные игровые события произошли, и в целом уровень проходился. Если изменение параметров игры привело к тому, что уровень теперь непроходим по тем же шагам, дизайнерам приходится уточнять изменения. Либо заново пройти уровень уже по новым правилам, показав боту, как это делается.
Очевидно, что перепроходить уровни в Cut the Rope 2 дизайнеру приходится, когда он меняет существенные параметры игры, это долгое и дорогое занятие. Некоторые уровни весьма сложны, и даже их создателям приходится делать много попыток, чтобы в правильный момент и в правильном месте разрезать нужные веревки. Поэтому фундаментальные константы игры, такие как гравитационная постоянная и масса Ам Няма активно меняются только на ранней стадии разработки. Большую часть времени дизайнеры отлаживают локальные вещи: геометрию конкретных уровней или параметры новых игровых элементов.
Дизайнер в этом процессе как бы доказывает боту, что созданный им уровень действительно можно пройти. А затем бот много раз в ходе тестирования пытается это повторить. Забавно то, что схожий принцип положен в основу нашей другой нашей игры King of Thieves. В ней уже не дизайнер, а каждый игрок создает свой уровень (подземелье с сокровищами и ловушками) и доказывает аналогичному боту, что этот уровень можно пройти. Затем этот уровень попадает на растерзание другим игрокам. Они пытаются пройти его, затратив на это как можно меньше попыток. Обойти все ловушки в хорошо сделанном уровне чрезвычайно сложно. Поэтому игроки могут попросить бота показать, как проходил уровень его создатель. Так они убеждаются, что уровень действительно проходим. Проверки уровня самой игрой на мобильном устройстве бывает недостаточно. У нас есть настолько красноречивые игроки с соответствующим софтом, что они могут убедить сервер в том, что прошли заведомо непроходимый уровень. Поэтому мы также используем для проверки проходимости специальных серверных ботов, которые перепроверяют уровни и их прохождения уже в отрыве от устройств, на серверах.
Игрок пытается выкрасть сокровище из подземелья с ловушками в игре King of Thieves
Физические пазлы, такие, как Cut the Rope 2, основаны на том, чтобы прохождение их уровней было неочевидно человеку. Создать бота, который умел бы проходить произвольные уровни, сложно. С другой стороны, есть игры с более простой механикой, для которых легко сформулировать оптимальную или близкую к ней стратегию. Например, в популярной Heroes Charge достаточно близка к оптимальной стратегия использовать специальные способности сразу же, как только на них накопилась энергия. В остальном бой автоматизирован, игрок может лишь активировать способности или ждать удачного момента для их применения. Эту стратегию и использует бот, которые играет за противников или представляет интересы игрока на арене. Другой пример — знаменитая Flappy Bird, для которой разработаны алгоритмы прохождения и даже механические роботы, которые играют в нее намного успешнее людей.
Есть автоматизируемые игры и у нас в Зептолабе. В них мы максимально широко используем ботов, которые играют в уровни и воспроизводят разнообразные игровые ситуации с большой эффективностью. Это применяется для выработки и тестирования игрового баланса. Дизайнеру, например, бывает нужно построить функцию вероятности прохождения уровня от набора входных параметров (структура уровня, степень развития и характеристики противников, степень развития игрока). У функции десятки переменных, и нужно выделить из них существенные и построить относительно простую функцию от них. А если она не нравится дизайнеру, то изменить правила поведения игры, и построить функцию заново. Нам помогают это делать боты. Мы запускаем ботов играть в определенный набор входных параметров несколько сотен раз (количество игр определяется количеством значимых параметров и устраивающим нас доверительным интервалом). Так мы получаем вероятность победы в одной точке пространства параметров. Проделав это для достаточного количества точек, мы получаем данные для построения функции общего вида. И уже она используется для формирования кривой сложности игры и предсказания того, как игра будет ощущаться игроком в тот или иной момент.
Здесь стоит упомянуть, что есть два существенно разных подхода к такому моделированию игры. Можно отвязать отрисовку от игровой логики, и моделировать игру с огромной скоростью, не будучи никак привязанными к мощности мобильных процессоров и возможностями их графики. С другой стороны, можно моделировать игру на самом мобильном устройств существующим игровым кодом, который работает, когда играет человек. Этот код, помимо логики, рисует всю красоту, играет звуки, взаимодействует с сетью, собирает аналитику. За счет этого он достаточно медленный, и его можно заставить работать быстрее только ускорив виртуальное время, в котором живет приложение (отрисовка не может работать чаще, чем 60 раз в секунду). В данный момент мы склоняемся ко второму варианту, поскольку его дешевле реализовывать, и попутно достигается экстремальное тестирование игры на наличие редких ошибок и утечек памяти. А скорости как раз хватает, чтобы дизайнер получал новые данные с достаточной скоростью.
В некоторых играх решающую роль играет то, как игрок распоряжается своими ресурсами в течение длительного времени. В них мы стараемся дополнять чисто игровых ботов мета-игровыми ботами, которые распоряжаются ресурсами по неким разумным правилам. Это позволяет дизайнерам задавать параметры экономики и сложности игры, а затем наблюдать, как боты на большой скорости проходят игру, экономя десятки часов на каждую итерацию и позволяя попробовать много вариантов. Как правило, это выглядит, как несколько подключенных к компьютеру планшетов, на которых игра “сама в себя играет” на очень большой скорости. Дизайнер следит за ними визуально и параллельно читает логи с интересующими его игровыми событиями и параметрами.
Пока что наши игры с широким использованием ботов стесняются быть упомянутыми на Хабре, поэтому я их не называю. А если вам интересна мобильная разработка и такие задачи, то приходите помогать нам сделать их более известными и менее стеснительными. Тестовым заданием для программистов сейчас является написание клона вышеупомянутой Flappy Bird.
Вот так выглядит Ам Ням в игре Cut the Rope 2
Код мобильных игр часто и значительно меняется, чтобы успевать за полетом мысли дизайнеров и художников. Многообразие игровых ситуаций, которые возникают в игре, делает сложным быстрое и надежное проведение сценариев тестирования вручную. Бывает, нужно проверить, что происходит после возникновения редкого случайного события или наложения нескольких факторов. Например, в игре Cut the Rope 2 дизайнер может поменять массу Ам Няма для того, чтобы он слабее реагировал на воздействия других объектов. Это решит проблему дизайнера на уровне, с которым он работает, но возросшая масса может привести к невозможности пройти другой уровень, где Ам Няма как раз нужно было столкнуть с опоры.
Для проверки того, что прохождение не поломалось, мы используем специального бота, который по порядку быстро проходит все уровни ровно так же, как это делал дизайнер при их создании. Он запоминает все касания экрана и происходящие в игре события (такие, как разрезание веревки, нажатие кнопки или съедание конфеты) в специальный журнал. А когда мы запускаем проверку прохождения, он читает этот журнал и эмулирует те же самые касания экрана. Попутно он следит за тем, чтобы все важные игровые события произошли, и в целом уровень проходился. Если изменение параметров игры привело к тому, что уровень теперь непроходим по тем же шагам, дизайнерам приходится уточнять изменения. Либо заново пройти уровень уже по новым правилам, показав боту, как это делается.
Очевидно, что перепроходить уровни в Cut the Rope 2 дизайнеру приходится, когда он меняет существенные параметры игры, это долгое и дорогое занятие. Некоторые уровни весьма сложны, и даже их создателям приходится делать много попыток, чтобы в правильный момент и в правильном месте разрезать нужные веревки. Поэтому фундаментальные константы игры, такие как гравитационная постоянная и масса Ам Няма активно меняются только на ранней стадии разработки. Большую часть времени дизайнеры отлаживают локальные вещи: геометрию конкретных уровней или параметры новых игровых элементов.
Дизайнер в этом процессе как бы доказывает боту, что созданный им уровень действительно можно пройти. А затем бот много раз в ходе тестирования пытается это повторить. Забавно то, что схожий принцип положен в основу нашей другой нашей игры King of Thieves. В ней уже не дизайнер, а каждый игрок создает свой уровень (подземелье с сокровищами и ловушками) и доказывает аналогичному боту, что этот уровень можно пройти. Затем этот уровень попадает на растерзание другим игрокам. Они пытаются пройти его, затратив на это как можно меньше попыток. Обойти все ловушки в хорошо сделанном уровне чрезвычайно сложно. Поэтому игроки могут попросить бота показать, как проходил уровень его создатель. Так они убеждаются, что уровень действительно проходим. Проверки уровня самой игрой на мобильном устройстве бывает недостаточно. У нас есть настолько красноречивые игроки с соответствующим софтом, что они могут убедить сервер в том, что прошли заведомо непроходимый уровень. Поэтому мы также используем для проверки проходимости специальных серверных ботов, которые перепроверяют уровни и их прохождения уже в отрыве от устройств, на серверах.
Игрок пытается выкрасть сокровище из подземелья с ловушками в игре King of Thieves
Физические пазлы, такие, как Cut the Rope 2, основаны на том, чтобы прохождение их уровней было неочевидно человеку. Создать бота, который умел бы проходить произвольные уровни, сложно. С другой стороны, есть игры с более простой механикой, для которых легко сформулировать оптимальную или близкую к ней стратегию. Например, в популярной Heroes Charge достаточно близка к оптимальной стратегия использовать специальные способности сразу же, как только на них накопилась энергия. В остальном бой автоматизирован, игрок может лишь активировать способности или ждать удачного момента для их применения. Эту стратегию и использует бот, которые играет за противников или представляет интересы игрока на арене. Другой пример — знаменитая Flappy Bird, для которой разработаны алгоритмы прохождения и даже механические роботы, которые играют в нее намного успешнее людей.
Есть автоматизируемые игры и у нас в Зептолабе. В них мы максимально широко используем ботов, которые играют в уровни и воспроизводят разнообразные игровые ситуации с большой эффективностью. Это применяется для выработки и тестирования игрового баланса. Дизайнеру, например, бывает нужно построить функцию вероятности прохождения уровня от набора входных параметров (структура уровня, степень развития и характеристики противников, степень развития игрока). У функции десятки переменных, и нужно выделить из них существенные и построить относительно простую функцию от них. А если она не нравится дизайнеру, то изменить правила поведения игры, и построить функцию заново. Нам помогают это делать боты. Мы запускаем ботов играть в определенный набор входных параметров несколько сотен раз (количество игр определяется количеством значимых параметров и устраивающим нас доверительным интервалом). Так мы получаем вероятность победы в одной точке пространства параметров. Проделав это для достаточного количества точек, мы получаем данные для построения функции общего вида. И уже она используется для формирования кривой сложности игры и предсказания того, как игра будет ощущаться игроком в тот или иной момент.
Здесь стоит упомянуть, что есть два существенно разных подхода к такому моделированию игры. Можно отвязать отрисовку от игровой логики, и моделировать игру с огромной скоростью, не будучи никак привязанными к мощности мобильных процессоров и возможностями их графики. С другой стороны, можно моделировать игру на самом мобильном устройств существующим игровым кодом, который работает, когда играет человек. Этот код, помимо логики, рисует всю красоту, играет звуки, взаимодействует с сетью, собирает аналитику. За счет этого он достаточно медленный, и его можно заставить работать быстрее только ускорив виртуальное время, в котором живет приложение (отрисовка не может работать чаще, чем 60 раз в секунду). В данный момент мы склоняемся ко второму варианту, поскольку его дешевле реализовывать, и попутно достигается экстремальное тестирование игры на наличие редких ошибок и утечек памяти. А скорости как раз хватает, чтобы дизайнер получал новые данные с достаточной скоростью.
В некоторых играх решающую роль играет то, как игрок распоряжается своими ресурсами в течение длительного времени. В них мы стараемся дополнять чисто игровых ботов мета-игровыми ботами, которые распоряжаются ресурсами по неким разумным правилам. Это позволяет дизайнерам задавать параметры экономики и сложности игры, а затем наблюдать, как боты на большой скорости проходят игру, экономя десятки часов на каждую итерацию и позволяя попробовать много вариантов. Как правило, это выглядит, как несколько подключенных к компьютеру планшетов, на которых игра “сама в себя играет” на очень большой скорости. Дизайнер следит за ними визуально и параллельно читает логи с интересующими его игровыми событиями и параметрами.
Пока что наши игры с широким использованием ботов стесняются быть упомянутыми на Хабре, поэтому я их не называю. А если вам интересна мобильная разработка и такие задачи, то приходите помогать нам сделать их более известными и менее стеснительными. Тестовым заданием для программистов сейчас является написание клона вышеупомянутой Flappy Bird.