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

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

Я отвечал за backend на Laravel: API, бизнес‑логику, профили, прогресс, начисления, админские процессы и интеграции. Пользовательский интерфейс делала отдельная frontend‑команда на React.

Главная задача была не в том, чтобы нарисовать карту с играми. Нужно было сделать так, чтобы все части продукта — детские профили, задания, календарь, баллы, рейтинг и админка — работали как одна система.

Почему «несколько игр на сайте» здесь не работают

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

  • какой профиль ребёнка выполнил задание;

  • доступно ли задание его возрастной группе;

  • открыто ли оно в этот день;

  • было ли прохождение засчитано раньше;

  • меняет ли результат баллы и рейтинг.

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

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

Один родитель, несколько детей

Самая важная модель продукта проста для пользователя, но требовательна для разработки: аккаунт принадлежит родителю, а прогресс — ребёнку.

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

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

Где проходит граница между React и Laravel

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

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

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

Робот как пример этой схемы

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

Симуляция живёт на клиенте: это даёт мгновенную реакцию, drag‑and‑drop и понятную обратную связь. Но победа на экране ещё не означает автоматическое начисление баллов.

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

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

Календарь кампании не должен жить в компонентах

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

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

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

Почему баллы нельзя хранить одним числом

Поле points показывает итог, но не объясняет его. Если пользователь или поддержка спрашивает, почему изменился рейтинг, нужна история: за какое действие начислены баллы, когда это произошло и не было ли повторного зачёта.

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

Родительские материалы и совместные сценарии тоже получают явные правила. Не каждое полезное действие родителя должно менять счёт ребёнка.

Админка — часть продукта, а не служебная страница

Контентная и операционная команда не должны обращаться к разработчику для каждого нового вопроса в квизе, даты открытия или слота онлайн‑сессии.

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

Админка не повторяет детский интерфейс. Она решает другую задачу: помогает вести продукт после запуска.

Что проверять до запуска

Главные ошибки обычно не видны на главном экране. Важнее проверить пограничные сценарии:

  • родитель переключил профиль в соседней вкладке;

  • задание закрылось, пока ребёнок был на его экране;

  • результат пришёл повторно;

  • контент опубликован с неполными данными;

  • начисления остановлены, но история должна остаться доступной.

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

Итог

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

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