Как в Тинькофф делали игру «три в ряд» для 3 млн клиентов

НачалоПочему решили делать игрыКак выбирали технологии и стекКак реализовали «Ряд наград»Зачем нужны подобные проекты

GTA V за время своего существования принесла разработчикам больше денег, чем три самых кассовых фильма в мире, вместе взятых: «Аватар», «Мстители» и «Титаник». Рынок игр перегнал рынок фильмов — и это говорит о том, что к этой индустрии стоит присмотреться. Рассказываем, для чего делают игры в Тинькофф.

Тинькофф уже несколько лет делает спецпроекты, в которых использует геймификационные механики. Например, компания запускала экочеллендж «Пока, пакет!». Он длился месяц, и в течение этого времени участники не должны были покупать в магазинах пластиковые пакеты — банк за этим следил. Если человек доходил до конца, ему выдавали кешбэк на супермаркеты.

Результаты спецпроектов показали, что внедрение геймификации растит метрики вовлечённости и интереса. Но в таком формате можно внедрять только часть игровых механик, поэтому компания решила выпускать игры внутри приложения.

В 2020 году Тинькофф заколлабился с Hasbro и выпустил первую игру — «Монополию». В ней приняли участие больше 700 тыс. человек, которые выполнили 2 млн заданий.

Такие результаты показала первая игра Тинькофф

«Монополия» оказалась успешной, поэтому команда продолжила выпускать игры. Следом зарелизили «5 букв», метрики которой оказались ещё выше. В ней принимали участие 6 млн пользователей, причём 61% из них — старше 31 года. Так Тинькофф смог охватить новый пласт аудитории.

«5 букв» оставили в приложении на постоянной основе

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

Чтобы выбрать направление для новой игры, команда решила обратиться к трендам. В топе жанров были RPG (англ. role-playing game) и пазлы. Ролевые игры делать сложно, долго и ресурсозатратно, поэтому остановились на поджанре пазлов — «три в ряд». Так получилась игра «Ряд наград».

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

Требования к игре предъявили такие:

  • Разработать за четыре месяца маленькой командой: лид, три фронтенда, два бэкенда и QA
  • Встроиться в экосистему Тинькофф — подключиться к авторизации, push-уведомлениям, Путешествиям, Афише, Mobile и другим сервисам
  • Выдавать призы от партнёров и экосистемы — кешбэки, подарки и деньги. Например, за первое место полагалось 300 000 ₽
  • Дать пользователям возможность играть из мобильного приложения на медленном интернете, потому что клиентов Тинькофф много и все они заходят с разных устройств
  • Внедрить спецэффекты VFX — до этого команда их никогда не делала на таком уровне
  • Быстро тюнить UI с учётом правок, потому что по ходу разработки у продакт-менеджеров появлялось много разных идей
  • Кастомизировать логику Match-3
  • Смотреть историю действий юзера, чтобы разбираться с багами

Команда сразу столкнулась с вопросом, на чём делать игру: Unity или HTML5.

Составили таблицу-сравнение двух платформ, но в итоге она не пригодилась: команда опиралась на другие критерии

Большинство пазлов разрабатывают на Unity. У этой платформы даже есть asset store, где можно купить готовые рабочие движки со спецэффектами в среднем за 40 $.

На Unity команда ни разу не работала, поэтому при выборе платформы предстояло оценить все плюсы и минусы каждого решения. Для этого опирались на три критерия:

  • Гибкость — на разработку было всего четыре месяца, поэтому приходилось всё быстро тюнить, внедрять и деплоить по несколько раз в день
  • Экосистемность — предстояло надёжно и безопасно внедрить все решения внутри экосистемы Тинькофф
  • Накопленный опыт — все предыдущие проекты команда делала на HTML5

При выборе Unity пришлось бы обращаться к подрядчикам — иначе за четыре месяца команда не успела бы ничего разработать. Поэтому остановились на HTML5.

Стек выбирали из трёх библиотек, с которыми уже работали:

  • React — удобно делать UI, но сложно реализовать красивые и производительные спецэффекты
  • Pixi — хорошо работает анимация, но сложно адаптировать интерфейс под разные форматы
  • Phaser — примерно то же самое, что и Pixi, но есть встроенный 2D-движок

В итоге выбрали Pixi в качестве графического движка и React, чтобы делать UI.

Когда определились с технологиями и стеком, приступили к технической части.

Разработка. Работали с движком Match-3. В игре есть фигурки разного цвета, и задача юзера — выстроить минимум три в ряд и схлопнуть их. На их место прилетают новые фигурки. А ещё есть бустеры, они взрывают всё в ряду или дают интересный спецэффект.

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

  • Ввели понятие псевдорандома. Во всех языках программирования функция Random работает примерно одинаково: выводит случайные числа. Но если построить на ней движок Match-3, будет сложно писать юнит-тесты, а воспроизвести историю игры юзера не получится никогда.

    Чтобы решить проблему и сохранить рандомность, ввели функцию PseudoRandom. Она точно так же выдаёт последовательность случайных чисел, но их можно воспроизвести.

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

    Подробнее о взаимодействии с бэкендом — в выступлении.

Тестирование. Команда сама написала движок и на фронтенде, и на бэкенде, и это позволило спроектировать саму архитектуру. Поэтому пошли по методологии Test Driven Development (TDD) и подготовили больше 200 юнит-тестов. В итоге QA-инженеры не нашли ни одного бага в механике Match-3. Также сделали бота, который проходил тестовые игровые сессии.

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

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

Пользователи не заметили этих «костылей», всё работало

Например, Pixi рендерил графический движок сзади, а сверху был React. Все затемнения нужно было делать на Pixi, но времени на это не было. Поэтому команда добавила HTML-тег и position: absolute.

Как делали спецэффекты, можно узнать из полной версии выступления.

Игру «Ряд наград» команда сделала за восемь месяцев: четыре ушло на идею и ещё столько же — на разработку. За четыре недели получили такие результаты:

  • 3 млн участников
  • 7 млн выполненных заданий
  • 6,8 млн выданных призов
  • 500 тысяч юзеров ежедневно

Команда превзошла все бизнес-ожидания, но делать игры стоит не только ради метрик. Они развивают команду разработки и компанию в целом.

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

Команда прокачалась в коммуникациях, аналитике и продуктовых скилах. Появилась «антихрупкость» — после таких масштабных проектов браться за игры подобного уровня уже не страшно.

Благодаря синергетическому эффекту развиваются и другие отделы: все хотят интегрироваться в новую игру и придумывают для этого фичи. Это способствует росту компании в целом, а у всех участников проекта появляется мотивация к свершениям.

Поделитесь увиденным

Скопировать ссылку
ТелеграмВКонтакте