Studio / ROBLOX
Как проверить первый уровень в Roblox Studio: план тестирования
Пошаговая проверка появления, маршрута, столкновений, интерфейса и второго игрока. С шаблоном отчёта, таблицей проверок и двумя схемами.
Что именно мы проверяем #
Этот план подходит для небольшого учебного уровня, где персонаж появляется, проходит маршрут и достигает цели. Мы не пытаемся проверить сразу все возможные функции Roblox. Сначала нужно описать основное действие и признаки успешного результата. Для трассы это может быть проход от начала до финиша без застревания и неожиданного падения.
Сохраните исходную версию проекта и выпишите три вещи: где должен появиться персонаж, какой путь считается допустимым и как распознаётся конец. Если есть контрольные точки, отдельно опишите возврат после падения. Так вы проверите намеренное поведение, а не просто посмотрите, запускается ли сцена.
1. Выберите подходящий режим запуска #
Для проверки появления и движения нужен тест с персонажем. В текущей документации Studio режим Test запускает симуляцию с аватаром. Test Here начинает у положения камеры, поэтому он удобен для проверки конкретного участка, но не заменяет проверку настоящего старта. Run запускает симуляцию без аватара.
Начните с Test и пройдите с исходной точки. Затем используйте Test Here для неудобного участка, который долго достигать. Записывайте использованный режим: ошибка появления может исчезнуть, если вы каждый раз стартуете непосредственно у финиша. Названия и расположение инструментов сверяйте с текущей версией Studio.
2. Пройдите маршрут обычным способом #
Не перемещайте персонажа средствами редактора при основной проверке. Идите так, как предполагается в игре: поворачивайте камеру, обходите препятствие, подходите к краю и финишу. Проверьте обе стороны барьера, если они выглядят доступными. Для сцены из первого урока сверяйте TrainingSpawn, Barrier и Goal со схемой.
Отмечайте точное место проблемы: «между Barrier и краем пола», а не «движение странное». Если часть падает, проверьте Anchored; если персонаж проходит сквозь неё — CanCollide. Это первые диагностические проверки, а не универсальное объяснение любого сбоя.
3. Проверьте повторение и восстановление #
Остановите тест и начните снова с исходного положения. Повторный запуск помогает отличить постоянную проблему от единичного наблюдения. Затем проверьте предусмотренное вашей игрой восстановление: например, возвращение после падения. Не приписывайте сцене контрольные точки, если вы их ещё не создали.
Запишите ожидаемое и фактическое поведение рядом. Если персонаж должен вернуться на последнюю достигнутую платформу, а возвращается на старт, это конкретное расхождение. Для учебной сцены без механики прогресса достаточно проверить начальное появление и доступность маршрута после нового запуска.
4. Просмотрите Output и сохраните сведения #
Откройте Output и проверьте ошибки, предупреждения и собственные диагностические сообщения. Для каждой проблемы сохраните точный текст, имя скрипта и номер строки, если они доступны. Убедитесь, что фильтр не скрывает нужный тип сообщений или серверный контекст.
Сообщение в журнале и наблюдаемая ошибка могут быть связаны, но не считайте связь доказанной автоматически. Запишите действия, после которых возникли оба события. Исправив код, повторите те же действия. Исчезновение красного сообщения само по себе ещё не означает, что путь стал проходимым.
5. Если есть взаимодействие игроков #
Для механики с общими объектами используйте Server & Clients и начните с двух клиентов. Проверьте действие первого игрока глазами второго: видит ли он результат, получает ли правильные сообщения и не меняется ли его собственное состояние ошибочно. В конце завершите тестовую сессию.
Например, личная контрольная точка одного игрока не должна самопроизвольно становиться точкой другого, если такой общий прогресс не задуман. Это пример проверки, а не утверждение о вашем проекте. Два локальных клиента полезны для поиска ошибок, но не доказывают производительность под реальной большой нагрузкой.
6. Проверьте небольшой экран #
Если рассчитываете на мобильных игроков, используйте Device Simulator для проверки экрана и управления. Посмотрите, не перекрывает ли большая надпись цель, видны ли кнопки и можно ли выполнить основное действие. Одна удобная раскладка на компьютере не подтверждает удобство на телефоне.
Эмуляция помогает обнаружить проблемы, но не заменяет проверку на реальном устройстве. Если телефона для теста нет, так и запишите в отчёте. Не ставьте отметку «мобильная версия проверена», когда смотрели только обычное окно редактора. Фиксируйте размер или профиль устройства, чтобы повторить условия.
7. Заполните таблицу и решите, что исправлять #
Пройдите проверки из таблицы и поставьте для каждой свой статус: работает, ошибка или не проверено. Не отмечайте отсутствующую механику как успешную: напишите «не предусмотрено». Шаблон помогает увидеть пробелы и повторить проверку после изменения.
Сначала исправьте проблемы, мешающие начать или завершить основное действие. Затем займитесь читаемостью пути и удобством интерфейса. Сохраните рабочую версию перед следующей правкой. Новый запуск должен отвечать на конкретный вопрос, например «может ли персонаж пройти справа после расширения прохода?».
| Проверка | Что считать ожидаемым результатом |
|---|---|
| Появление | Персонаж появляется в предусмотренном месте |
| Основной путь | Можно дойти от старта до цели обычным управлением |
| Края и препятствия | Нет непредусмотренного застревания или проваливания |
| Возврат после падения | Соответствует реализованным правилам проекта |
| Повторный запуск | Основной путь остаётся работоспособным |
| Output | Ошибки разобраны; фильтры не скрывают сообщения |
| Второй игрок | Личные и общие изменения разделены как задумано |
| Мобильный экран | Основное действие и кнопки доступны |
| Сохранённая версия | Нужная копия открывается с ожидаемыми объектами |
Шаблон полезного сообщения об ошибке #
Опишите проблему по схеме: версия проекта; режим теста; исходное положение; последовательность действий; ожидаемый результат; фактический результат; текст Output; повторяется ли ошибка. Например: «Test, появление на TrainingSpawn, движение вправо вокруг Barrier; ожидал пройти к Goal, персонаж застрял у края; повторилось дважды».
Такой отчёт можно использовать самому или передать помощнику без долгих уточнений. После исправления повторите исходные шаги и отметьте результат. Даже подробная проверка прототипа не подтверждает готовность всех остальных систем игры: публикацию и доступ игроков проверяют отдельно в актуальных настройках.
Первоисточники
Roblox Creator HubRoblox Creator Hub: Output
Roblox Creator Hub: Parts
