Привет, я Алина Бриленкова, руковожу онлайн-направлением в ивент-агентстве Найт Стрит. Мы сделали игровую платформу (совсем недавно дали ей название — Playforma), не имея опыта в разработке. Я за это время прошла путь от «давайте построим империю» до «давайте оставим этот костыль как постоянное решение». О процессе создания продукта с нуля и о том, как нас кидало между ожиданиями и реальностью, подробно рассказали в прошлой статье.
Сейчас подробно разберу, что у нас в итоге получилось, без погружения в технические детали: расскажу, как устроена платформа, и подсвечу пару забавных кейсов. В конце — поделюсь, что планируем добавить в ближайшее время (разработка игровой платформы — это как бесконечный сериал с новыми сезонами).
Архитектура и технологии платформы
На уровне архитектуры наш инструмент для онлайн-тимбилдингов состоит из двух подсистем — пользовательской и административной. Пользовательская часть (фронт) — то, что видит участник. Административная (бэк) — это рабочий интерфейс для управления играми.
Отдельно существует dev-ветка — копия основного движка нашей платформы (её технической части) на отдельном поддомене. Любая новая функция сначала выкатывается туда для тестов, только потом переносится в прод. У команды всегда масса гипотез для проверки, и в работе они часто находятся параллельно, тестовая среда нужна постоянно. Приоритеты и статусы по ней фиксируются в таблице.
Как наша архитектура влияет на технологии
Наш формат — командно-ориентированный: с играми, где надо действовать синхронно, чатами, живой статистикой. Это требует, чтобы всё обновлялось мгновенно сразу у всех участников. Поэтому в основе Playforma лежат вебсокеты — технология для постоянного соединения клиента и сервера, через которое данные передаются в реальном времени. Всё обновляется без перезагрузки страницы и нет постоянных запросов к серверу, которые бы создавали излишнюю нагрузку.
Как устроена пользовательская часть
Пользователь всегда начинает игру с авторизации, после входа попадает на главную страницу игры. Здесь отображается афиша, текущий статус (например, «Игра стартует через 5 дней 12 часов» или кнопка «Перейти в игру»), а также блок, где организаторы размещают контент: например, приветственный текст, видео или инструкции.
Если к игре прикреплён вступительный брифинг, на главной появляется кнопка «Подключиться к брифингу. При нажатии открывается встроенная ссылка на видео-комнату в Zoom или другом сервисе.
Слева располагаются подсказки и элементы навигации: куда перейти, как найти правила, где посмотреть результаты. Правый блок — коммуникационный: там видны все участники команды, плюс чат для общения.
Личный кабинет и настройки команды
В личном кабинете участник может редактировать свои данные — ФИО, телефон, город. Поля гибко настраиваются, если заказчику это нужно. Можем добавить, например, «департамент» или другую информацию о сотруднике.
Здесь же можно: загрузить аватар, изменить пароль, выйти из профиля.
Настройки команды работают по тому же принципу. Можно изменитьназвание команды, загрузить логотип, добавить ссылку на чат в Телеграм или Zoom, если все решили общаться вне платформы.
Раздел «Правила» оформлен как отдельная вкладка с картинкой и кратким описанием всех базовых пунктов, которые нужно знать перед стартом. Рядом обычно размещаются ответы на FAQ, чтобы игроки могли решить типовые проблемы без поддержки. Если всё же нужна помощь, чат с техподдержкой встроен прямо в интерфейс. Сообщения операторов приходят туда же, где участники общаются между собой — не нужно открывать почту или сторонние мессенджеры.
Игровые режимы
Главный раздел платформы — «Игра», что логично для агентства Найт Стрит, которое изначально занимается играми. Внутри этого раздела мы делим все форматы для геймификации мероприятий по нескольким параметрам: как устроено взаимодействие участников, как выстроен прогресс и сколько по времени длится игровой интерактивный сценарий.
1. По типу взаимодействия:
командные игры — участники проходят задания вместе и общаются в общем чате;
индивидуальные игры — участник проходит задания самостоятельно, без командного чата. Видит только свой прогресс и не зависит от других игроков.
2. По логике прохождения:
линейный режим — каждое следующее задание открывается только после прохождения предыдущего;
гибкий режим — можно свободно переключаться между заданиями и проходить их в любом порядке.
3. По длительности:
короткая игра — до 10 заданий, как правило, в рамках одной сессии;
марафон — игра длится двое суток и дольше. Задания могут открываться сразу или по расписанию.
Дополнительная настройка внутри марафонов:
адвент-формат — задания отображаются не списком, а в виде набора карточек, которые участник открывает по мере прохождения (по логике календаря).
Параметры можно комбинировать между собой — например, собрать командный марафон с линейной логикой или индивидуальную короткую игру с гибким режимом.
Почти всё в интерактивных сценариях онлайн можно настраивать. В одной показывать статистику и рейтинги, в другой — полностью их скрыть. Менять оформление финальной страницы, конфигурацию подсказок и видимость отдельных блоков.
Как устроена административная часть
По сути это центр управления игрой: всё, что видит пользователь на фронте, сначала настраивается здесь. Это место, где создаются проекты, собираются задания, настраиваются правила и загружается весь контент — от описаний этапов до медиафайлов.
Через админку можно полностью контролировать процесс: запускать и останавливать игру, редактировать задания, управлять регистрацией и составом участников, менять визуал и подключать дополнительные механики. Например, превратить игру в марафон с этапами или добавить формат адвент-календаря.
Отдельный блок — мониторинг. Мы в реальном времени видим, как команды проходят задания: где застряли, сколько попыток сделали и сколько времени потратили. Если что-то идёт не так, администратор может вмешаться — перезапустить задание, начислить баллы или скорректировать результат.
По сути, это центр управления игрой: всё, что видит пользователь на фронте, сначала настраивается и проверяется здесь.
Безопасность и борьба с читерами
Как и в любой сложной системе, к вопросам безопасности мы пришли довольно рано. При тысячах одновременных пользователей любое лишнее поле в коде или открытая переменная могут стать источником уязвимости.
После первых тестов мы пересмотрели архитектуру хранения данных: внедрили передачу ответов и ключевых идентификаторов в нечитабельном виде, ввели дополнительные проверки на уровне сервера, чтобы доступ к заданиям зависел от прав пользователя и состояния игры, а не только от наличия данных в браузере. Сейчас даже если открыть консоль или скачать элементы страницы, пользователь увидит наборы данных, которые сами по себе не дают прямого понимания ответа без контекста игровой логики.
Даже если ваш продукт напрямую не связан с хранением денег и личными данными, минимальные меры для безопасности необходимы. Чем интереснее продукт, тем выше шанс, что кто-то попробует обойти систему.
Защита от самых умных
Читерство для нас — не про хакеров в чёрных худи, а про обычных участников, которые просто хотят пройти игру любым способом. Кто-то открывает DevTools, кто-то ищет файлы заданий в кэше или Storage, кто-то делится правильными ответами в чатах. Наша цель — сделать игру максмально честной, а значит постараться, чтобы все эти манипуляции не давали ощутимого преимущества.
На уровне фронтенда и бэкенда реализовано несколько защитных решений:
непрозрачные названия медиа и ресурсов, чтобы по имени файла нельзя было напрямую понять его содержимое или номер задания;
доступ к заданиям проверяется на стороне сервера: учитываются права пользователя, команда, текущий этап игры и условия открытия задания;
шифрование текстовых ответов и промежуточных данных, чтобы даже загруженный элемент не раскрывал смысла без связанного контента.
Дополнительно мы внедрили вариативные задания: внешне они выглядят одинаково, но содержат разные данные для разных пользователей. Например, у одного участника правильный ответ — «байт», у другого — «мобс». Даже если они обменяются ответами, ничего не получится, каждый вариант проверяется по своей логике. Решение существенно снижает возможность массового слива ответов.
Мониторинг и контроль
Даже при наличии всех технических ограничений важно видеть, что происходит в игре прямо сейчас, чтобы не пропустить косяк. Плюс надо анализировать вовлечённость. Поэтому в админке платформы можно в реальном времени отслеживать прохождение заданий: кто прошёл, во сколько, сколько времени потратил.
Если кто-то, например, открыл задание раньше, чем это было запланировано игрой, событие сразу видно в логах. Дальше мы разбираемся: это ошибка в настройках или попытка обойти систему. При необходимости можно выгрузить подробную статистику участников: время входа, IP-адреса, тип устройства.
Эти данные не дают прямого доступа к пользователю, но позволяют заметить странности: например, если две команды постоянно играют с одного IP. В таких случаях мы уточняем у клиента: «А участники случайно не муж и жена, которые играют из одной квартиры?». Это, кстати, реальный случай с одной из первых игр: думали, что нашли мошенников, а оказалось — просто семью.
Полный контроль прохождения — не для тотальной слежки, а ради честной игры. Если кто-то действительно пытается обмануть систему, его можно заблокировать.
Совместная работа с безопасниками клиентов
Некоторые компании относятся к информационной безопасности особенно строго, особенно если сотрудники играют со своих корпоративных адресов. В таких случаях мы подключаем их IT- и ИБ-отделы, заполняем опросники и проводим отдельные встречи, чтобы пройти внутреннюю проверку.
Обычно клиенты всего лишь хотят понять, где физически расположены наши серверы, какие методы защиты и шифрования мы используем, какие данные собираются и кто имеет к ним доступ. После этого согласовываем решение.
Иногда достаточно добавить наш домен в корпоративный «белый список», чтобы участники могли заходить в игру с рабочих компьютеров. Если требования сложнее, мы подстраиваемся: можем изменить схему авторизации, отдельные параметры безопасности или даже поднять изолированную ветку продукта под конкретный проект.
Кейсы и нагрузочные тесты
Как мы отреагировали на тролля Однажды участник решил повеселиться и протестировать нашу систему на прочность: начал массово создавать аккаунты. Не десятки, а тысячи. С той компанией, которая заказала игру для сотрудников, было согласовано, что регистрация — открытая: без капчи и без подтверждения e-mail, так что зайти можно было хоть с адресом qwerty@gmail.com
Мы вычислили источник и заблокировали IP, с которого шла активность. к счастью, атакующий не использовал VPN, поэтому разобраться удалось быстро. Вообще мы рады этому случаю: он научил нас, что любая платформа для управления участниками онлайн и работающая с большим количеством пользователей, должна быть готова к несанкционированной активности.
После этого случая капча и подтверждение почты стали стандартом для крупных проектов, плюс на них всегда дежурит команда — фронтенд, бэкенд и менеджер. Они следят за системой в реальном времени и быстро реагируют на любые аномалии — от всплесков трафика до подозрительных входов.
Иногда защита срабатывает слишком усердно. На одной игре бэкендер в панике прибежал:
— Нас DDoS-ят, с одного IP идёт сотня запросов!
— Друг, спокойно, это просто все играют из корпоративной сети
Как платформа выдержала 7000 участников
Один из самых показательных кейсов — крупная игра, когда мы заранее загрузили в систему около 40 000 логинов и паролей. Регистрация была по списку, то есть попасть в игру могли только участники из базы клиента.
В утро запуска в одно время, 9:00, в игру зашло примерно 7000 человек — и хороший боевой тест: тысячи одновременных входов, запуск заданий, постоянные обновления данных. Платформа выдержала запуск, но проект показал зону, которую нужно усиливать — подключения вебсокетов. При большом количестве одновременных подключений они начинают упираться в свои пределы, из-за чего система местами реагирует медленнее, чем хотелось бы.
Сейчас мы дорабатываем эту часть: оптимизируем схему обмена данными через вебсокеты, чтобы равномерно распределять трафик и снижать зависимость от числа одновременных подключений.
Планы по развитию платформы
Что у нас в планах:
Выкатить визуальные обновления (завершаем проверку на dev-ветке). Результат нашего UX-аудита, обновили интерфейсы, сократили время отклика, улучшили навигацию и логику игровых сценариев.
Выкатить обновления по вебсокетам. Мы оптимизировали работу с ними, полностью переработали систему обмена данными, чтобы увеличить количество одновременных подключений без падения производительности.
Продолжать выпуск малых функций. Это небольшие улучшения, которые у нас постоянно в работе: от настройки логов до мелких визуальных апдейтов, заметных пользователю.
Новые игровые механики и функции
Помимо технических задач и масштабирования продукта, мы постепенно внедряем новые возможности для игроков и организаторов:
Автоматизация заданий с метриками: участники вводят данные (например, количество шагов или выполненных действий), а система автоматически подсчитывает результат и отображает прогресс на шкале.
Дополнительные необязательные задания. Маленькие квесты, за которые можно заработать бонусные баллы и подняться в общем рейтинге.
Одноразовые ответы и промокоды. Участник вводит уникальный код (с офлайн-мероприятия или который он получил в другой игре) и получает очки или открывает новый этап.
Мини-игры. Простые вставки, например, головоломка аля «пятнашки», которые можно добавить в сценарии как разогрев или тайм-киллер, пока участники ждут результаты.
Вторая награда. Помимо стандартных баллов — внутренняя «валюта» (монетки, жетоны), которую можно обменять на сувениры или бонусы компании.
Система ачивок и бейджей. Например, если игрок прошёл пять заданий быстрее двух минут, он получает титул «Молния» и бейдж в личный кабинет.
Разграничение ролей внутри команды. Каждый участник видит только свою часть интерфейса: таймер, ответы или подсказки — в зависимости от роли. Это делает взаимодействие ближе к офлайн-игре.
Очень важное в планах — добавить механику «блендера». Это автоматическое перемешивание составов команд после каждого этапа. После завершения задания система собирает участников заново, случайно распределяя их в новые группы. Такой формат делает игру динамичнее: участники постоянно взаимодействуют с новыми людьми, быстрее знакомятся и учатся договариваться.
С технической стороны всё сложнее. Если обычное рандомное распределение команд уже реализовано, то «блендер» требует дополнительной логики. Как учитывать тех, кто не дошёл до этапа? Нужно ли подтверждение участия? И главное — как при перестроении не сбросить прогресс игроков?
Сейчас этот функционал на этапе ТЗ. Мы прорабатываем сценарии, тестируем гипотезы и обсуждаем, для каких форматов (коротких или длинных игр) «блендер» вообще будет уместен.
Спасибо, что дочитали до конца! Уже пишем для вас новую статью
Ну вот, разобрали, как устроена платформа для квестов и игр сейчас. Со всеми рабочими решениями, костылями и тем, что со временем стало системой. Дальше хотим пойти глубже: рассказать, как адаптировали Playforma под офлайн-ивенты и разобрать реальные кейсы и факапы. Там всё самое интересное. И отдельно спасибо аудитории Хабра за обратную связь на прошлые статьи. Мы в агентстве Найт Стрит всё читаем, обсуждаем внутри команды и многое берём в работу. Правда — приятно видеть, что это откликается. Остаёмся на связи.
