Studio / ROBLOX
Два игрока в Roblox Studio: как организовать проверку
Запустите учебную симуляцию с двумя клиентами и отделите наблюдения A, B и сервера. Исходное состояние, личный и общий результат, близкие действия, повтор, респавн и журнал без выдуманных итогов.
Открыть изображение крупнее ↗Один запуск, три точки наблюдения #
Два персонажа рядом ещё не означают проверенную многопользовательскую механику. Клиент A может видеть красивый результат, клиент B — прежний объект, а сервер — вовсе другое состояние. Этот гайд помогает организовать наблюдения, а не написать новую систему наград или универсальную защиту RemoteEvent.
Работайте с отдельной учебной копией своего проекта. Для первой проверки запуска подходит простая сцена с местом появления; поведение взаимодействия проверяют только если оно уже реализовано. Выберите один общий объект и один личный элемент интерфейса из своего прототипа, если они есть. Не добавляйте новое правило во время наблюдения. Ни Studio, ни пять игр автора для этой статьи не запускались: далее инструкции и незаполненные записи, а не результаты проведённого испытания.
1. Сначала составьте паспорт одного случая #
Запишите версию проекта, режим, два клиента, выбранный объект и условие готовности. Пример готовности: оба персонажа появились и могут двигаться, общий объект найден, нужная панель доступна. Определите исходное значение объекта по своей реализации и положение A/B. Если оно неизвестно, сначала выясните его, а не называйте любой увиденный цвет правильным.
Разделите ожидаемое и наблюдаемое. «A меняет общий объект; B видит изменение» — требование, не доказательство. Личная справка A может оставаться только у A; это тоже нужно заранее выбрать. Укажите допустимый повтор и способ вернуть исходное состояние. Для первого прохода достаточно одного действия. Несколько одновременно меняющихся меню, предметов и заданий мешают понять источник расхождения. Таблицы ниже помогают передать план другому разработчику без догадок.
2. Выберите подходящий режим, не подменяя цель #
Одиночный Test/F5 добавляет персонажа; Run/F8 запускает сцену без него. Проверка двумя клиентами требует режима Server & Clients. В актуальной справке выбор режимов расположен в левой части полосы управления тестированием, названной mezzanine. Не ищите старую вкладку по случайной инструкции, если ваша версия показывает другой интерфейс.
Одиночная проверка полезна для короткого осмотра готовности, но переключение Client/Server в ней не создаёт второго игрока. Оно меняет сторону наблюдения одного теста. Team Test относится к совместной работе участников и не нужен для нашей локальной схемы двух клиентов. Здесь задача — получить две клиентские точки зрения и сервер, затем сравнить один сценарий. Таблица режимов показывает узкую цель выбора, без заявления, что какой-либо режим уже доказал качество вашей игры.
| Режим | Что проверяет этот проход | Граница |
|---|---|---|
| Test / F5 | Одиночная готовность с персонажем | Второй игрок не появляется |
| Client / Server в одиночном тесте | Две стороны того же одиночного запуска | Не две независимые клиентские сессии |
| Run / F8 | Запуск сцены без персонажа | Не заменяет действия двух игроков |
| Server & Clients · 2 · Play/F7 | Два клиента и сервер для журнала A/B/S | Локальная симуляция, не публичная игра |
3. Запустите именно два клиента #
В выпадающем выборе укажите Server & Clients, задайте количество клиентов 2 и нажмите Play либо F7. Документация описывает отдельные сессии Studio для сервера и клиентов. Дождитесь готовности запуска, прежде чем выполнять действие. Не считайте исходное окно редактирования дополнительным игроком и не ориентируйтесь только на число окон на рабочем столе.
Обозначьте клиентские сессии A и B в своих записях, сервер — S. Сверьте, кто управляется в каждом клиенте; на сервере проверьте два Player в Players. Если служба не видна в Explorer, воспользуйтесь Show Services… в его контекстном меню. Имена тестовых игроков записывайте такими, какие они появились, без обещания Player1/Player2 или реальных учётных записей. При неполном запуске сначала восстановите состав теста, затем начинайте сценарий.
4. Настройте наблюдение, а не новый код #
Откройте Explorer и Output через Window; актуальная справка также указывает отдельные кнопки этих окон на соответствующих панелях. Explorer нужен для конкретного объекта и его значений, Output — для ошибок и уже существующих сообщений. В Output полезны Show Context, Show Timestamp и при необходимости Show Source. Не добавляйте новый скрипт только ради прохождения этого гайда.
Для каждой записи указывайте сторону: A, B или S. LocalPlayer относится к конкретному клиенту, а сервер работает с игроками сеанса, поэтому слово «игрок» без роли слишком расплывчато. Не скрывайте ошибку фильтром перед сохранением наблюдения. Отсутствие сообщения в Output не доказывает отсутствия операции: прототип мог ничего не печатать. Если данных недостаточно, так и запишите, а отдельное диагностическое изменение обсуждайте после исходного прогона.
5. Зафиксируйте исходное состояние на всех сторонах #
До первого действия снимите три отдельные записи. A: положение персонажа, видимый объект, состояние личной панели. B: те же сведения со своей стороны. S: нужный объект и серверное значение, состав Players, доступный журнал. Не подставляйте серверное значение в колонку B вместо реального наблюдения B.
Общий результат и одинаковая картинка не всегда совпадают. Камера, интерфейс или доступность области могут отличаться. В проекте со streaming отсутствие далёкого объекта у клиента не сразу означает сбой: область наблюдения нужно подготовить одинаково. Для первого сравнения поставьте обоих рядом с выбранным объектом и запишите, что действительно доступно. Не двигайте объект в серверном Explorer для получения желаемой картинки в середине проверки: такое вмешательство станет отдельным случаем с другим исходным состоянием.
Открыть изображение крупнее ↗6. Проверьте действия по очереди #
Пусть A выполнит одно заранее выбранное действие, а B пока только наблюдает. Запишите реакцию интерфейса A, серверное состояние и видимый результат B. Затем остановитесь и сравните их с требованием. Не исправляйте код до записи расхождения: иначе получится наблюдение от одной версии и вывод от другой.
Верните известное исходное состояние выбранным в плане способом или начните новую сессию для чистого сценария. Теперь B действует, A наблюдает. Это помогает заметить зависимость от первого игрока, роли или положения. Личную панель проверяют отдельно: открытие справки A не должно считаться общим изменением, если правило панели локальное. У другого проекта может быть другое правило; именно поэтому паспорт нужен до теста. Успех одного направления A→B не заменяет обратную проверку B→A.
7. Близкие действия описывают точнее, чем «одновременно» #
После последовательного прохода подготовьте обоих к одному объекту. Выполните действие A, затем быстро действие B и запишите порядок ввода. Повторите с обратным порядком после возврата исходного состояния. Оператор, переключающий окна мышью, не гарантирует один и тот же момент обработки на сервере. Поэтому запись «почти вместе, A первым» честнее слова «одновременно» без подтверждения.
Заранее выберите ожидаемое правило конфликтов своей механики: очередь, отказ второму или другой явный результат. Гайд не задаёт его за вас. Сравните итог S и сообщения обоих клиентов. Второе действие может законно поменять общий объект после первого; это не автоматически ошибка первого игрока. Для проверки строгого одновременного запроса требуется отдельный управляемый сценарий. Ручная смена двух окон не доказывает защиту всех гонок.
8. Поздний ответ и повтор — отдельные случаи #
Запишите, что A делает, пока ждёт результат, и что B видит в этот момент. Если A нажимает повторно, сопоставьте действие с конкретным ответом или имеющимся идентификатором. Поздняя обратная связь не должна молча заменять сообщение другого нового действия. Но отсутствие ответа само не говорит, завершилась ли операция: различайте неизвестное состояние и подтверждённый отказ.
Для управляемого задержанного случая используйте Network Simulator только отдельным проходом, записав настройки обоих направлений. Это beta-инструмент Studio: доступность проверяют по текущей справке, соединения опубликованной игры он не меняет. Выбор пресета ещё не применяет параметры; нужен Apply. Медленное переключение окон не воспроизводит сетевую задержку. После случая восстановите и примените записанные базовые параметры; Reset подготавливает Ideal Fiber, а не нулевую задержку. Если запрос и результат нельзя сопоставить, отметьте ограничение наблюдения вместо обещания безопасного повтора.
9. Респавн проверяют внутри той же сессии #
После понятного исходного прохода перезапустите персонажа A предусмотренным способом своего учебного проекта. Запишите, что изменилось у A, что видит B и что осталось на S. Появление нового Character не равно присоединению нового Player. CharacterAdded связан с появлением или возрождением персонажа; это не готовая гарантия сохранности панелей, задач или игрового состояния.
Перед новым действием дождитесь условия готовности заново. Старые ссылки на персонажа или локальные элементы могут нуждаться в обновлении по реализации. Здесь мы ничего не исправляем и не добавляем код: фиксируем явный случай для разработчика. Не называйте повторное появление «новым входом» и не подменяйте его полной остановкой теста. Если проект отключает обычное появление персонажей, используйте его действующий механизм, а не обещание автоматического респавна для каждой игры.
10. Завершение теста и сохранение — разные операции #
Когда записи сделаны, для Server & Clients используйте End Session из любой сессии симуляции: закрываются клиентские и серверная сессии. Одиночный Stop останавливает свою симуляцию и возвращает объекты к состоянию до теста. Не считайте закрытие одного окна или паузу универсальным завершением всей проверки.
Вернитесь к исходному проекту редактирования; для локальной копии используйте File → Save to File, если меняли авторские материалы. Это не сохранение игрового прогресса. Изменение мира в тесте не становится автоматически правкой файла. Новый запуск требует новой записи исходного состояния. Если прототип использует внешнее сохранение, перезапуск сам не обещает чистые данные: это отдельная область проверки. Журнал наблюдений храните отдельно от проекта, чтобы после остановки не потерять порядок действий и контекст.
11. Передайте воспроизводимый результат с границами #
Хорошая запись содержит версию, состав клиентов, исходное состояние, точный ввод, роли A/B/S, ожидание и фактическое наблюдение. При расхождении приложите доступную ошибку с контекстом и укажите, повторилось ли оно после того же старта. Слово «работает» без этих условий не позволяет другому человеку повторить проверку.
Материал проверен по официальным источникам; схемы и таблицы — наши, не снимки Studio. Реального запуска по этому гайду не проводилось. Локальная симуляция не доказывает работу на телефоне, поведение публичного сервера или все сетевые условия. После исправления повторяют именно проблемный случай и связанный исходный проход. Затем планируют реальные устройства и требуемую среду отдельным этапом. Такой небольшой журнал делает две клиентские точки зрения полезными, а не просто добавляет ещё два окна на экран.
| Случай / ввод | Заранее выбранный критерий | A: наблюдение | B: наблюдение | S: наблюдение |
|---|---|---|---|---|
| Исходный старт: оба готовы | Записать реальную доступность и значение, сравнить с паспортом | — | — | — |
| A действует, B наблюдает | Изменения согласно общему правилу; раздельные наблюдения | — | — | — |
| B действует, A наблюдает после восстановления | Та же проверка при смене инициатора | — | — | — |
| A открывает личную панель, если она есть | Если правило локальное, панель B не открывается | — | — | — |
| Быстро A → B, затем отдельный B → A | Записать порядок; сравнить с выбранной политикой конфликта | — | — | — |
| Повтор и поздний ответ: отдельный проход | Сопоставить запрос/результат, не затереть другую новую операцию | — | — | — |
| Респавн A в текущем сеансе | Проверить готовность, Character и требуемое состояние | — | — | — |
| End Session и новый запуск | Новая запись состава и исходных значений; не предполагать чистые внешние данные | — | — | — |
Первоисточники
Roblox Creator Hub — Studio testing modesRoblox Creator Hub — Client-server runtime
Roblox Creator Hub — Players
Roblox Creator Hub — Player
Roblox Creator Hub — Explorer
Roblox Creator Hub — Output
Roblox Creator Hub — Network Simulator
Roblox Creator Hub — Place files
