Инструменты разработки и LiveOps: Как стабильно управлять тоннами контента игры

Вводная

На протяжении последних 9 лет в игровой индустрии, я изучал очень много разных инструментов и использовал их для разработки и оперирования Играми. О каких-то нет возможности рассказать, какие-то уже не актуальны: например сборка и экспорт json файла GUI из Adobe Illustrator, а какие-то решения будут актуальны ещё продолжительное время.

Сегодня хочу поделиться готовым решением/инструментом работы с игровыми данными. Это решение подходит для любого проекта, может значительно облегчить не только жизнь начинающему проекту, но и получить отличные результаты для большого проекта как Pixel Gun 3D, которому более 8 лет. Ускорить заведение типов Игровых предложений с 2-х недель до 3-х дней, и ускорить разработку других фич в 2-3 раза.

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

Первоочерёдная задача

Свой опыт в проектировании хорошей архитектуры проекта, я получил, создав хитовый проект и оперируя им на протяжении 3-х лет, после ухода, возникла потребность в поиске альтернативного инструмента, который бы был доступен каждому разработчику, независимо от того, под какую платформу он разрабатывает проект и каким движком пользуется.

Когда я пришёл на проект PixelGun3D первое, что меня встретило и с чем пришлось разбираться - это 100500 GoogleSheets табличек с огромным количеством разбросанных данных, которые необходимо было как-то структурировать и сформировать единую систему и как следствие возможность ускорить разработку проекта и снизить кол-во возможных багов и ошибок со стороны ГД.

Задача была разбита на 2 больших блока:

1. Создать архитектуру централизованных конфигов сущностей;

2. Подготовить инструмент для удобной работы большого кол-ва Гейм-Дизайнеров.

Результаты, которых удалось добиться на PixelGun 3D

Кол-во и сложность конфигов
• Было 30 разных конфигов на разные сущности → стало 7 конфигов с единой структурой

Разработка нового типа GameOffer
• Было 1-2 недели → cейчас 2-3 дня

Разработка фильтров и условий выдачи в разных системах
• Было 4-5 дней → сейчас 2-3 часа

Ошибки в заведении контента
• Были 1-2 раза в месяц → сейчас 1 раз в 2-3 месяца

ARPDAU
• +17% за счет более точных Офферов и разнообразия под разные когорты Игроков

Порог освоения системы
• Был черный ящик логики и параметров, где только 1 мастер ящика знает, как его настроить. Стал прозрачный магический шар, с которым новый джун ГД разобрался в новых системах за 3-4 дня

Если вы плохо понимаете о чем речь в данной статье, чтобы лучше погрузиться в тему игровых данный, рекомендкю посмотреть мое видео на → DevGAMM ←

Разработка инструментария и исследования проходили в несколько этапов, рассматривал разные инструменты и сервисы, с которыми я работал последние несколько лет, большая часть решений была опробавана на практике в разных проектах.

В связи с тем, что проект Pixel Gun 3D — это полноценнный оперируемый проект с огромной аудиторией и приличными доходами, были сформированы определенные требования и критерии оценки отбора “кандидатов”, расскажу о тех, кто не прошел строгий отбор:

Charon

https://gamedevware.com/w/view/product/charon

➕➕

• Хорошо подходит для создания быстрого игрового прототипа и небольшого проекта на Unity.

• Отличный инструмент для знакомства с базовыми понятиями EAV-модели (Сущность-Атрибут-Значение) и компонентной системы.

➖➖

• Работа множества геймдизайнеров превращается в боль, если плохо структурировать фичи. Приходится постоянно мержить UID-сущностей.

• Нет онлайна, синхронизация единого файла настройки происходит только через Git.

• Работает только с Unity.

• Нет возможности разделить единый файл на разные JSON’ы.

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

Castle DB

http://castledb.org/

Не буду сильно заострять внимание на этом решении, так как по сути это был один из первых экспериментов среди подобных инструментов. Гениальный разработчик и один из основателей языка Haxe, Nicolas Cannasse, создал его для студий MotionTwin и ShiroGames.

Из особенностей можно отметить, что у него есть интересный встроенный редактор тайловых игровых уровней.

Отбросили этот вариант по тем же причинам, что и Charon.

Balancy (UnnyNet)

https://developers.unnynet.com/

Хороший сервис, я лично приложил руку к созданию и развитию этого сервиса. Основная идея и архитектура будущего сервиса были заложены при моем непосредственном участии.

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

1. Стоимость. При огромном онлайне Pixel Gun 3D и объеме трафика, пришлось бы платить приблизительно $7-9 тысяч в месяц. Это не ключевой фактор в принятии решения, но его однозначно стоит учитывать при финансовом планировании.

2. Один из критериев и принципов звучал так: «Нужна возможность быстрого изменения структур данных и банального костыляния». Все же в геймдеве время и скорость итераций часто играют решающую роль, поэтому возможность что-то быстро собрать из фекалий и веточек — хороший плюс, в сервисе такой возможности нет, только архитектура, только красиво и правильно.

