For many developers, the fundamental challenge of adapting to Roblox scripting is the importance of file location and the Script.RunContext property. Depending on script type, location in the Explorer, and run context, scripts can behave very differently. Certain method calls might fail, objects in your game might be inaccessible, or scripts might not run at all.
The reason for this complexity is that Roblox games are multiplayer by default. Scripts need the ability to only run on the server, only run on the client, or be shared across both. The evolution of the Roblox platform over time has further complicated the situation.
Script types
Roblox has three types of scripts:
- Script - Code that runs on either the server or the client, depending on its location and Script.RunContext property.
- LocalScript - Code that runs only on the client. Does not have a run context.
- ModuleScript - Code that you can reuse in other scripts. Does not have a run context.
When you create a Script, its default run context is Legacy, meaning that it a) is a server-side script and b) only runs if it is in a server container, such as Workspace or ServerScriptService.
- If you change the script's run context to Server, it can now also run in ReplicatedStorage, but that's not recommended. The contents of that location are replicated to clients, so it's a poor location for server-side scripts.
- If you change the script's run context to Client, it can run in ReplicatedStorage. It can also run in StarterCharacterScripts and StarterPlayerScripts. Starter containers are copied to clients, though, so the original script and the copy run, which isn't desirable.
To change a script run context, select it in the Explorer and change the value in the Properties window.
Recommendations
Put client scripts into ReplicatedStorage with a RunContext of Client alongside client-only ModuleScripts.
When debugging in Studio, you can click lines in the Output window and go to ReplicatedStorage.YourScript (the stable location of the script) rather than Players.YourName.PlayerScripts.YourScript (the ephemeral location that the script was copied to at runtime).
Put server scripts into ServerScriptService with a RunContext of Server alongside server-only ModuleScripts.
To share code between server and client scripts, use ModuleScripts in ReplicatedStorage.
To stay organized, many creators write the vast majority of their code in ModuleScripts and require() all of them in exactly one server script and one client script.
Put the minimal number of client scripts (such as a loading script) into ReplicatedFirst with a RunContext of Client. To learn more, see Replication order.
Use LocalScripts in StarterCharacterScripts, StarterPlayerScripts, StarterGui, and StarterPack.
Script locations
| Location | Description |
|---|---|
| Workspace | Represents the game's 3D world. This location works well for server scripts that attach directly to objects and control their behavior. |
| ReplicatedFirst | Contains objects that replicate to the client before anything else. This location is ideal for the absolute minimum set of objects and client scripts necessary to display a loading screen. |
| ReplicatedStorage | Contains objects that are replicated to both the client and the server. This location is ideal for ModuleScripts that you want to use on both the server and the client. LocalScripts do not run from this location, but Scripts with a RunContext of Client do. |
| ServerScriptService | Contains server scripts. This location is ideal for scripts that need to access server-side functionality or objects, such as game logic and cloud storage. |
| ServerStorage | Contains server-side objects. This location is ideal for large objects that don't need to be immediately replicated to clients when they join a game. Scripts do not run from this location, but you can store server-side ModuleScripts here. |
| StarterPlayer ⟩ StarterCharacterScripts | Contains LocalScripts that run when the character spawns. |
| StarterPlayer ⟩ StarterPlayerScripts | Contains general-purpose LocalScripts that run when the player joins the game. |
| StarterGui | Contains GUI elements that the client displays when it loads the game. LocalScripts can run from this location. This location is ideal for scripts that modify the game's user interface, such as adding buttons, menus, and pop-ups. |
| StarterPack | Generally only contains Tools, but can also include LocalScripts for setting up player backpacks. |
This image shows which Explorer window locations can contain client scripts. Remember, ReplicatedFirst and ReplicatedStorage can contain Scripts with a RunContext of Client, whereas the Starter[] containers should use LocalScripts.
Example project structure
The Plant reference project shows how you might organize your code in a large, complex game.
Of particular note is how it stores the vast majority of its code as reusable ModuleScripts in ReplicatedStorage and ServerStorage.