Кастомна аналітика для роуглайк-декбілдера за 0 гривень

Всім привіт! Мене звати Альберт Ковнір, я розробник гри Mutate! Fight! Purr!, яку ми анонсували на початку березня. Це божевільний декбілдер у біблійному сеттингу, де ти граєш за кота, який мутує щоразу, коли підбираєш реліквії.

Передмова

Я завжди був дата-дрівен в своїх рішеннях. Часто цифри (при статистично значущій вибірці) можуть сказати тобі набагато більше, ніж прямий фідбек або навіть живе спостереження за гравцями.

У своїй попередній грі, хардкорному платформері Through the Nightmares, ми активно використовували Game Analytics, трекаючи складність рівнів та коефіцієнт відтоку (churn rate) для прийняття геймдизайнерських рішень. Хоча гра і не показала великих продажів, це дозволило нам досягти 98% позитивних відгуків у Steam та досить високого відсотка людей, що проходять гру до кінця.

Коли ми почали робити Mutate! Fight! Purr!, перед нами постало завдання налаштувати аналітику і для неї. Це гра про тонкий баланс предметів, компаньйонів, ворогів та карт, що постійно синергують один з одним. Дженерік аналітичні сервіси, які підходять для більшості ігр, просто не могли дати нам необхідної гнучкості, тому довелося писати власну кастомну систему.

Ми все ще використовуємо Game Analytics для побудови базових красивих дашбордів та збору звітів про помилки, але весь аналіз балансу ведемо окремо.

Фаза 1: Підготовка

Ще до написання першого рядка коду ми створили документ, де продумали та розписали всі ігрові події (наприклад, гравець додав карту до колоди) та їх параметри (яку карту обрав, які були запропоновані, що вже є в колоді тощо).

Ми розділили їх на 3 основні категорії:

• Забіг (Run): всі події, які відправляються безпосередньо під час забігу. Результати бою, відвідування крамниці, проходження поверхів підземелля тощо.
• Мета-прогресія: що гравець вирішує прокачувати між забігами.
• Загальне: натискання на кнопку вішліста, переходи в соцмережі тощо.

Щоб аналітика була дійсно повною та корисною, її потрібно «збагатити». В аналітиці збагачення (enrichment) даних передбачає доповнення вихідних внутрішніх наборів даних відповідними внутрішніми або зовнішніми даними для підвищення точності, повноти та цінності рішень, що приймаються. По факту, це просто додаткові параметри, які приходять разом з усіма іншими івентами, але не стосуються їх напряму.

Ми розділили Енрічмент на дві частини:

• Глобальний, який приходить з усіма івентами без винятку.
• Енрічмент забігу, який домішується до всіх подій забігу.

Це дозволяє нам відокремлювати новачків від людей, які пройшли гру вже кілька разів, порівнювати результати між версіями, і в разі потреби, занурюватися глибше та повторювати ті самі ігрові ситуації локально, використовуючи seed генерації карти.

Фаза 2: Відправка та зберігання

В якості бази даних ми обрали BigQuery через її популярність, низьку ціну та дуже високий free tear ліміт (10 GiB storage, up to 1 TiB queries in on-demand compute free per month), якого, ймовірно, вистачить для більшості інді-ігор. Створення бази та заповнення схеми (мапінгу всіх полів аналітики до їхніх типів) займає час, але в цьому немає нічого складного, тож я утримаюся від опису процесу. Ось так виглядає готовий результат:

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

Розгортати свій, хоч і тонкий, але все одно потребуючий підтримки, сервер, мені дуже не хотілося. Тому на виручку тут прийшов Google Cloud Run. Це сервіс, який дозволяє розгортати контейнеризовані додатки практично на будь-яких мовах програмування на віддалених серверах Google. І він теж має досить високий фрі тір — те, що треба для нашої маленької прослойки.

Клієнт відправлятиме джейсон за адресою, на якій розгорнуто скрипт. Скрипт — домішуватиме туди серверний час і відправлятиме в базу. Також у кожного повідомлення є унікальний айді, який дозволяє серверному скрипту відсіювати повідомлення, які вже є в базі, але прийшли повторно через помилку на клієнті. Gemini допоміг мені написати цей скрипт на Python, що дуже сильно заощадило час на читання документації нової для мене технології.

