Автоматизація розробки в ZeptoLab

Для роботи над нашими іграми ми широко використовуємо програмних роботів, наділених тим чи іншим інтелектом. Боти допомагають нам розробляти, тестувати і експлуатувати наші ігри. Я хочу розповісти про декілька прикладів такого симбіозу з автоматикою.

image
Ось так виглядає Ам Ням у грі Cut the Rope 2

Код мобільних ігор часто і значно змінюється, щоб встигати за польотом думки дизайнерів і художників. Різноманіття ігрових ситуацій, які виникають у грі, робить складним швидке і надійне проведення сценаріїв тестування вручну. Буває, потрібно перевірити, що відбувається після виникнення рідкісного випадкової події або накладення декількох факторів. Наприклад, у грі Cut the Rope 2 дизайнер може поміняти масу Ам Няма для того, щоб він слабший реагував на дії інших об'єктів. Це вирішить проблему дизайнера на рівні, з яким він працює, але збільшена маса може призвести до неможливості пройти інший рівень, де Ам Няма якраз потрібно було зіштовхнути з опори.

Для перевірки того, що проходження не поламалося, ми використовуємо спеціального бота, який по черзі швидко проходить всі рівні рівно так само, як це робив дизайнер при їх створенні. Він запам'ятовує всі торкання екрана і відбуваються в грі події (такі, як розрізування мотузки, натискання кнопки або з'їдання цукерки) у спеціальний журнал. А коли ми запускаємо перевірку проходження, він читає цей журнал і емулює ті ж самі торкання екрана. Попутно він стежить за тим, щоб всі важливі ігрові події відбулися, і в цілому рівень проходився. Якщо зміна параметрів гри призвело до того, що тепер рівень непрохідний за тим же кроків, дизайнерам доводиться уточнювати зміни. Або заново пройти рівень вже за новими правилами, показавши боту, як це робиться.

Очевидно, що перепроходити рівні у Cut the Rope 2 дизайнерові доводиться, коли він змінює істотні параметри гри, це довгий і дороге заняття. Деякі рівні досить складні, і навіть їх творцям доводиться робити багато спроб, щоб у правильний час і в правильному місці розрізати потрібні мотузки. Тому фундаментальні константи ігри, такі як гравітаційна постійна і маса Ам Няма активно змінюються тільки на ранній стадії розробки. Велику частину часу дизайнери налагоджують локальні речі: геометрію конкретних рівнів або параметри нових ігрових елементів.

Дизайнер в цьому процесі як би доводить боту, що створений ним рівень дійсно можна пройти. А потім бот багато разів в ході тестування намагається це повторити. Цікаво, що схожий принцип покладений в основу нашої інший нашої гри King of Thieves. В ній вже не дизайнер, а кожен гравець створює свій рівень (підземелля з скарбами і пастками) і доводить аналогічного боту, що цей рівень можна пройти. Потім цей рівень потрапляє на поталу іншим гравцям. Вони намагаються пройти його, витративши на це якомога менше спроб. Обійти всі пастки в добре зробленому рівні надзвичайно складно. Тому гравці можуть попросити бота показати, як проходив рівень його творець. Так вони переконуються, що рівень дійсно проходимо. Перевірки рівня самою грою на мобільному пристрої буває недостатньо. У нас є настільки красномовні гравці з відповідним софтом, що вони можуть переконати сервер в тому, що пройшли завідомо непрохідний рівень. Тому ми також використовуємо для перевірки прохідності спеціальних серверних ботів, які перевіряють рівні і їх проходження вже у відриві від пристроїв, на серверах.

image
Гравець намагається викрасти скарб з підземелля з пастками в грі King of Thieves

Фізичні пазли, такі, як Cut the Rope 2, засновані на тому, щоб проходження їх рівнів було неочевидно людині. Створити бота, який умів би проходити випадкові рівні, складно. З іншого боку, є ігри з більш простий механікою, для яких легко сформулювати оптимальну або близьку до неї стратегію. Наприклад, у популярній Heroes Charge досить близька до оптимальної стратегія використовувати спеціальні здібності відразу ж, як тільки на них накопичилася енергія. В іншому бій автоматизований, гравець може лише активувати здатності або чекати вдалого моменту для їх застосування. Цю стратегію і використовує бот, які грає за супротивників або представляє інтереси гравця на арені. Інший приклад — знаменита Flappy Bird, для якої розроблені алгоритми проходження і навіть механічні роботи, які грають в неї набагато успішніше людей.

Є автоматизируемые гри і у нас в Зептолабе. В них ми максимально широко використовуємо ботів, які грають в рівні і відтворюють різноманітні ігрові ситуації з великою ефективністю. Це застосовується для вироблення і тестування ігрового балансу. Дизайнеру, наприклад, буває потрібно побудувати функцію ймовірності проходження рівня від набору вхідних параметрів (рівня структура, ступінь розвитку і характеристики супротивників, ступінь розвитку гравця). У функції десятки змінних, і потрібно виділити з них істотні і побудувати відносно просту функцію від них. А якщо вона не подобається дизайнерові, то змінити правила поведінки ігри, і побудувати функцію заново. Нам допомагають це робити боти. Ми запускаємо ботів грати в певний набір вхідних параметрів кілька сотень разів (кількість ігор визначається кількістю значущих параметрів і влаштовує нас довірчим інтервалом). Так ми отримуємо ймовірність перемоги в одній точці простору параметрів. Проробивши це для достатньої кількості точок, ми отримуємо дані для побудови функції загального виду. І вже вона використовується для формування кривий складності гри і передбачення того, як гра буде відчуватися гравцем в той чи інший момент.

Тут варто згадати, що є дві істотно різні підходи до такого моделювання гри. Можна відв'язати малювання від ігрової логіки, і моделювати гру з величезною швидкістю, не будучи ніяк прив'язаними до потужності мобільних процесорів і можливостями їх графіки. З іншого боку, можна моделювати гру на самому мобільному пристроїв існуючим ігровим кодом, який працює, коли грає людина. Цей код, крім логіки, малює всю красу, грає звуки, що взаємодіє з мережею, збирає аналітику. За рахунок цього він досить повільний, і його можна змусити працювати швидше тільки прискоривши віртуальне час, в якому живе додаток (відтворення не може працювати частіше, ніж 60 разів у секунду). В даний момент ми схиляємося до другого варіанту, оскільки його реалізовувати дешевше, і попутно досягається екстремальне тестування гри на наявність окремих помилок і витоків пам'яті. А швидкості якраз вистачає, щоб дизайнер отримував нові дані з достатньою швидкістю.

У деяких іграх вирішальну роль грає те, як гравець розпоряджається своїми ресурсами протягом тривалого часу. В них ми намагаємося доповнювати чисто ігрових ботів мета-ігровими ботами, які розпоряджаються ресурсами за якимось розумним правилами. Це дозволяє дизайнерам задавати параметри економіки та складності гри, а потім спостерігати, як боти на великій швидкості проходять гру, економлячи десятки годин на кожну ітерацію і дозволяючи спробувати багато варіантів. Як правило, це виглядає, як кілька підключених до комп'ютера планшетів, на яких гра «сама в себе грає» на дуже великій швидкості. Дизайнер стежить за ними візуально і паралельно читає логи з цікавлять його ігровими подіями і параметрами.

Поки що наші ігри з широким використанням ботів соромляться бути згаданими на Хабре, тому я їх не називаю. А якщо вам цікава мобільна розробка і такі завдання, то приходьте допомагати нам зробити їх більш відомими і менш сором'язливі. Тестовим завданням для програмістів зараз є написання клону вищезгаданої Flappy Bird.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.