People have been telling me that a good way to develop your game is by having 1-2 local scripts, 1-2 server scripts, and have everthing else be module scripts. Is this really a good practice? And if so can someone give me an example or two of how to implement it? (tycoon, simulator, fps) Because I just don’t know what kind of functions to put in each script and if this is the easiest way then I want to understand it
it depends. i use localscript for client-sided stuff (obviously) such as tweening/modifying guis or playing typewriting effects. server scripts for modifying values and checks. modulescripts for when you need to use that function in different scripts
The local and server scripts are to require the module so you can get the functions out of them. Each module should house functions related to its purpose. Ex:
Lets say you are making a fps game. Then one module should be to handle the shooting of the gun and it should house functions like ShootModule:FireRay
and ShootModule:CreateEffect
. And another module could be to select the loadout so it would be like LoadoutModule:ChangeLoadout
and LoadoutModule:GetLoadoutWeapons
Doing this keeps your game extremely readable and just prevents it from spawning headaches
Think of it like this: Modules are the storage and building blocks, and scripts are what puts them together. This isnt the only way but its the most organized, readable and most recommended way. Obviously the amount of scripts and modules depend of your game but most of the time you would probably want to have more modules than scripts.
How would you organize a party system or a menu GUI with this method? @Dynamite2479 I want to ask you this question as well
LocalScript can use Remote Event or Remote Function to retrieve value or trigger things that the server needs to process.
A party system needs LocalScripts that connect the server Remote Functions of doing things like forming parties, kicking players, leaving parties, and sending party invites to players on the server.
The client GUI should use data obtained from the server this way to form the party GUI, like displaying player who actually agreed to join your party in a frame on the GUI also showing their current health and mana.
The client needs LocalScripts to connect actions you decided in code that the server needs to process. And the server needs functions and events that process those actions.
For a menu gui, have one module with different functions to handle each button that was clicked. Eg: MenuModule:PlayButtonActivated
or MenuModule:CreditsButtonActivated
Okay what i would personally do is keep all the methods inside the module. For example i would add 6 methods for a party like: Party:Start()
And keep in mind this uses OOP and metatables if your not familiar with them you can do the same without it but some extra code. Basically all the needed functions in the module and then make them all come together with a local script. Obviously more than the script is needed like remote events.
So in short server script handles the actual parties which are in tables. module handles the functions for the party and each client is responsible for sending the server their inputs eg: player presses the create party button and send the request to the server. And the server is responsible for sending all clients information about the parties when they are changed.
Also for sure learn Object Oriented Programming (OOP) its a life saver. Framework of your game is really important and you want to keep it very managble, organized and future proof.
This way of development is by no means easy but in the future it will be much easier to maintain your game. Having 1-2 server and localscripts each is kinda extreme, because oftentimes you’ll need more to handle different parts of your game. This advice is just to modularize your code to make it easier to manage and understand. This does not mean that you have restrict yourself to 1-2 scripts.
I have an example:
This is a round-based sword fighting game I’ve been working on for a while which has gamemodes and disasters.
Instead of coding the gamemodes and disasters directly into the script which handles rounds, I make them ModuleScripts, which return a function that can be cancelled anytime (eg. the round is over). The round script will load these modules as needed. Here’s the hierachy:
This makes my game’s development considerably faster than if I just hardcoded them.
Having only a few scripts isn’t necessarily a good or bad practice, the organization you choose should mostly depends on your personal preference. You shouldn’t force yourself to use a type of organization that you dislike just because other scripters told you to. If you prefer using more scripts or whatever, you’re free to do it, it isn’t necessarily bad. Some people could have a better feeling and workflow using a specific organization while it could not be the case for others.
Personally, i’m using a different script and modules to individually handle each different part of the game, such as one for all GUI, the characters, the datastore, all events ect…
Thank you everyone for helping me, reading through this thread helped me a lot. I just have one more request, do you have any tutorials/guides for learning OOP and/or metatables? I’ve been trying to learn for a while but I can’t get the hang of it
My OOP knowledge is self-taught, so I wouldn’t know much, but here’s my advice.
Use ChatGPT to the fullest extent as it’s your best tool along with Devforum to learn OOP. There are tons of posts on the devforum as well about OOP. Finally, I think there’s a guy on YouTube whom I think I learnt OOP basics from. Link to him
I feel ya i learned oop all by myself. The way i did it was youtube, devforum questions, any form of searching. So i have a good idea if it and even i have a perspective of someone new trying to learn. You should follow these ways but my messages are always open where i could guide you a bit more.
Alright thank you guys for the help. I’ll definitely reach out if I need anything else
It’s possible to make a game with 1 server script, 1 local script, and a handful of modules. However, it becomes very difficult to debug a single gargantuan script, or even just navigate it in general. You should split up scripts according to specific tasks, such as having a unique a script for handling UI, another for movement, and a third for VFX. Modules can be used more liberally.