Table of Contents
Why Roblox Uses Different Script Types
Roblox uses two main kinds of Lua scripts to run your game logic: Script and LocalScript. They both use the same Lua language, but they do not run in the same place and they do not have access to the same things. Understanding how they differ is one of the most important parts of Roblox scripting, because it affects what your code can do and who can see the results.
At a very high level, a normal Script runs on the server. A LocalScript runs on a single player’s device, which is called the client. The idea of server and client will appear many times in Roblox development, so this is your first practical encounter with it. In later chapters you will connect this with RemoteEvents and multiplayer logic. Here you will focus only on how script types behave and what you should use them for.
Key rule: Use Script for server logic. Use LocalScript for player specific and user interface logic.
Where Scripts and LocalScripts Run
When you add a new script in Roblox Studio, you will usually choose between Script and LocalScript. The code looks the same, but Roblox decides when and where to execute it based on its type and its location in the game hierarchy.
A Script runs on the server. In online games there is a Roblox server that keeps the authoritative game world. All players connect to it. When you use Script, the server executes your code. This means any changes you make with that script apply to the shared world and are seen by all players. For example, if a server script creates a new part in Workspace, every player will see that part.
A LocalScript runs on the client. Each player has their own client that renders the world and shows the user interface. A LocalScript that is running for one player is not running for other players. If a LocalScript changes something that only exists on the client, other players do not see that change. For example, updating a ScreenGui to show a message is something only that one player will see.
Because of this, one action can feel very different depending on which script type you use. If you change a part’s color from a server script, all players see the new color. If a LocalScript changes a part’s color that only exists for that client, other players will not see any difference. You will use this behavior to control which things are global and which things are personal.
Typical Uses of Scripts
Server scripts are used for things that must be correct and shared for all players. They are also used for anything that needs to be secure, such as rewards, currency, or rules of the game.
Common uses for Script include:
Game rules that affect everyone. For example, starting and ending a round, spawning items into the world, or changing the map.
Creating and managing things in Workspace. This includes platforms, enemies that all players can see, or objects that multiple players can interact with.
Changing player characters in ways that all players should see, like applying a uniform to all players, or setting their walk speed globally.
Handling data that should not be trusted to the player, such as saving coins, controlling leaderboards, or deciding whether a player really earned a reward.
If you imagine your game as a board game, the server is like the referee that everyone can see and trust. The referee’s decisions need to be consistent, so they live in server scripts.
Important: Anything that involves rewards, currency, or rules that must be fair for all players belongs in Script on the server.
Typical Uses of LocalScripts
LocalScripts are used for things that belong to a single player and do not need to be shared exactly the same way with everyone. They are also used for anything that reacts to that player’s input or display, such as user interface, camera, and controls.
Common uses for LocalScript include:
User interface logic. For example, changing a health bar color when the player is low on health, showing a tutorial message, or opening and closing menus.
Camera and view. You might move the camera to follow the player in a special way, or create a cutscene that plays only on that player’s screen.
Player input. Reading when the player presses keys or clicks buttons on the screen and then reacting to it on their own client.
Visual effects that do not need to be identical for all players, such as showing a special glow only for the local player, or rendering client side particle effects.
Any time you want a game to feel responsive to a player, you place the immediate response in a LocalScript. If the action has consequences for the rest of the game, the LocalScript will later talk to the server. That communication is covered in a later chapter on RemoteEvents, so here you only focus on the LocalScript’s role on the client.
Rule of thumb: Use LocalScript for UI, camera, input, and personal visual effects. Do not use it for secure game logic or shared rules.
Where Scripts and LocalScripts Can Live
Roblox does not run LocalScripts everywhere. Their location in the Explorer decides if they will run at all. Server scripts are simpler: if a Script is under a place the server executes, such as ServerScriptService, it will run.
You can reliably place a server Script in areas like ServerScriptService, ServerStorage, or inside objects in Workspace. Code in these scripts will run on the server when the game starts or when the object appears. You will often keep most of your game logic in ServerScriptService to keep it organized and hidden from clients.
LocalScripts, on the other hand, must be in certain locations related to the player. The most common ones you will use are:
Inside StarterGui, which becomes PlayerGui for each player. This is where you put UI logic.
Inside StarterPlayerScripts, which becomes PlayerScripts on each player. This is useful for general client side behavior that is not UI, such as input handling.
Inside StarterCharacterScripts, which runs inside each player’s character as it spawns on the client. This is useful for customizing how the local character looks or behaves.
LocalScripts inside these places will run for each player on their own client. If you place a LocalScript in a location that is only known to the server, such as ServerScriptService, it will never run. When you are confused about why your LocalScript does nothing, checking its location is often the first thing to do.
Critical rule: A LocalScript must be inside a player related container, such as PlayerGui, PlayerScripts, or StarterCharacterScripts, or it will not run.
What Each Script Type Can Access
Because of their different roles, Scripts and LocalScripts have access to different services and objects. Some services are available to both, such as Workspace, but their view of the world can still differ.
A server Script sees the authoritative game world. When it looks at Workspace, it sees what the server believes is true. When it uses Players, it can see all connected players. It can create new parts, move them, and those changes are replicated out to all clients. When a Script looks at a player’s character, it sees the version stored on the server.
A LocalScript sees the client’s view. It can also look at Workspace and Players, but some changes it makes might only be visible on that client, depending on replication rules. It has special access to client side services, such as UserInputService for keyboard and mouse, or StarterGui which becomes PlayerGui. It also has direct access to that one player’s camera and screen.
Because a LocalScript runs on a single client, it cannot safely be used to make decisions that the server should trust. For example, if a LocalScript decides how many coins a player has, a cheating player could try to modify that script and give themselves infinite coins. The server would never know that this is wrong. For this reason you must always let the server through a normal Script own critical data and decisions.
Simple Examples of What Belongs Where
You can take some common game features and decide which script type should control them by thinking about who they affect and how secure they must be.
If you create a start menu with buttons on the screen, that menu only appears for each player on their own device. The logic to open, close, and animate that menu belongs in a LocalScript inside a ScreenGui.
If you give a player coins when they touch a special brick, the actual change to their coin amount belongs in a Script on the server. The brick might detect a touch on the server, update the player’s stored coin value, and then later you can show the new total to the player through a LocalScript.
If you want the camera to zoom in when a player presses a key, the key detection and camera change should be in a LocalScript on the client. If pressing that key also activates a power that affects other players, the LocalScript can ask the server to perform the shared effect, which the server Script will handle.
When you practice, you can start by asking two questions for any behavior. First, does this affect everyone or just one player. Second, must the result be secure and fair. If it affects everyone or needs to be trusted, use a Script. If it affects only one player and is not sensitive, use a LocalScript.
Performance and Responsiveness
Another reason Roblox separates Scripts and LocalScripts is performance. The server might be handling many players at once, so it cannot instantly react to every tiny input, such as every mouse movement. If every small input had to go to the server and then back to the client, the game would feel slow.
By running LocalScripts on the client, Roblox lets you respond to input and update the interface without waiting for the network. Movement of the camera, highlighting buttons on hover, or playing local visual effects can all happen immediately. This makes the game feel smoother for the player.
However, because LocalScripts do not decide shared results, you combine them with server scripts if an action has important consequences. The LocalScript can handle the instant visual feedback, while the Script later confirms the effect, such as actually removing health from an enemy or giving a reward. You will learn how to send those messages between client and server when you study RemoteEvents.
Common Beginner Mistakes
When you first work with Scripts and LocalScripts, you are likely to run into some repeating issues.
One common problem is putting a LocalScript in a place where it never runs, such as ServerScriptService. The code looks correct, but it does not execute. Moving it to StarterPlayerScripts or inside a ScreenGui often fixes this.
Another mistake is trying to access something that only exists on the server from a LocalScript, or something that only exists on the client from a server Script. For example, a server Script trying to directly change PlayerGui for each player is often not the best choice. Instead, you usually let the LocalScript manage the GUI.
A third mistake is trying to put secure logic in a LocalScript, such as adding money to a player directly on their client. This can work in Studio tests, but in real multiplayer it opens the door to exploits. The correct pattern is to ask the server through a Script to perform the secure change.
By paying attention to where each script runs, what it is allowed to control, and how visible its changes are, you avoid these problems and build a solid base for more advanced systems that involve communication between client and server.
How to Choose Between Script and LocalScript
When you are not sure which script type to use, you can follow a small mental checklist.
If the code is about user interface, camera, or direct player input, choose LocalScript. These features are naturally client side and must feel responsive.
If the code is about changing the shared game world, keeping score, or enforcing the rules, choose Script. These features must be consistent for all players and protected from cheating.
If the feature touches both sides, split it. Use a LocalScript for the immediate response to the player, and use a Script for the trusted game logic. In later chapters you will see how to connect these pieces cleanly.
Over time this choice becomes natural. In this chapter you only needed to understand that the two script types exist, that they run in different places, and that each has its role. With that, you are ready to start using Roblox specific scripting features like events, where this separation becomes even more important.