Как собрать игровую платформу для семей сотрудников, а не набор отдельных активностей

Это четвёртый похожий проект для крупного российского бренда, в котором я веду backend-направление. Над продуктом работает команда через Deep: отдельный frontend-разработчик реализует пользовательский React-клиент, а моя зона ответственности — Laravel API, бизнес-логика, административные процессы и интеграции.

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

С первого взгляда это выглядит как яркий интерфейс с несколькими мини-играми. На практике платформу удерживает единая модель данных и правил. Кто именно выполняет задание? Какой ребёнок сейчас активен? Подходит ли эта активность его возрастной группе? Открыта ли она сегодня? Можно ли пройти её повторно? Что происходит с баллами после окончания кампании? Эти вопросы не должны каждый раз решаться заново на уровне экрана.

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

Такой подход защищает от типичной ошибки семейных продуктов: когда действие одного человека случайно влияет на состояние другого. Родительские материалы могут фиксироваться для аналитики, но не должны автоматически менять детский рейтинг. Совместное задание должно знать и о родителе, и о профиле ребёнка, но начисление должно попадать в понятный продуктовый контекст.

В проекте Laravel выполняет роль источника данных и владельца бизнес-правил. Backend хранит профили родителей и детей, возрастные группы, районы, активности, результаты, историю начислений, расписание открытия контента, родительские материалы и онлайн-сессии. React-приложение получает эти данные через API и превращает их в пользовательский путь: выбор профиля, переход в район, выполнение задания, экран результата и обновлённый прогресс.

Критически важно не смешивать эти зоны. Клиент отвечает за быстрый и понятный опыт: анимацию, drag-and-drop, состояния загрузки, маршрутизацию и адаптацию интерфейса. Сервер отвечает за доступность, валидацию, хранение попыток, начисление баллов и данные для рейтинга. Когда правила кампании остаются на backend, они не становятся скрытой логикой браузера и не расходятся между устройствами.

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

Визуально лёгкая игровая платформа опирается на строгие границы ролей, данных и процессов. Для ребёнка это простой путь: выбрать героя, открыть район, пройти задание, увидеть результат. Для родителя — понятный инструмент, который объединяет несколько детских профилей и отдельный полезный контент. Для команды клиента — управляемая кампания, где жизненный цикл активности и данные поддержки не спрятаны в исходном коде.