Für viele Entwickler besteht die grundlegende Herausforderung bei der Anpassung an das Skripting in Roblox darin, wie wichtig der Speicherort von Dateien und die Script.RunContext-Eigenschaft sind. Je nach Skripttyp, Standort im Explorer und Ausführungskontext können Skripte sehr unterschiedlich funktionieren. Bestimmte Methodenaufrufe könnten fehlschlagen, Objekte in Ihrem Spiel könnten unzugänglich sein, oder Skripte könnten überhaupt nicht ausgeführt werden.
Der Grund für diese Komplexität ist, dass Roblox-Spiele standardmäßig für mehrere Spieler konzipiert sind. Skripte müssen die Fähigkeit haben, nur auf dem Server, nur auf dem Client oder zwischen beiden geteilt zu werden. Die Evolution der Roblox-Plattform im Laufe der Zeit hat die Situation weiter kompliziert.
Skripttypen
Roblox hat drei Typen von Skripten:
- Script - Code, der entweder auf dem Server oder dem Client ausgeführt wird, abhängig von seinem Standort und der Script.RunContext-Eigenschaft.
- LocalScript - Code, der nur auf dem Client ausgeführt wird. Hat keinen Ausführungskontext.
- ModuleScript - Code, den Sie in anderen Skripten wiederverwenden können. Hat keinen Ausführungskontext.
Wenn Sie ein Script erstellen, beträgt der Standard-Ausführungskontext Legacy, was bedeutet, dass a) es sich um ein serverseitiges Skript handelt und b) es nur ausgeführt wird, wenn es sich in einem Servercontainer, wie Workspace oder ServerScriptService, befindet.
- Wenn Sie den Ausführungskontext des Skripts auf Server ändern, kann es nun auch in ReplicatedStorage ausgeführt werden, was jedoch nicht empfohlen wird. Die Inhalte dieses Standorts werden den Clients repliziert, sodass es ein schlechter Standort für serverseitige Skripte ist.
- Wenn Sie den Ausführungskontext des Skripts auf Client ändern, kann es in ReplicatedStorage ausgeführt werden. Es kann auch in StarterCharacterScripts und StarterPlayerScripts ausgeführt werden. Starter-Container werden jedoch an Clients kopiert, sodass das ursprüngliche Skript und die Kopie ausgeführt werden, was nicht wünschenswert ist.
Um den Ausführungskontext eines Skripts zu ändern, wählen Sie es im Explorer aus und ändern Sie den Wert im Properties-Fenster.
Empfehlungen
Platzieren Sie Clientskripte in ReplicatedStorage mit einem RunContext von Client neben client- spezifischen ModuleScripts.
Beim Debuggen in Studio können Sie auf Linien im Output-Fenster klicken und zu ReplicatedStorage.YourScript (dem stabilen Standort des Skripts) anstelle von Players.YourName.PlayerScripts.YourScript (dem flüchtigen Standort, an den das Skript zur Laufzeit kopiert wurde) gehen.
Platzieren Sie Serverskripte in ServerScriptService mit einem RunContext von Server neben server- spezifischen ModuleScripts.
Um Code zwischen Server- und Clientskripten zu teilen, verwenden Sie ModuleScripts in ReplicatedStorage.
Um organisiert zu bleiben, schreiben viele Creator den Großteil ihres Codes in ModuleScripts und verwenden require(), um alle in genau einem Serverskript und einem Clientskript zu laden.
Wenn Sie Skripte innerhalb von Modellen und Paketen platzieren, geben Sie für jedes Skript einen RunContext an, um Mehrdeutigkeiten zu beseitigen, wie es ausgeführt wird. Die explizite Festlegung dieser Eigenschaft macht Modelle und Pakete wahrscheinlicher, dass sie aus verschiedenen Standorten ordnungsgemäß funktionieren.
Platzieren Sie die minimale Anzahl von Clientskripten (wie ein Lade-Skript) in ReplicatedFirst mit einem RunContext von Client. Um mehr zu erfahren, siehe Replikationsreihenfolge.
Verwenden Sie LocalScripts in StarterCharacterScripts, StarterPlayerScripts, StarterGui und StarterPack.
Skriptstandorte
| Location | Description |
|---|---|
| Workspace | Stellt die 3D-Welt des Spiels dar. Dieser Ort eignet sich gut für Server-Skripte, die direkt an Objekte angehängt werden und deren Verhalten steuern. |
| ReplicatedFirst | Enthält Objekte, die zuerst an den Client repliziert werden. Dieser Ort ist ideal für die absolut minimale Menge an Objekten und Client-Skripten, die erforderlich sind, um einen Ladebildschirm anzuzeigen. |
| ReplicatedStorage | Enthält Objekte, die sowohl an den Client als auch an den Server repliziert werden. Dieser Ort ist ideal für ModuleScripts, die sowohl auf dem Server als auch auf dem Client verwendet werden sollen. LocalScripts werden von diesem Ort aus nicht ausgeführt, aber Scripts mit einem RunContext von Client tun dies. |
| ServerScriptService | Enthält Server-Skripte. Dieser Ort ist ideal für Skripte, die auf serverseitige Funktionen oder Objekte zugreifen müssen, wie Spiel-Logik und Cloud-Speicherung. |
| ServerStorage | Enthält serverseitige Objekte. Dieser Ort ist ideal für große Objekte, die nicht sofort an Clients repliziert werden müssen, wenn sie einem Spiel beitreten. Skripte werden von diesem Ort aus nicht ausgeführt, aber Sie können serverseitige ModuleScripts hier speichern. |
| StarterPlayer ⟩ StarterCharacterScripts | Enthält LocalScripts, die ausgeführt werden, wenn der Charakter erscheint. |
| StarterPlayer ⟩ StarterPlayerScripts | Enthält allgemeine LocalScripts, die ausgeführt werden, wenn der Spieler dem Spiel beitritt. |
| StarterGui | Enthält GUI-Elemente, die der Client anzeigt, wenn er das Spiel lädt. LocalScripts können von diesem Ort aus ausgeführt werden. Dieser Ort ist ideal für Skripte, die die Benutzeroberfläche des Spiels ändern, wie das Hinzufügen von Schaltflächen, Menüs und Pop-ups. |
| StarterPack | Enthält in der Regel nur Tools, kann aber auch LocalScripts für die Einrichtung von Spieler-Rucksäcken beinhalten. |
Dieses Bild zeigt, welche Standorte im Explorer Clientskripte enthalten können. Denken Sie daran, dass ReplicatedFirst und ReplicatedStorage Scripts mit einem RunContext von Client enthalten können, während die Starter[]-Container LocalScripts verwenden sollten.
Beispielprojektstruktur
Das Plant Referenzprojekt zeigt, wie Sie Ihren Code in einem großen, komplexen Spiel organisieren können.
Besonders hervorzuheben ist, wie es den Großteil seines Codes als wiederverwendbare ModuleScripts in ReplicatedStorage und ServerStorage speichert.