3. Проект уже существует и управление настроено на GogleSheets таблицах. Переезжать полностью на новый сервис — это огромный объем работы, который может сильно замедлить разработку игры и выпуск нового контента.

4. База данных с конфигами хранится на стороне Balancy, и к ней нет прямого доступа.

5. Это проприетарный сервис, Bus-фактор всегда нужно учитывать. Если за работу инструмента отвечают всего несколько человек, при выпадении одного из них, сервис может стать неподдерживаемым, т.к. у вас нет доступа ни до базы данных, ни до кода самого сервиса. При таком сценарии блокируется дальнейшая разработка и оперировнии проектом, что в итоге выливается в огромные риски для бизнеса.

Articy и Beamable

https://www.articy.com/en/

https://beamable.com/

Эти два инструмента заточены под решение конкретных задач.

Например, Articy сделана с упором на сценаристов и нарративщиков. Там удобно формировать огромные истории, следить за развитиям персонажей и так далее.

Beamable — это огромный комбайн с кучей возможностей, однако все они подходят для специфических нужд, а требования для нашей задачи они не выполняли + было достаточно дорого.

Решение на гугл-таблицах

Попробовал сделать подобие админки в гугл-таблицах нативными средствами. Приходилось учитывать десятки дополнительных параметров, валидации и прочего-прочего.

Очень много времени уходило на приведение инструмента к удобному виду. К тому же, любой человек с правами на редактирование мог случайно что-либо поломать, к примеру: При перемещении столбцов, можно сломать формулу или query запрос, если они не учитывают порядок столбцов.

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

На чем остановился

В определенный момент я вспомнил про AppSheet — сервис, который позволяет настроить приложение поверх гугл-таблиц, синхронизирует данные и позволяет удобно с ними работать, итог GoogleSheets + AppSheet = PineappleApplePen, если одной фразой: «Вся мощь гугл-таблиц в удобной оболочке».

В AppSheet есть раздел, где идет настройка и управление отображением гугл-таблицы — UI, UX, отображения, столбцы, параметры и многое другое. По настройке и созданию архитектуры управления гугл-таблицами, надеюсь, когда-нибудь напишу отдельную статью или проведу стрим.

В PG3D было гигантское количество готовых таблиц, часть уже подходила для использования в сервисе, достаточно было только импортировать и собрать приложение.

Остальные не вписывались в требования по структуре БД, поэтому их пришлось пересобирать. Например, в игре было 7 отдельных таблиц по GameOffer. После структуризации конфигов, параметров и создании универсальной системы, возникла 1 единая таблица, которая учитывала все возможные варианты игровых предложений.

Так выглядит итоговая таблица системы GameOffer в гугл-таблицах:

Она же, настроенная в AppSheet:

Основные возможности AppSheet

1. Валидация входных параметров. AppSheet знает, какие параметры нужно указывать в конкретных ячейках. Например, на видео я пытаюсь написать буквы в поле Amount, но приложение разрешает вводить только цифры.

2. Авто-генерация ID по любым удобным правилам. Хочешь, числовой ID, хочешь GUID. Максимально гибкая настройка.

3. Возможность задавать динамические фильтры.

4. Возможность сделать ссылочный тип и указывать референс на запись в другой таблице + возможность сделать удобную организацию ключей локализации.

5. Возможность удобно организовать хранение таблиц и данных. Таблицы могут храниться в разных местах и иметь разный доступ — в приложении все это собирается в единую систему.

6. Возможность залить файлы картинок на любой ресурс и удобно просматривать игровые сущности.

Дополнительные возможности

• Возможность написать собственный log (история изменений) и разделение ролей, кто может просматривать, редактировать, создавать и удалять. Проще говоря — собственный менеджер CRUD.

• Удобно просматривать и управлять контентом с мобильных устройств.

• Вероятность того, что сервис перестанет существовать достаточно низкая. Google купила AppSheet довольно давно и с тех пор только развивает и улучшает сервис.

• Очень-очень-очень гибкие возможности по созданию любой структуры и архитектуры фичи.

• Гибкая настройка UX и UI пользователя, и управление отображением полей в разных сценариях.

• Еще одно мощное преимущество подобной системы, если хорошо все настроить — возможность посмотреть где и в каких точках могут быть выданы игровые предметы и их статус.

• Создание автоматизаций на разные действия. Например, можно сделать, чтобы ГД лиду каждый день присылали отчет об изменениях в проекте на почту.

• Можно использовать для любого движка: Unity, UE4, Cocos, Defold и других.

Недостатки

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

Стоимость

• Бесплатно — при использовании маленькой командой в тестовом режиме.

• $20 — при использовании через один аккаунт и создание внутренней системы разделения ролей, логина и паролей.

• $20 — за каждый новый аккаунт, если использовать доступ по аккаунтам.

В завершении статьи поделюсь историей из личного опыта. Однажды я потратил на разработку подобного сервиса примерно 600 тысяч рублей личных средств и получил...