Можно ли создать жизнеспособный гибрид двух кардинально разных игровых моделей и философий — классического пазла «три-в-ряд» (match3) и слот-машины? Какие метрики важно учитывать в азартных играх и какие инструменты для этого подходят? И почему представитель одного из крупнейших в мире издателей социальных мобильных казино обратился за реализацией такого проекта к ребятам из студии zGames — подразделению компании Softeq Development. Ответить на эти вопросы помогут разработчики игры Lucky Swipe! — геймдизайнер Андрей Бородко, техлид Андрей Рылач и менеджер проектов Алексей Кислов.
Что такое Lucky Swipe! и почему о ней стоит поговорить
Андрей Бородко: Lucky Swipe! — это необычный гибрид нескольких суперпопулярных на сегодняшний день игровых жанров: match3-пазла, основанного на swipe-механике, и слот-машины.
Принцип работы слот-машины известен всем. Нажимаешь кнопку — барабаны с вишенками и прочими деликатесами крутятся и, при совмещении определённых значений, ты получаешь приз. Вместо банального слота, которых на рынке мобильных игр тысячи, наш клиент захотел сделать динамичный match3-пазл, в основе которого лежат те же слотовые принципы. Вместо того, чтобы крутить слоты, ты просто «свайпаешь» символы. Символы «лопаются», и из них выпадают определенные призы. Из каждого символа может выпасть как определенное количество денег, так и специальные бонусы, которые умножат твой доход. Чем более «длинным» будет свайп, тем больше шансов у тебя выбить большой приз. Фактически, это слотовый механизм в новой обёртке.
Алексей Кислов: И нашей целью было не только разработать правильную экономику и математику приложения, но и упаковать всё это счастье максимально ярко и драйвово, чтобы игрок «забыл обо всём на свете».
А.Б.: Да, только когда мы говорим об «игроке» приложения match3+гемблинг, то имеем дело с очень сложным стыком специфических пользовательских аудиторий. Фактически, это был экспериментальный проект с большими рисками.
The Challenge
А.К.: Почему мы взялись за такой неоднозначный проект? На это повлияло несколько ключевых факторов. Во-первых, конечно же, это была возможность создать нишевый продукт, у которого практически не существует аналогов на рынке (по крайней мере, выполненных на таком высоком уровне). Во-вторых, получение опыта разработки и интеграции полноценной гемблинговой модели в игру классического жанра. Всё, что связано с разработкой гемблинговых игр, — это очень тонкая «кухня», с достаточно сложной внутренней математикой, экономикой и чрезвычайно требовательной аудиторией. А, в данном случае, нужно было не только полностью разработать гемблинговую модель, но и органично встроить её в незамысловатый match3.
Если в мире геймдева что-то можно назвать челенджем, — то это как раз тот самый случай.
А.Б.: И, кстати, ещё одним важным фактором стал сам клиент. Можно сказать, что именно он, будучи автором идеи проекта, убедил нас в том, что сделать успешный проект в этой нише реально. За что, в итоге, мы ему невероятно благодарны.
О чём думал клиент
А.Б.: Наш клиент — эксперт в области онлайн-гемблинга, долгое время занимал руководящие посты в компаниях-разработчиках и издателях социальных казино. В определенный момент он решил, что хочет сделать собственный проект. У него изначально была общая идея, наброски визуальной «обёртки» игры и просто безграничный опыт и знания в области азартных игр.
А.К.: И для реализации проекта ему не хватало только надёжного партнёра с опытом в Unity фронтенд- и бэкенд-разработке. Команда zGames, игровая студия компании Softeq Development, в итоге, подошла по всем параметрам. У нас уже был опыт создания подобного продукта — игры Match3Volution, где тоже используетcя комбинация «три-в-ряд» и гемблинга, для которого мы разрабатывали математику, игровую механику и визуальную часть. Также у нас была возможность выполнить полный цикл разработки на Unity — от создания геймдизайн-документа (GDD) до поддержки игры после релиза.
Сложности разработки и интеграции гемблинговых элементов
Андрей Рылач: Существовало море чисто технических нюансов. Ключевыми моментами при разработке гемблинговых игр являются обеспечение стабильности работы клиент-серверного соединения, возможность сохранения сессии и восстановления приложения без потери данных при обрыве связи. Для гемблинга это суперважно, так как если пользователь сделал ставку и произошёл обрыв связи (в моменты пиковых нагрузок это возможно), а приложение не имеет возможности сохранения сессий и полного восстановления, — он просто теряет деньги. Для разработчика такой сценарий недопустим.
Один из вариантов решения проблемы — горизонтальное масштабирование серверов с сохранением сессий, для чего на стороне сервера мы использовали Amazon ElastiСache Redis, In-Memory хранилище от AWS, взаимодействие с которым позволило нам сохранять и восстанавливать сессии.
Плюс, чтобы наверняка избежать подобных косяков, мы применили комбинированное решение — часть бизнес-логики обрабатывалась на стороне сервера, часть на стороне клиента. Благодаря этому интернет-соединение было нужно пользователю только при запуске игры и в самом её конце — для расчета результатов. По ходу игры связь могла пропасть, но юзер бы даже этого не заметил, спокойно продолжая играть. В итоге мы сумели добиться такого уровня стабильности и восстанавливаемости продукта, что игрок никогда не потеряет ни одного цента по вине приложения или разрыва сети.
А.Б.: Исходя из серверной аналитики, около 99% игроков никогда не сталкивались с проблемами, связанными с потерей данных при обрыве связи. Мы изучали одну из топовых MMO-игр в App Store и обнаружили, что даже в ней нет некоторых вещей, которые мы использовали в Lucky Swipe! — к примеру, сохранения сессии после обрыва и восстановления приложения после падения в абсолютно том же месте.
Технические решения
А.Р.: Технической части этого проекта можно посвятить отдельную статью, но, если говорить кратко, то в первую очередь стоит упомянуть такие «рабочие инструменты», как многопоточность (multithreading) и использование стека AWS и других внешних сервисов.
В общем случае, в проектах на движке Unity многопоточность не используется, но так как Lucky Swipe! является клиент-серверным приложением и с сервером происходит постоянный обмен данными, то для ускорения работы и оптимизации приложения мы решили все взаимодействия с сервером по протоколу WebSocket выделить в отдельный поток. Это необходимо, чтобы основной поток не блокировался (что возникает в случае использования протоколов WebSocket или TCP/UDP sockets).
Мы сделали выбор в пользу многопоточной работы, так как это помогало избежать большинства проблем, возникающих в процессе клиент-серверного взаимодействия. К примеру, при получении ответа от сервера в виде потока байт его необходимо десериализировать для дальнейшей работы. И если проводить десериализацию в основном потоке, то сталкиваешься с лагами на реальных устройствах. Либо другой случай. При сворачивании приложения, основной поток приостанавливается, что приводит к разрыву соединения между клиентом и сервером. Но если выделить сетевое взаимодействие в отдельный поток, то такая проблема просто не возникнет.
Что касается технологического стека AWS, то при создании Lucky Swipe! мы впервые максимально плотно работали с ним при разработке клиент-серверного приложения, и это действительно невероятный набор девелоперских сервисов для самых различных задач, касающихся работы с данными, — от сбора, хранения и передачи информации до обеспечения высокого уровня безопасности и многовекторного анализа данных. Из стека AWS мы использовали следующие сервисы:
- AWS ElastiCache — для In-Memory хранения сессий;
- AWS Kinesis Firehose — для сбора статистики по каждой игре;
- AWS S3 — для хранения DLC контента.
Также очень полезным для нас оказался сервис New Relic, а точнее New Relic APM (на стороне сервера) и New Relic Mobile (на стороне клиента). Это партнёрский для AWS аналитический сервис, просто аналитический рог изобилия, который служит для мониторинга всех процессов, происходящих в рамках клиент-серверного соединения в реальном времени. К примеру, на стороне клиент-приложения отслеживается количество установок и запусков приложения, время выполнения и отклика каждой транзакции, crash rate, используемые устройства и источники трафика, ведется логирование ошибок. То есть, фактически, New Relic рисует для нас общую аналитическую картину работы клиент-серверного приложения. Это как монитор жизненно важных функций в реанимации — в любую секунду ты видишь, что происходит с «пациентом» и в каком он состоянии.
А.К.: Раз уж зашел разговор о клиент-серверной архитектуре в целом, то нужно отметить и другой её важный аспект.
В Lucky Swipe! речь идёт о клиент-серверном приложении с возможностью удалённой настройки. Наша серверная инфраструктура открывает перед игроком абсолютно новые впечатления от игры, позволяя при необходимости даже кардинально перестраивать её изнутри, при этом не требуя от пользователя постоянного выкачивания глобальных обновлений приложения.
А.Б.: Также стоит сказать несколько слов об аналитической системе Amplitude, которою я очень советую всем разработчикам игр. Амплитуда очень проста в использовании и даёт возможность без задержек получать реальные данные по активности игроков — прогресс прохождения, достигнутый уровень, завершенные игры, начисленные бонусы и т.д, а при должной фантазии позволяет изучить практически любые зависимости внутри игры. С её помощью видна полная картина поведения пользователя, а это очень помогает понять, какие элементы геймплея нравятся ему в большей или меньшей степени, и что тебе, геймдизайнеру, нужно изменить.
А.Р.: Не могу не упомянуть такую важную фишку от zGames, как zLib. Это наша внутрикорпоративная библиотека решений типовых задач (common library), встречающихся в большинстве проектов, — интеграция социальных сетей (Facebook, Twitter), рекламных платформ (Chartboost, AdMob и др.), платёжных систем для мобильных приложений и Facebook и других типовых элементов. zLib позволяет не изобретать колесо в каждом новом проекте, а использовать уже готовые и проверенные решения. Таким образом, мы сильно экономим время на разработку (от 5 до 50% экономии, в зависимости от размера проекта) и, соответственно, деньги клиента. К примеру, в уже упомянутой Match3Volution, использование zLib при создании анимации геймплея позволило сэкономить около 80 рабочих часов разработчиков. Также zLib максимально упрощает процесс баг-фикса и саппорта, т.к. все решения из библиотеки неоднократно выверены. Подробнее о zLib мы рассказывали здесь.
В Lucky Swipe! мы использовали подсистему экшенов zLib для создания визуальных эффектов, а также подсистемы аналитики и интеграции платежных систем под iOS. Плюс, благодаря этому проекту, мы расширили библиотеку стандартами логики взаимодействия с Amplitude, New Relic, Kinesis Firehose и другими продуктами из стека AWS.
Внутриигровая математика и экономика
А.Б.: Изначально нужно понимать, что разработка слотов стоит на трёх взаимосвязанных китах: это игровой прогресс, призовая математика и экономика. В Lucky Swipe! мы полностью разрабатывали экономику и прогресс, но практически не занималсь математикой — эту часть клиент решил выполнить силами собственной команды.
Под «созданием игровой математики» в отношении азартных игр, мы, грубо говоря, подразумеваем разработку матрицы вероятностей, которая просчитывает, насколько часто игрок проигрывает или выигрывает. Для валидации математической модели нужно было обкатать её на репрезентативном количестве итераций (хотя бы нескольких десятках тысяч игр). Вот этой частью разработки математики занималась наша команда.
Главное, чего нам удалось добиться в данном аспекте — игра ведет себя абсолютно «честно», по отношению к игроку, обеспечивая правильный показатель RTP (Return to Player, процент возврата игроку — ключевой математический показатель любой азартной игры).
Основываясь на полученной от нас информации, специалисты на стороне клиента могли выверить все математические показатели игры. И уже после окончательной проверки вся математика возвращалась к нам, а мы увязывали её с экономикой и прогрессом и делали общую настройку работы системы. К слову, в итоге всё работает очень точно, отклонения от плановых значений минимальные.
Выводы после тестирования
А.К.: После тестирования продукта на реальной аудитории пришлось полностью изменить обучающую часть.
Изначально, мы сделали в игре подробный и детальный туториал, который готовил пользователя к «активным боевым действиям», но во время тестирования оказалось, что определённый процент пользователей даже не доходил до основной части игры.
В современном мире мобильных игр (особенно казуальных) существует четкая тенденция к ускорению игровой динамики и полному упрощению — у пользователя нет ни малейшего желания тратить время на долгое обучение игровой механике. Весь игровой процесс должен быть интуитивно понятен и с первого клика погружать в самый водоворот событий.
Поэтому вместо туториала мы добавили в игру Лепрекона (которого клиент почему-то «жэстачайшэ» запретил называть каноничным лепреконским именем Патрик) — персонажа, который на протяжении большей части игры ненавязчиво помогает понять, как всё вокруг работает и что делать дальше. Без отрыва от производства, так сказать. И это сработало — около 85% пользователей прошли, как минимум, сюжетную линию Лепрекона, а это достаточно большая часть игры.
Попасть нельзя промахнуться: нишевый продукт для узкой аудитории
А.К.: Попадание или непопадание практически любой мобильной игры в аудиторию очень наглядно можно проиллюстрировать показателями average session duration, average daily game time и retention rate (процент удержания пользователя). Для мобильных игр высоким показателем дневной сессии считается около 24 минут в день, со средней сессией в 5-7,5 минут. Мы же в итоге вышли на среднюю длину сессии около 18-20 минут. Для сравнения, у match3-суперхита Candy Crash Saga этот показатель по США в 2016 году составил 34 минуты, тогда как в Clash of Clans (топовая MMO-стратегия) игроки в среднем проводят 20 минут в день. Изначально на стадии тестирования показатель средней длины сессии составил около 15 минут, но благодаря обновлениям, в которых мы полностью переработали туториал и ввели систему миссий и «ачивок», данный показатель удалось увеличить на 25-30%. Retention rate также вырос на 15-17%.
А.Б.: А топовые дневные сессии в Lucky Swipe! периодически «выдавали» какие-то невероятные цифры — 3-3.5 часа в день. Для мобильных игр это просто запредельные значения, которыми могут похвастаться только супертоповые приложения, наподобие Pokemon Go. У нас даже был случай, когда два игрока из США прокачались до максимального уровня, что требовало просто уйму времени и казалось нам практически нереальным. Из-за них пришлось даже слегка поменять верхний порог прокачки. Соответственно, можно сказать, что Lucky Swipe! действительно попал прямо в яблочко!
А.К.: Игра написана на Unity, то есть фактически является кроссплатформенной, и её можно было скомпилировать под любую платформу и девайс, но мы в итоге выпустились только на iOS. В процессе разработки у клиента были мысли об оптимизации игры под Android, и даже появился релиз-кандидат одной из версий, но в итоге заказчик решил, что основные приоритеты — проработка всех фич в iOS-версии и максимальное изучение аудитории.
Игра стоила свеч: наш опыт
А.Б.: Если говорить глобально, то из этого проекта мы вынесли серьёзный опыт полноценной разработки гемблинг-игры, со всеми вытекающими последствиями: отточили использование многопоточности на Unity, освоили работу с огромным количеством внешних сервисов, добились максимально стабильной работы клиент-серверного соединения, расширили zLib и разработали сложную систему игровой экономики и математики.
А.К.: Плюс, помимо плюшек из области продакшена и геймдева, благодаря проекту Lucky Swipe! мы глубоко погрузились в тему технологий выведения большого игрового продукта на рынок. Фактически, теперь мы знаем, как внутриигровыми и околоигровыми средствами сделать игру настолько привлекательной с точки зрения маркетинга, чтобы она сама могла успешно продавать себя пользователю.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.