advanceSecondsnumber
Перематывает на виртуальных часах вперёд на указанное количество игровых секунд (быстро в реальном времени; макссимум 300), трассируя readState на каждом тике.
hashstring
Хэш развертывания из deploy_game проверяет, что комната новая (развертывания симуляции выполняются в детерминированном пошаговом режиме).
inputobject
Сценарный ввод для страницы 0 (сокращённая запись для одной страницы).
inputsany[]
Вход на страницу для игроков: 2 - inputs[0] управляет страницей 0, inputs[1] - страницей 1 (страница 0 откатывается к input). Последовательности работают ПАРАЛЛЕЛЬНО на одних общих виртуальных часах, поэтому взаимодействия двух игроков (погоня, столкновение, ралли) можно описать скриптами.
playersnumber
1 (по умолчанию) или 2: две страницы в одной комнате для проверки синхронизации.
readStatestring[]
Пути: "state.<key…>" или "player.<id|self>.<key…>"; в SIM-комнатах также "sim.<schema path>" (прогнозируемое состояние) и "render.<schema path>" (сглаженное представление, которое рисует корректная игра; используйте для проверок движения/перелёта). "self" работает как сегмент player-id. Некорректные пути возвращают допустимые варианты.
roomstring
Код активной комнаты для проверки вместо создания новой.
sandboxboolean
Проверка без риска для счёта: комната захвата ранжирует вызовы submitScore на собственной временной локальной таблице лидеров и никогда не записывает в таблицу лидеров проекта. Используйте при доработке игры, чья ссылка для публикации уже открыта. Только новые комнаты (с hash, а не room).
screenshotboolean
По умолчанию true. Задайте false, чтобы пропустить образ (быстрее, только проверки).
screenshotAtMsnumber[]
Снимайте промежуточные скриншоты на этих ВИРТУАЛЬНЫХ ms-отметках (<=8; те же часы, что и virtualMs в ответе, - счётчики settle). Динамичные кадры снимайте в полёте, не подгоняя по времени весь захват под этот момент; каждый кадр попадает в пределы одного-двух кадров и сохраняется в players[i].screenshots.
settleMsnumber
Виртуальный бюджет загрузки перед зондированием (по умолчанию 3000).
simulateLatencyMsnumber
Односторонняя задержка на участке клиент↔сервер, в мс (заново генерируется через хэш; максимум 2000). РАБОТАЕТ НА ОБОИХ УРОВНЯХ: сим-комнаты получают её в точных тиках, классические комнаты получают каждый WebSocket-кадр, удерживаемый на виртуальных часах. ЗАПУСТИТЕ ЭТО: задержка 0 мс на петле - единственное условие, при котором в вашу игру никогда не будут играть по-настоящему, а на КЛАССИЧЕСКОМ уровне ВЫ отвечаете за компенсацию задержки, так что тестирование с 0 мс означает, что игра не протестирована. Попробуйте 150 (межконтинентальное соединение) и 250 (трансокеанское): состояние другого игрока приходит в 2 раза позже (два участка), так что при 150 вы смотрите на позиции, которым уже 300 мс. Если тела визуально отстают от того места, где должны быть, или предсказанный объект дёргается, вы отрисовываете устаревшее состояние вместо того, чтобы продвигать его вперёд. Помечайте отправляемое состояние меткой room.now() и при получении продвигайте его на величину возраста.
simulateLatencyTicksnumber
То же, что simulateLatencyMs, но точный, в тиках симуляции. Только для SIM-комнат (тикам нужен stepped runner); на классике используйте simulateLatencyMs.
traceSeriesboolean
Также возвращайте фактический временной ряд для каждого числового пути readState: параллельные массивы {t, v} (виртуальные миллисекунды, значение; не более 600 равномерно прореженных точек). Трейс агрегирует ответ «произошло ли когда-либо»; ряд отвечает «КОГДА именно» (где умер запуск, когда переключилась фаза).
urlParamsobject | object[]
Дополнительные параметры запроса для тестируемой страницы, например { "seed": "42" }, делают прогоны ДЕТЕРМИНИРОВАННЫМИ, если ваша игра их читает (в противном случае Math.random меняется от прогона к прогону). Один объект применяется ко всем страницам; МАССИВ (по одному объекту на страницу, как inputs) даёт каждой странице свой собственный: [{ name: "A", team: "red" }, { name: "B", team: "blue" }] при players: 2. Длина массива должна соответствовать players.
