Studio / ROBLOX
Тест сохранений Roblox в Studio: отдельная experience и проверка окружения
Готовим небольшой тест DataStore без обращения к рабочим сохранениям. Отличаем новую experience от нового place, проверяем доступ Studio и записываем условия чтения, записи и повторного запуска.
Отдели задачу теста от рабочей игры #
Для проверки сохранений выбери один простой вопрос: «Смогу ли я записать учебное значение и прочитать его в следующем тестовом запуске?» Не начинай с настоящего инвентаря или валюты игроков. Небольшой самостоятельный прототип позволяет разобраться в окружении и результатах операции, не смешивая их с магазином, наградами и миграцией данных.
В статье предлагается учебный прогресс без реального пользователя. Тестовая experience не создавалась, доступ к API не включался, чтений и записей DataStore не выполнялось. Пошаговый план предназначен для твоего отдельного прототипа. Он не подтверждает, что сохранения уже работают в наших опубликованных играх.
Пойми границу хранилища #
Data stores доступны разным places одной experience. Поэтому добавление ещё одного place внутрь рабочей игры само по себе не создаёт отдельное окружение сохранений. Название «Test» тоже не меняет эту границу. Сначала выясни, к какой experience относится открытый проект, а уже потом выбирай имена учебного store и ключа.
Для данного упражнения нужна отдельная тестовая experience. Другой store или ключ полезны для организации теста, но не заменяют проверку окружения: скрипт может использовать старое имя или другую ветку конфигурации. Наша схема различает две самостоятельные experience и несколько places внутри одной, а не изображает реальные идентификаторы аккаунта.
Открыть изображение крупнее ↗Создай небольшой самостоятельный проект #
Открой новый шаблон Baseplate в Studio, если тебе нужен минимальный прототип. Для первоначальной публикации документация описывает File → Publish to Roblox, заполнение данных в Publish Experience и Create. Выбирай создание самостоятельной тестовой игры; не заменяй рабочий place и не добавляй тест как новый place в существующую рабочую experience.
После создания проверь фактическую experience, владельца и доступ в Creator Dashboard. Публикация в облако и открытие игры всем игрокам — разные действия. Для этого упражнения не требуется публичный запуск. Если видишь другую игру или предложение перезаписать её место, вернись к выбору проекта вместо продолжения по привычке.
Сохрани паспорт окружения #
Запиши название и ID тестовой experience, имя или ID её place, владельца, назначение и дату проверки. Эти поля нужны для сравнения перед каждым запуском. Различай идентификатор всей experience и отдельного place: запись одного названия не доказывает, что два запуска используют одно и то же окружение.
Добавь к паспорту учебное имя store, например PracticeProgress_v1, и вымышленный ключ example_student_01. Это выбранные нами обозначения, не готовые записи Roblox и не реальные данные игрока. Не переносить настоящие сохранения в упражнение проще, чем потом пытаться выяснить, какие результаты появились от старых данных.
Открыть изображение крупнее ↗Рассмотри доступ Studio только для тестовой версии #
По умолчанию Studio не получает доступ к DataStore этой настройкой. Документация предупреждает: при доступе Studio используется то же хранилище, что и опубликованной игрой. Поэтому перед настройкой ещё раз сверь паспорт отдельной тестовой experience. Закрытость игры для публики сама по себе не отделяет Studio от её хранилища.
В опубликованной тестовой версии путь описан как File → Experience Settings → Security → Enable Studio Access to API Services, затем Save. Это изменение доступа к API-сервисам, а не создание отдельной копии данных. Для этого упражнения не включай его в рабочей игре. Если тестовое окружение ещё не подтверждено, сначала исправь выбор проекта.
Проверь серверный путь и конфигурацию #
DataStoreService используется серверным скриптом; попытка работы из LocalScript приводит к ошибке. Запиши путь скрипта и сторону выполнения до разбора чтения. Интерфейс может показывать статус загрузки, но надпись в клиентском окне не доказывает, что сервер обратился к нужному store и ключу.
Сверь конфигурацию чтения и записи: experience, store, ключ и ожидаемый формат должны соответствовать одному упражнению. Если в коде есть несколько имен хранилищ, найди фактически используемое, а не только похожую строку. Не меняй сразу серверную логику, интерфейс и имена: иначе станет трудно определить причину результата.
Различай пустую запись и ошибку чтения #
Обращения к DataStore могут завершаться ошибкой сети, поэтому документация использует pcall для обработки сбоев. Успешное чтение без сохранённого значения и неудавшийся запрос — разные исходы. До теста реши, как они будут отражены в журнале и интерфейсе. «Нет записи» нельзя назначать результатом запроса, который не выполнился.
Вымышленный сбой: загрузка не удалась, интерфейс показал ноль, а следующий шаг записал этот ноль как новый прогресс. Такой сценарий не проверяет исходные данные и может скрыть проблему. Отдели состояния «загружается», «учебной записи нет» и «чтение не удалось». Не запускай запись исходного значения только ради исчезновения сообщения об ошибке.
| Исход чтения | Следующий шаг |
|---|---|
| Значение прочитано | Сопоставить значение и формат |
| Запрос успешен, записи нет | Проверить учебный ключ и план записи |
| Запрос завершился ошибкой | Записать ошибку; не считать отсутствием данных |
Проведи одну контролируемую запись #
После проверки окружения, серверной стороны и успешного исходного чтения можно составить отдельный учебный шаг записи одного небольшого значения. Зафиксируй store, ключ, формат и результат операции. Пример значения должен соответствовать твоему прототипу, не представлять реальные деньги и не требовать очистки чужих ключей.
Затем сделай отдельный шаг чтения и сравни результат с ожидаемым учебным значением. Выбор способа записи зависит от логики; конфликты нескольких серверов требуют отдельного материала об UpdateAsync. В этой инструкции нет готового обработчика магазина или обещания успешного запроса. Не называй запись успешной по одному нажатию или по изменению подписи.
Повтори с новым тестовым запуском #
Заверши первую симуляцию и запусти следующий тест в той же подтверждённой тестовой experience. Снова сверь паспорт, store, ключ и формат, затем отдельный результат чтения. Изменение обычного объекта во время Studio-теста и запись через DataStore — разные механизмы; не делай вывод о сохранении по цвету или временной переменной.
Если значение отличается, сначала сравни условия и результаты запросов. Чтение также имеет особенности кэширования, описанные в справке; мгновенный повтор не заменяет понятный план проверки. Не переписывай рабочие сохранения ради совпадения результата. Запиши, что наблюдалось, и какое объяснение ещё нуждается в отдельном тесте.
Сохрани вывод и границы проверки #
В журнале нужны паспорт окружения, серверный путь, store, ключ, формат, операции и их исходы. Отдельно укажи, что реально подтвердилось: выбор тестовой experience, успешное чтение, запись или чтение в новом запуске. Эти пункты нельзя объединять в одно «всё работает», если какой-то шаг не выполнен.
После теста зафиксируй состояние настройки доступа и дальнейшее назначение тестовой версии. В этой статье не проверены нагрузка, два сервера, миграция формата или восстановление рабочих данных. Для них нужны отдельные сценарии. Схемы и таблицы — оригинальные учебные материалы; никаких действий с реальными сохранениями здесь не заявлено.
| Проверка | Что записать |
|---|---|
| Окружение | Отдельная experience и её ID |
| Контекст | Серверный путь скрипта |
| Данные | Учебные store, ключ и формат |
| Результат | Исход каждой операции |
Первоисточники
Roblox Creator Hub — Data storesRoblox Creator Hub — Publish experiences and places
