Categories
Introduction
Before we start, I'd like to remind you that when you follow this guide (or any other scripting tutorial really), and complete it and feel like you now know scripting, you might forget the syntax later, and that is normal. You don't learn properly without practice. Give yourself a challenge like making a ping-pong game or even making your first actual game. It is also alright to end up googling something like "how to get all children of an instance" (i'll explain why we used 'children' here and the hierarchy naming later) because that is also how you learn. Personally, I learned by looking at examples and reusing them in a different way, and making random games. Now let's actually begin the guide
In Roblox, and pretty much everywhere else, the hierarchy (the tree you find in the Studio Explorer) is based on the family tree to understand it simpler. If you go on the Explorer and expand "Workspace" by the arrow that appears next to it, you will see the 'children' (which usually are Terrain, Camera and Baseplate on a new Studio place). From those children's perspective, the Workspace is the 'parent', and from the Workspace's perspective, the DataModel ('game', the base root of a Roblox place) is the parent.
What does this have to do with scripting? Well you will eventually find methods like "FindFirstChild()", "FindFirstAncestor()" and "GetDescendants()", and properties like .Parent, so you need to have this in mind.
Roblox uses Luau, an embeddable scripting language derived from Lua 5.1. This means that Lua 5.1 is valid and backwards compatible with Luau (this is not true the other way around). However, in the rest of the guide, we will still refer to Roblox's programming language "Luau".
Roblox has 3 types of scripting objects: Script, LocalScript, and ModuleScript.
Script
Docs availableThis is the object where we type Luau code in. It is always run server-side. You will learn more about server and client later. This is the most used script object for scripting in Roblox Studio.
LocalScript
Docs availableThis is same same but differeeent. This is also where you type Luau code. However, this is run client-side.
So, what is the difference? What is server-side and client-side?
It's important to remember the difference, but it's not very difficult to differentiate between them.
- Server-side: Stuff that is run "server-side" means that it is executed on the Roblox server the game is running on, which is the host. Think of it as the leader of clients, each changes are replicated to each client, which means every client (everyone) can see the changes that happened on the server. But theres latency between the server and clients of course, so stuff such as checking for user input should be rather handled on the client than on the server.
- Client-side: Stuff that is run "client-side" means that it is executed on your machine, this means that LocalScripts are running only on your device. So, client changes only happen on your side, and not on anyone else.
When should I use a Script and a LocalScript?
- Use Scripts when you want to execute code globally. For example, when you make a part move using a script, everyone should see that part move. So you would use a Script.
- Use LocalScripts when you want to execute code per player. A good use case is when building UI. You would only want the user to navigate UI by themselves, and not make the changes on the server, where everyone could see what UI buttons you are pressing. Otherwise that would be a huge mess!
ModuleScript
Docs availableFinally, we have the ModuleScript. Now, this is not a regular script where it is directly executed. This is a module. A Script or a LocalScript can require a ModuleScript.
ModuleScripts are helper scripts which usually provide functions or variables which a Script or LocalScript can use. It is basically an extension to a script. This is useful when you don't want huge lines of code.
Note: Some people (majority on the DevForum) may tell you to never use ModuleScripts for micro-optimization purposes; some may tell you to use them all the time. In reality, there's no perfect way to code. You can use ModuleScripts or not, it's your choice. The purpose of ModuleScripts anyway are shared tables, OOP (Object-Oriented Programming), or a way to store functions. Use them in any way you'd prefer.