Dla wielu deweloperów, podstawowym wyzwaniem w dostosowywaniu się do skryptowania w Robloxie jest znaczenie lokalizacji plików 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ą kończyć się niepowodzeniem, 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 potrzebują możliwości uruchamiania tylko na serwerze, tylko na kliencie, lub dzielenia się nimi pomiędzy obiema stronami. Ewolucja platformy Roblox w czasie jeszcze bardziej skomplikowała sytuację.
Typy skryptów
Roblox ma trzy typy skryptów:
- Script - Kod, który działa albo na serwerze, albo na 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.
Gdy 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 Workspace lub ServerScriptService.
- Jeśli zmienisz kontekst uruchomienia skryptu na Server, może on teraz działać również w ReplicatedStorage, ale nie jest to zalecane. 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 jego kopia działają, co nie jest pożądane.
Aby zmienić kontekst uruchomienia skryptu, zaznacz go w Eksploratorze i zmień wartość w oknie Właściwości.
Rekomendacje
Umieść skrypty klienckie w ReplicatedStorage z RunContext równym Client obok skryptów ModuleScripts przeznaczonych tylko dla klientów.
Podczas debugowania w Studio, możesz kliknąć linie w oknie Wyjście i przejść do ReplicatedStorage.YourScript (stabilna lokalizacja skryptu) zamiast Players.YourName.PlayerScripts.YourScript (efemeryczna lokalizacja, do której skrypt został skopiowany w czasie działania).
Umieść skrypty serwerowe w ServerScriptService z RunContext równym Server obok skryptów ModuleScripts przeznaczonych tylko dla serwera.
Aby dzielić kod między skryptami serwera i klienta, użyj ModuleScripts w ReplicatedStorage.
Aby zachować porządek, wielu twórców pisze większość swojego kodu w ModuleScripts i używa require() do załadowania ich w dokładnie jednym skrypcie serwera i jednym skrypcie klienta.
Umieść minimalną liczbę skryptów klienckich (takich jak skrypt ładowania) w ReplicatedFirst z RunContext równym Client. Aby dowiedzieć się więcej, zobacz Kolejność replikacji.
Używaj LocalScripts w StarterCharacterScripts, StarterPlayerScripts, StarterGui i StarterPack.
Lokalizacje skryptów
| Location | Description |
|---|---|
| Workspace | Reprezentuje 3D świat gry. Ta lokalizacja dobrze sprawdza się dla skryptów serwerowych, które bezpośrednio łączą się z obiektami i kontrolują ich zachowanie. |
| ReplicatedFirst | Zawiera obiekty, które replikują się do klienta przed wszystkim innym. Ta lokalizacja jest idealna dla absolutnego minimum zestawu obiektów i skryptów klienckich potrzebnych do wyświetlenia ekranu ładowania. |
| ReplicatedStorage | Zawiera obiekty, które są replikowane zarówno do klienta, jak i do serwera. Ta lokalizacja jest idealna dla ModuleScripts, które chcesz używać zarówno na serwerze, jak i w kliencie. LocalScripts nie działają z tej lokalizacji, ale Scripts z RunContext równym Client działają. |
| ServerScriptService | Zawiera skrypty serwerowe. Ta lokalizacja jest idealna dla skryptów, które potrzebują dostępu do funkcjonalności lub obiektów po stronie serwera, takich jak logika gry i przechowywanie w chmurze. |
| ServerStorage | Zawiera obiekty po stronie serwera. Ta lokalizacja jest idealna dla dużych obiektów, które nie muszą być natychmiast replikowane do klientów, gdy dołączają do gry. Skrypty nie działają z tej lokalizacji, ale możesz przechowywać tutaj po stronie serwera ModuleScripts. |
| StarterPlayer ⟩ StarterCharacterScripts | Zawiera LocalScripts, które działają, gdy postać się pojawia. |
| StarterPlayer ⟩ StarterPlayerScripts | Zawiera ogólnego przeznaczenia LocalScripts, które działają, gdy gracz dołącza do gry. |
| StarterGui | Zawiera elementy GUI, które klient wyświetla, gdy ładowana jest gra. LocalScripts mogą działać z tej lokalizacji. Ta lokalizacja jest idealna dla skryptów, które modyfikują interfejs użytkownika gry, takich jak dodawanie przycisków, menu i wyskakujących okienek. |
| StarterPack | Zwykle zawiera tylko Tools, ale może również zawierać LocalScripts do zakupu plecaków gracza. |
Ten obraz pokazuje, które lokalizacje w oknie Eksplorator mogą zawierać skrypty klienckie. Pamiętaj, że ReplicatedFirst i ReplicatedStorage mogą zawierać Scripts z RunContext równym Client, podczas gdy kontenery typu Starter[] powinny używać LocalScripts.
Przykład struktury projektu
Projekt referencyjny Plant pokazuje, jak możesz zorganizować swój kod w dużej, złożonej grze.
Szczególnie istotne jest to, jak przechowuje większość swojego kodu jako wielokrotne ModuleScripts w ReplicatedStorage i ServerStorage.