Entwicklung / ROBLOX
ProximityPrompt in Roblox: wann der Server eine Interaktion erlauben darf
Verfolge eine Übungstür vom sichtbaren Hinweis bis zur erlaubten Zustandsänderung. Plane Prüfungen für Figur, Ziel, Entfernung und Wiederholungen und dokumentiere die Testbedingungen verständlich.
Zuerst eine erlaubte Handlung bestimmen #
Verwende einen kleinen eigenständigen Prototyp mit einer Tür namens PracticeDoor. Für die erste Übung reichen eine erlaubte Öffnung und ein protokolliertes Ergebnis. Währung, Inventar und dauerhaftes Speichern bleiben zunächst außerhalb der Aufgabe. So kannst du erkennen, welcher Schritt den Zustand geändert hat. Beschreibe in einem einfachen Satz, wer die Tür unter welchen Bedingungen öffnen darf.
Deine Übungsregel könnte eine lebende Figur in der Nähe einer verfügbaren Tür mit einer zuvor erteilten Erlaubnis vorsehen. Das ist eine gewählte Projektregel, kein allgemeiner Roblox-Standard. Für diesen Artikel wurde weder Studio gestartet noch ein veröffentlichtes Spiel getestet. Die Anleitung schlägt einen Prüfplan für den eigenen Handler vor und behauptet keine ausgeführten Versuche.
Hinweis und Entscheidung trennen #
Die Figur sieht eine Beschriftung und eine Taste, bevor sie eine Interaktion versucht. Diese Elemente erklären die Bedienung. Sie bilden den aktuellen Serverzustand von Tür, Figur und Erlaubnis nicht vollständig ab. Bleibt der Hinweis nach einer Zustandsänderung sichtbar, beweist er keine weiterhin bestehende Berechtigung.
Zeichne drei Schritte: Die Oberfläche bietet eine Handlung an, ein Ereignis meldet einen Versuch, der Server prüft die Regel vor der Zieländerung. Auch eine Ablehnung gehört zum letzten Schritt. Damit werden Fragen genauer: Warum wurde der Versuch abgelehnt? Warum erfolgte eine Änderung ohne erfüllte Bedingung? Nicht jedes Problem muss als defekte Taste behandelt werden.
Bild in voller Größe öffnen ↗Das Ereignis genau benennen #
ProximityPrompt besitzt mehrere Ereignisse. Die Sicherheitsdokumentation nennt ausdrücklich die eingebaute serverseitige Entfernungsprüfung bei Triggered. Übertrage diese Eigenschaft nicht auf PromptButtonHoldBegan oder TriggerEnded. Verschiedene Phasen einer Interaktion sind keine austauschbaren Gründe für eine Änderung des Spielzustands.
Notiere für die Übungstür, welches Ereignis der Handler empfängt und wann die Entscheidung fällt. Ein eingeblendeter Hinweis oder der Beginn des Haltens darf allein keine Belohnung auslösen. Auch bei Triggered bleiben die übrigen Regeln wichtig: passende Figur, verfügbares Ziel und erforderlicher Zustand. Diese Anleitung enthält keinen universellen Handler für alle Interaktionsformen.
Das Ziel auf dem Server beschreiben #
Halte die vorgesehene Tür, ihren erwarteten Ort und die verwendete Serverreferenz fest. PracticeDoor ist nur ein Beispielname. Ein anderes Teil mit demselben Namen wird dadurch nicht zur erlaubten Zielinstanz. Verschwindet die Tür oder verlässt sie die erwartete Struktur, soll der geplante Vorgang ohne Änderung fremder Objekte enden.
Beschreibe Verfügbarkeit und Erlaubnisbedingung getrennt. Eine vom Prototypserver verwaltete Übungsfreigabe genügt; ein bezahlter Zugang ist für diese Aufgabe unnötig. Entscheidend ist, woher die Freigabe kommt und was bei ihrem Fehlen geschieht. Erfasse vor jedem Fall den Ausgangszustand, damit eine frühere Öffnung nicht wie ein neuer Erfolg aussieht.
Figur und Interaktionsbereich prüfen #
Vor einer Türänderung müssen aktuelle Figur und Handlungsmöglichkeit anhand der Serverdaten feststehen. Beim Respawn oder Verlassen kann eine frühere Referenz den gegenwärtigen Zustand nicht mehr beschreiben. Plane fehlende Figuren und Figuren, die nach deiner Regel nicht interagieren dürfen, als eigene Fälle.
Definiere den Bereich mit Bezugspunkt, Vergleich und ausgewählter Grenze. Keine Entfernung passt zu allen Karten. Bereite eine eindeutig nahe und eine eindeutig ferne Position sowie anschließend einen Grenzfall vor. Eine erfolgreiche nahe Interaktion sagt wenig über zu große Entfernung oder eine inzwischen veränderte Figur aus und beendet deshalb nicht den Prüfplan.
Einen festen Interaktionspunkt berücksichtigen #
Soll der wichtige Interaktionspunkt am Ort bleiben, entwirf ihn als verankertes Teil mit Anchored. Die Dokumentation weist bei beweglichen übergeordneten Teilen und Baugruppen auf network ownership hin. Eine Entfernung zu einem bewegbaren Ziel zu prüfen ist ein anderer Fall als die Entfernung zu einer stationären Tür.
Halte die Geometrie der ersten Übung einfach und notiere die Position des Punktes. Eine bewegliche Truhe oder ein Fahrzeug darf nicht pauschal durch Verankern der gesamten Baugruppe geändert werden; dafür ist ein eigener Physikplan nötig. Wir wählen hier eine stationäre Übungstür, um Berechtigungen vom Baugruppenverhalten zu trennen. Es wurde kein Ownership-Versuch in einem laufenden Spiel ausgeführt.
Häufigkeit und Dauer unterscheiden #
Wiederholte Versuche und eine zu schnell abgeschlossene Interaktion stellen unterschiedliche Fragen. Für Wiederholungen setzt der Server die gewählte Häufigkeitsregel durch. Benötigt die Handlung eine Mindestdauer, muss die entsprechende Serverbedingung geprüft werden. Ein Fortschrittskreis auf dem Client beweist diese Dauer nicht.
Schreibe die Regeln vor dem Test auf, einschließlich eines zulässigen neuen Versuchs nach einer Pause und der Bedeutung eines Abbruchs. Ein Cooldown garantiert keine einmalige Ausgabe: Er ersetzt weder Zustandsübergänge noch die Erfassung einer bereits angenommenen Handlung. Entscheide bei der Tür, was ein weiterer Öffnungsversuch im offenen Zustand bedeutet. Hier werden keine allgemeinen Zeitwerte oder fertige Haltefunktionen angeboten.
Einzelne Fälle durchgehen #
Beginne im eigenen Prototyp mit dem vorgesehenen erlaubten Fall und ändere danach jeweils eine Bedingung: Entfernung, Freigabe, Verfügbarkeit oder Figurenzustand. Erfasse den Zustand vor und nach jedem Versuch. Das verbindet ein Ergebnis mit einer Ursache statt mit mehreren gleichzeitig geänderten Einstellungen.
Plane anschließend eine Wiederholung und zwei zeitlich nahe erlaubte Versuche separat. Für eine einmalige Mechanik muss vorher feststehen, welche Änderung genau einmal angenommen werden darf. Die Tabelle enthält vorgeschlagene Erwartungen, keine ausgeführten Tests. Diese Aufgaben betreffen den eigenen Prototyp; zum Prüfen dieses Artikels sollen keine Ereignisse fremder Spiele ausgelöst werden.
Bild in voller Größe öffnen ↗| Fall | Vorgeschlagene Erwartung |
|---|---|
| Geeignete nahe Figur | Eine vorgesehene Handlung |
| Freigabe fehlt | Keine Änderung |
| Tür nicht verfügbar | Keine Änderung |
| Wiederholung zu schnell | Häufigkeitsregel des Servers anwenden |
Das Serverergebnis verständlich notieren #
Das Protokoll braucht Ausgangsbedingungen, empfangenes Ereignis, Annahme- oder Ablehnungsgrund und tatsächliche Türänderung. Eine Clientmeldung kann erklären, dass die Tür nicht verfügbar ist. Das Prüfprotokoll muss diese Anzeige vom Serverergebnis unterscheiden. Eine Aufschrift „offen“ beweist bei unveränderter Tür keine Öffnung.
Nutze kurze Gründe wie Ziel nicht verfügbar, Figur ungeeignet, zu weit entfernt, Freigabe fehlt oder Wiederholung zu schnell. Öffentliche Meldungen müssen keine internen Geheimnisse zeigen. Für die Fehlersuche genügt eine Zuordnung zum relevanten Regelschritt. Kennzeichne außerdem angenommene Versuche, deren anschließende Ausführung fehlschlägt: Entscheidung und Ausführung sind unterschiedliche Phasen.
Die Aussage begrenzen #
Das Ergebnis der Übung soll eine prüfbare Interaktionsregel und ein eigenes Beobachtungsprotokoll sein. Nach der tatsächlichen Durchführung unterscheidest du bestandene, fehlerhafte und noch ungeprüfte Fälle. Eine normale Öffnung oder eine Oberfläche ohne sichtbaren Fehler beweist keine vollständig geschützte Mechanik.
Belohnungen, Käufe, Speicherung und mehrere Server benötigen zusätzliche Szenarien. Dieser Artikel enthält keine Änderung unseres Spielcodes, wirkliche Gegenstandsausgaben oder Studio-Ergebnisse. Die eigenen Zeichnungen erklären Entscheidungsschritte und Bedingungsprotokolle. Vor dem Übertragen in ein größeres Projekt müssen Verbindungen zu dessen Logik und Wiederholungsverhalten geprüft werden.
| Protokoll | Festhalten |
|---|---|
| Start | Figur, Tür und Bedingungen |
| Ereignis | Genauer Name und Kontext |
| Entscheidung | Grund für Annahme oder Ablehnung |
| Änderung | Tatsächlicher Zustand vorher und nachher |
Originalquellen
Roblox Creator Hub — Securing the client-server boundaryRoblox Creator Hub — ProximityPrompt API
