Skripttypen und -standorte

Für viele Entwickler besteht die grundlegende Herausforderung bei der Anpassung an das Roblox-Scripting in der Bedeutung des Dateistandorts und der Script.RunContext-Eigenschaft. Je nach Skripttyp, Standort im Explorer und Ausführungskontext können Skripte sehr unterschiedlich reagieren. Bestimmte Methodenaufrufe könnten fehlschlagen, Objekte in deinem 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 Mehrspieler sind. Skripte müssen die Fähigkeit haben, nur auf dem Server, nur auf dem Client oder über beide hinweg ausgeführt zu werden. Die Entwicklung der Roblox-Plattform im Laufe der Zeit hat die Situation weiter kompliziert.

Skripttypen

Roblox hat drei Arten 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 du in anderen Skripten wiederverwenden kannst. Hat keinen Ausführungskontext.

Wenn du ein Script erstellst, ist sein standardmäßiger Ausführungskontext Legacy, was bedeutet, dass es a) ein serverseitiges Skript ist und b) nur ausgeführt wird, wenn es sich in einem Servercontainer wie ServerScriptService oder Workspace befindet.

• Wenn du den Ausführungskontext des Skripts auf Server änderst, kann es jetzt auch in ReplicatedStorage ausgeführt werden, aber wir empfehlen das nicht. Der Inhalt dieses Standorts wird an Clients repliziert, sodass es ein schlechter Standort für serverseitige Skripte ist.
• Wenn du den Ausführungskontext des Skripts auf Client änderst, 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ähle es im Explorer aus und ändere den Wert im Eigenschaften-Fenster.

Empfehlungen

• Lege ein einzelnes Script mit einem RunContext von Client in ReplicatedStorage.

• Lege ein einzelnes Script mit einem RunContext von Server in ServerScriptService.

• Verwende ModuleScripts für so viel Client- und Servercode wie möglich. Fordere diese Module in deinem Client-Skript und deinem Server-Skript an.

  Dieser Ansatz gibt deinem Code einen einzigen Einstiegspunkt auf der Client- und Serverseite, was die Organisation vereinfacht und es einfach macht, problematische Module zu isolieren oder zu deaktivieren. Füge jeder ModuleScript eine start()-Funktion hinzu, damit alle Module geladen werden können, bevor du mit der Ausführung ihres Codes beginnst:

  Beispiel für ein Server-Skript

  --!strict
  local ServerScriptService = game:GetService("ServerScriptService")
  local SampleModule = require(ServerScriptService.SampleModule)
  local AnotherSampleModule = require(ServerScriptService.AnotherSampleModule)
  SampleModule.start()
  AnotherSampleModule.start()

  Beispielmodul

  --!strict
  local CollectionService = game:GetService("CollectionService")
  
  local NPC_TAG = "npc"
  
  local SampleModule = {}
  
  local function setUpNpc(npc: Instance)
      -- initialisiere jeden NPC
  end
  
  local function cleanUpNpc(npc: Instance)
      -- wird ausgeführt, wenn das Ereignis ausgelöst wird
  end
  
  function SampleModule.start() -- füge die Funktion zur Tabelle hinzu
      -- Beispielschleife für die Einrichtung basierend auf Tags
      for _, npc in CollectionService:GetTagged(NPC_TAG) do
          setUpNpc(npc)
      end
  
      -- führe Funktionen aus, wenn Ereignisse ausgelöst werden
      CollectionService:GetInstanceAddedSignal(NPC_TAG):Connect(setUpNpc)
      CollectionService:GetInstanceRemovedSignal(NPC_TAG):Connect(cleanUpNpc)
  end
  
  return SampleModule

• Um Code zu teilen, verwende ModuleScripts in ReplicatedStorage und fordere sie sowohl in deinem Client-Skript als auch in deinem Server-Skript an.

• Wenn es für dein Spiel notwendig ist, wiederhole dasselbe Muster in ReplicatedFirst mit einem einzelnen Client-Skript und einer minimalen Anzahl von ModuleScripts, um einen Ladebildschirm zu implementieren. Um mehr über ReplicatedFirst zu erfahren, siehe Replikationsreihenfolge.

• Verwende LocalScripts sparsam. Wenn du sie verwenden musst, lege sie in StarterCharacterScripts, StarterPlayerScripts, StarterGui oder StarterPack.

  Skripte in diesen Containern werden in die Spielercontainer kopiert, anstatt von einem Standort aus ausgeführt zu werden, was das Debuggen komplizieren kann. Die Verwendung von ReplicatedStorage für Client-Code ermöglicht es dir, Zeilen im Output-Fenster anzuklicken und zu ReplicatedStorage.YourScript (dem stabilen Standort des Skripts) zu gelangen, anstatt zu Players.YourName.PlayerScripts.YourLocalScript (dem flüchtigen Standort, an den das Skript zur Laufzeit kopiert wurde).

• Vermeide es, Skripte direkt an Instanzen in Workspace anzuhängen. Tagge stattdessen Instanzen und verwende CollectionService, um von einem einzelnen ModuleScript aus mit ihnen zu arbeiten.

  Die wichtigste Ausnahme ist, wenn du Modelle oder Pakete im Creator Store verteilst. In diesem Fall musst du möglicherweise Skripte innerhalb der Instanzhierarchie einfügen; gib für jedes Skript einen RunContext an, um Mehrdeutigkeiten darüber zu beseitigen, wie es ausgeführt wird. Das explizite Setzen dieser Eigenschaft erhöht die Wahrscheinlichkeit, dass Modelle und Pakete von verschiedenen Standorten aus ordnungsgemäß funktionieren.

Beispielprojektstruktur

Das Plant-Referenzprojekt zeigt, wie du deinen Code in einem großen, komplexen Spiel organisieren könntest. Es speichert den Großteil seines Codes als wiederverwendbare ModuleScripts.

Skriptstandorte

Dieses Bild zeigt, welche Standorte im Explorer Client-Skripte enthalten können. Denk daran, dass ReplicatedFirst und ReplicatedStorage Scripts mit einem RunContext von Client enthalten können, während die Starter[]-Container LocalScripts verwenden sollten.