Фаза 3: Захист

Я, з очевидних причин, не хочу, щоб гравець міг підгледіти запит, щось у ньому змінити та надіслати нам невірні дані. Перше, що спадає на думку — це енкрипшн усіх повідомлень, але тоді ми витрачатимемо дорогоцінні ресурси безкоштовного тіру гугл клауд рану. Тож я обрав простіше рішення. У хедер http-запиту з боку клієнта замішується HMAC, згенерований із секретним ключем, який знає тільки клієнт і наш гугл клауд ран скрипт. HMAC (Hash-based Message Authentication Code) — це криптографічний механізм, що поєднує секретний ключ із хеш-функцією для перевірки цілісності даних і автентичності повідомлення.

У загальному сенсі він набагато швидший в обчисленнях і займає набагато менше байтів, ніж якби ми передавали повністю зашифроване повідомлення. Коли запит приходить на сервер, наш скрипт рахує HMAC, порівнює з тим, який нам надіслав клієнт, і кладе дані в базу тільки якщо ці хеші збіглися (аутентичність повідомлення підтверджена).

Фаза 4: Відправка

Тут усе дуже просто і примітивно. Код відправки дуже простий:

Плюс додано можливість персистувати повідомлення, якщо гравець перебуває офлайн, і намагатися відправити його кілька разів, якщо відправка не завершилася успіхом. Також був доданий консент-попап, і якщо гравець не надав дозволу — вся аналітика буде відключена.

Фаза 4: Генерування репортів

Буде чесно сказати, що я ненавиджу SQL. Протягом останніх 15 років, раз на пару років у мене виникає необхідність щось зробити з його використанням. Я щоразу розбираюся в ньому заново і щоразу встигаю його повністю забути до того, як мені знову доведеться зануритися в чудовий світ селектів, джоїнів і партішинів.

І я радий, нарешті, повідомити, що ці дні добігли кінця!

Ви напевно чули про Google Gemini, і, можливо, чули про Gemini Gems. Це кастомні АІ-асистенти, складені під конкретні завдання з конкретною базою знань. Я задав простий промпт, завантажив у нього csv, експортовані з гугл таблиці, яку я показував у найпершому розділі, і схему бази даних біг квері у форматі json.

І це все. Далі я пишу будь-який запит природною нетехнічною мовою і отримую готовий SQL-запит.

Чесно, я вже навіть не перевіряю, що він видає мені у відповідь. Поки що всього один раз він спрацював неправильно, все інше працює ідеально. Звичайно, що CSV і схема для цього завжди мають бути повними та актуальними.

BigQuery дозволяє зберігати запити та ділитися ними з усією командою, що дуже зручно, коли ви працюєте не одні.

Якщо що — гугл не спонсорують цю статтю, але якщо її читає хтось із представників гугл — я не проти, зв’яжіться зі мною! :)

Ось приклад, у якому відсотку випадків сьогодні гравці воліють обирати конкретні карти:

Або як часто наявність якоїсь карти призводить до перемоги:

Сміливий погляд у світле майбутнє

Дивитися аналітику в самому BigQuery не завжди зручно. На щастя, в ній можна робити експорт звіту в гугл таблиці реально в два кліки, а там вже працювати з даними як з таблицею, будувати графіки і так далі.

Попри те, що ми вже отримуємо величезну кількість корисних даних, зараз ми все ще обкатуємо цю систему і формуємо базу корисних запитів. Наступною стадією буде створення простенького веб-інтерфейсу, який виводитиме нам найнеобхідніші дані та графіки в зручному вигляді, але поки що потрібно зайнятися самою грою.

Якщо текст був для вас корисний, ви дізнались щось для себе нове, або ви просто любите декбілдери — додавайте нашу гру у вішліст у Steam, грайте в демо, надсилайте мені більше даних для аналізу. І доєднуйтесь до нашої маленької, але затишної спільноти в діскорд, де ми разом обираємо нові фічі для імплементації в грі!

Якщо у вас є питання — пишіть їх у коментарях, я обов’язково відповім.

До нових зустрічей!

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини