Typy skryptów i lokalizacje

Dla wielu deweloperów podstawowym wyzwaniem związanym z programowaniem w Robloxie jest znaczenie lokalizacji pliku oraz właściwości Script.RunContext. W zależności od typu skryptu, lokalizacji w Eksploratorze i kontekstu uruchomienia, skrypty mogą działać bardzo różnie. Niektóre wywołania metod mogą się nie powieść, obiekty w twojej grze mogą być niedostępne, lub skrypty mogą w ogóle się nie uruchamiać.

Powodem tej złożoności jest to, że gry Roblox są domyślnie wieloosobowe. Skrypty muszą mieć możliwość uruchamiania się tylko na serwerze, tylko na kliencie lub być współdzielone pomiędzy nimi. Ewolucja platformy Roblox w czasie dodatkowo skomplikowała sytuację.

Typy skryptów

Roblox ma trzy typy skryptów:

• Script - Kod, który działa na serwerze lub kliencie, w zależności od jego lokalizacji i właściwości Script.RunContext.
• LocalScript - Kod, który działa tylko na kliencie. Nie ma kontekstu uruchomienia.
• ModuleScript - Kod, który możesz ponownie wykorzystać w innych skryptach. Nie ma kontekstu uruchomienia.

Kiedy tworzysz Script, jego domyślny kontekst uruchomienia to Legacy, co oznacza, że a) jest to skrypt po stronie serwera i b) działa tylko, jeśli znajduje się w kontenerze serwera, takim jak ServerScriptService lub Workspace.

• Jeśli zmienisz kontekst uruchomienia skryptu na Server, może on teraz również działać w ReplicatedStorage, ale nie zalecamy tego. Zawartość tej lokalizacji jest replikowana do klientów, więc jest to słaba lokalizacja dla skryptów po stronie serwera.
• Jeśli zmienisz kontekst uruchomienia skryptu na Client, może on działać w ReplicatedStorage. Może również działać w StarterCharacterScripts i StarterPlayerScripts. Kontenery startowe są kopiowane do klientów, więc oryginalny skrypt i kopia działają, co nie jest pożądane.

Aby zmienić kontekst uruchomienia skryptu, wybierz go w Eksploratorze i zmień wartość w oknie Właściwości.

Rekomendacje

• Umieść pojedynczy Script z RunContext ustawionym na Client w ReplicatedStorage.

• Umieść pojedynczy Script z RunContext ustawionym na Server w ServerScriptService.

• Używaj ModuleScripts dla jak największej ilości kodu po stronie klienta i serwera. Wymagaj tych modułów w swoim skrypcie klienckim i skrypcie serwerowym.

  Takie podejście daje twojemu kodowi jeden punkt wejścia po stronie klienta i serwera, co upraszcza organizację i ułatwia izolowanie lub wyłączanie problematycznych modułów. Dodaj funkcję start() do każdego ModuleScript, aby wszystkie moduły mogły się załadować przed rozpoczęciem wykonywania ich kodu:

  Przykładowy skrypt serwerowy

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

  Przykładowy moduł

  --!strict
  local CollectionService = game:GetService("CollectionService")
  
  local NPC_TAG = "npc"
  
  local SampleModule = {}
  
  local function setUpNpc(npc: Instance)
      -- inicjalizuj każdego NPC
  end
  
  local function cleanUpNpc(npc: Instance)
      -- uruchom, gdy zdarzenie się uruchomi
  end
  
  function SampleModule.start() -- dodaj funkcję do tabeli
      -- przykładowa pętla do konfiguracji na podstawie tagów
      for _, npc in CollectionService:GetTagged(NPC_TAG) do
          setUpNpc(npc)
      end
  
      -- uruchom funkcje, gdy zdarzenia się uruchomią
      CollectionService:GetInstanceAddedSignal(NPC_TAG):Connect(setUpNpc)
      CollectionService:GetInstanceRemovedSignal(NPC_TAG):Connect(cleanUpNpc)
  end
  
  return SampleModule

• Aby dzielić kod, używaj ModuleScripts w ReplicatedStorage i wymagaj ich w swoim skrypcie klienckim i skrypcie serwerowym.

• Jeśli to konieczne dla twojej gry, powtórz ten sam wzór w ReplicatedFirst z pojedynczym skryptem klienckim i minimalną liczbą ModuleScripts, aby zaimplementować ekran ładowania. Aby dowiedzieć się więcej o ReplicatedFirst, zobacz Kolejność replikacji.

• Używaj LocalScripts oszczędnie. Jeśli musisz ich używać, umieść je w StarterCharacterScripts, StarterPlayerScripts, StarterGui lub StarterPack.

  Skrypty w tych kontenerach klonują się do kontenerów gracza, a nie działają z jednej lokalizacji, co może skomplikować debugowanie. Używanie ReplicatedStorage dla kodu klienckiego pozwala na klikanie w linie w oknie Output i przechodzenie do ReplicatedStorage.YourScript (stabilna lokalizacja skryptu) zamiast Players.YourName.PlayerScripts.YourLocalScript (ulotna lokalizacja, do której skrypt został skopiowany w czasie wykonywania).

• Unikaj bezpośredniego przypisywania skryptów do instancji w Workspace. Zamiast tego, taguj instancje i używaj CollectionService, aby pracować z nimi z jednego ModuleScript.

  Kluczowym wyjątkiem jest sytuacja, gdy dystrybuujesz modele lub pakiety w Sklepie Twórcy. W takim przypadku możesz potrzebować dołączyć skrypty w hierarchii instancji; określ RunContext dla każdego skryptu, aby usunąć niejasności dotyczące jego działania. Wyraźne ustawienie tej właściwości sprawia, że modele i pakiety mają większe szanse na prawidłowe działanie z różnych lokalizacji.

Przykładowa struktura projektu

Projekt referencyjny Plant pokazuje, jak możesz zorganizować swój kod w dużej, złożonej grze. Przechowuje on większość swojego kodu jako wielokrotne ModuleScripts.

Lokalizacje skryptów

Ten obrazek pokazuje, które lokalizacje w oknie Eksplorator mogą zawierać skrypty klienckie. Pamiętaj, że ReplicatedFirst i ReplicatedStorage mogą zawierać Scripts z RunContext ustawionym na Client, podczas gdy kontenery Starter[] powinny używać LocalScripts.