Разработка / ROBLOX
ProximityPrompt в Roblox: когда сервер должен разрешить взаимодействие
Разбери дверь с подсказкой: показ кнопки, событие и разрешённое изменение — отдельные шаги. Подготовь проверки персонажа, объекта, расстояния и повторных действий с понятным журналом теста.
Сначала опиши одно разрешённое действие #
Возьми небольшой самостоятельный прототип с дверью PracticeDoor. Для первого упражнения достаточно разрешённого открытия и записи результата. Убери из задачи валюту, инвентарь и постоянное сохранение: иначе трудно понять, какой именно шаг изменил состояние. Напиши обычным предложением, кто может открыть дверь и при каких условиях.
Например, твой проект допускает живого персонажа рядом с доступной дверью после получения учебного разрешения. Это выбранное правило упражнения, а не стандарт всех Roblox-игр. В статье нет запуска Studio или испытания опубликованной игры. Мы составляем план, по которому автор проверяет свой обработчик, и не заявляем полученные результаты.
Отдели подсказку от решения #
Игрок видит надпись и кнопку, затем пытается взаимодействовать. Эти элементы помогают понять управление. Они не описывают полностью текущее серверное состояние двери, персонажа или доступа. Если надпись осталась на экране после изменения условий, из неё нельзя вывести право на открытие.
Удобно нарисовать три ступени: интерфейс предлагает действие, событие сообщает о попытке, сервер проверяет правила и меняет объект. На схеме последняя ступень включает и отказ. Тогда вопрос при ошибке звучит точнее: «Почему сервер отклонил действие?» или «Почему изменение прошло без выполненного условия?», вместо общего «кнопка сломалась».
Открыть изображение крупнее ↗Выбери событие с точным смыслом #
У ProximityPrompt несколько событий. Документация безопасности отдельно указывает встроенную серверную проверку расстояния для Triggered. Не переноси это свойство на PromptButtonHoldBegan или TriggerEnded. Разные этапы взаимодействия нельзя считать одинаковыми основаниями для изменения игрового состояния.
Для учебной двери зафиксируй событие, которое получает обработчик, и момент принятия решения. Не выдавай награду только потому, что появился интерфейс или началось удержание. Даже при Triggered серверу нужны остальные правила твоей механики: допустимый персонаж, доступный объект и требуемое состояние. Эта статья не предлагает готовый обработчик для всех типов взаимодействий.
Составь серверный паспорт объекта #
Запиши, какой объект считается дверью, где он должен находиться и какая серверная ссылка используется. Имя PracticeDoor здесь условное. Одинаковое название у другой части не делает её разрешённой целью. Если объект удалён или перемещён из ожидаемой структуры, предусмотренный сценарий должен завершиться без изменения посторонних объектов.
Отдельно укажи доступность двери и условие допуска. Условием может быть учебный флаг, которым управляет сервер прототипа; не нужно сразу строить платный доступ. Для теста важно понимать, откуда берётся разрешение и что будет при его отсутствии. Запиши исходное состояние перед каждым случаем, чтобы старый результат не выглядел новым успешным открытием.
Проверь персонажа и зону действия #
Перед изменением двери нужно определить актуального персонажа и пригодность к этому действию по серверным данным. Во время возрождения или выхода из игры прежняя ссылка может уже не соответствовать текущему состоянию. Продумай отдельно отсутствие персонажа и персонажа, который по правилам прототипа не может взаимодействовать.
Опиши свою зону допуска: точку отсчёта, способ сравнения и выбранную границу. Нет одного числа расстояния для всех карт. Для проверок подготовь очевидно близкую и очевидно далёкую позицию, затем пограничный случай. Не делай вывод о корректности по одному удачному нажатию рядом; он ничего не говорит о недопустимом расстоянии или сменившемся персонаже.
Учитывай неподвижную точку взаимодействия #
Если критичная точка должна стоять на месте, спроектируй её как неподвижную anchored-часть. Документация предупреждает о влиянии network ownership на подвижные родительские части и сборки. Проверять расстояние до объекта, который можно переместить, — другой сценарий, чем проверять стационарную дверь.
В первом упражнении держи геометрию простой и записывай положение точки. Подвижный сундук или транспорт не нужно автоматически исправлять закреплением всего объекта: такая механика требует отдельного решения об управлении физикой. Здесь мы выбираем неподвижную дверь, чтобы отделить разрешение взаимодействия от сложного поведения сборки, и не испытываем network ownership в живой игре.
Раздели частоту и длительность #
Быстро повторяемое обращение и слишком быстро завершённое удержание — разные вопросы. Для повторов сервер применяет выбранное правило частоты. Если действие требует минимальной длительности, проверять нужно именно соответствующее серверное условие; клиентская анимация заполнения не доказывает, что оно выполнено.
Запиши правила до теста, включая разрешённый повтор после паузы и смысл отмены. Не называй cooldown гарантией единственной выдачи: он ограничивает частоту, но не заменяет переход состояния или учёт уже принятого действия. Для простой двери реши, что означает повторное открытие открытой двери. В этой инструкции нет универсальных чисел времени и нет готовой реализации удержания.
Пройди матрицу отдельных случаев #
Сначала проверь ожидаемый допустимый случай в своём прототипе, затем меняй по одному условию: расстояние, наличие разрешения, доступность двери или состояние персонажа. Для каждого случая сохрани состояние до попытки и после неё. Так результат связывается с одной причиной, а не с несколькими одновременно изменёнными настройками.
После одиночных случаев отдельно запланируй повторное обращение и два допустимых обращения рядом по времени. Если механика однократная, заранее определи, какое изменение можно принять один раз. Эти сценарии остаются задачами автора; таблица показывает предложенные ожидания, а не реально проведённые испытания. Не вызывай события чужих игр для проверки этой инструкции.
Открыть изображение крупнее ↗| Случай | Предлагаемое ожидание |
|---|---|
| Допустимый близкий персонаж | Одно предусмотренное действие |
| Нет разрешения | Нет изменения |
| Дверь недоступна | Нет изменения |
| Слишком быстрый повтор | Применить серверное правило частоты |
Записывай серверный исход понятно #
В журнале нужны условия, полученное событие, причина отказа или принятия и фактическое изменение двери. Клиент может показывать полезное сообщение о недоступности, но журнал проверки должен отличать его от серверного результата. Надпись «открыто» при неизменной двери сама по себе ничего не подтверждает.
Используй короткие понятные причины: объект недоступен, персонаж не подходит, слишком далеко, нет разрешения, слишком частый повтор. Не включай в публичное сообщение внутренние секреты проекта. Для отладки достаточно связать случай с нужным шагом правила. Отдельно отметь, если сервер принял попытку, но дальнейшее действие завершилось ошибкой: это уже другой этап.
Зафиксируй границы вывода #
Итог упражнения — проверяемое правило взаимодействия и журнал собственных наблюдений. После его выполнения можно сказать, какие случаи действительно прошли, какие требуют исправления и какие ещё не испытаны. Нельзя назвать дверь полностью защищённой по одному нормальному открытию или по отсутствию видимой ошибки в интерфейсе.
Награды, покупки, сохранение и несколько серверов требуют дополнительных сценариев. В этих материалах нет изменений кода наших игр, настоящей выдачи предметов или результатов теста Studio. Схемы — оригинальные объяснения принятия решения и записи условий. Перед переносом правила в большой проект проверь связи с его собственной логикой и поведение повторов.
| Запись | Что сохранить |
|---|---|
| Начало | Персонаж, дверь и условия |
| Событие | Точное имя и контекст |
| Решение | Причина принятия или отказа |
| Изменение | Фактическое состояние до и после |
Первоисточники
Roblox Creator Hub — Securing the client-server boundaryRoblox Creator Hub — ProximityPrompt API
