Is it better to separate my main game code into multiple or different scripts?
9 Likes
A good argument @Kampfkarren made for not using modules, and instead using different scripts, is that the script performance stats panel doesn’t display modules separate from the scripts that require them.
2 Likes
I meant regular scripts or localscripts, not modules.
1 Like
Thats not what i meant, your first exam.
Of course I don’t mean a single script in each gui element, or zombie, or whatever.
I meant breaking your main client or server script code into different components.
I meant breaking your main client or server script code into different components.
It entirely depends on how complex those scripts, and thus the functionality of your game, would be.
if all you are making is an idle clicker ‘simulator’ with not much to it, I can see a single client and server script work. But in general, and even for this example, having all your code in just one script is a bad practice. Not only does it make it much harder to maintain your code, debug it, and make changes, it also will prevent anyone else from reading your code.
If you chop up your game in smaller modules, other programmers who might work with you in the future are able to get started much quicker. And if you ever get yourself into a situation where your code doesn’t work or you need help otherwise, you want the ability to share that smaller script in order to get help. I can almost guarantee you that no one is going to help you if you present them with a messy game script spanning thousands of lines.
3 Likes
@ForeverHD You seem to praise the use of modules a lot. From what I gathered in an earlier thread that I asked about the purpose of modules, they’re good for breaking up your code into components and reusing various parts, yes. On the other hand though, the pros you listed can also be done for non-module scripts (bar re-using code, which is a bit painful). Really it depends on how you yourself organise things.
As a general rule of thumb, I would never run a game off a single script. I used to think that a single script would usually mean better, but that in my mind is equivalent to premature optimisation, there’s no point aside from flexing to others that your game uses minimal self-ran code and is more reliant on modules. If you can get the “look pretty to others” and focus on the code being readable to developers and relatively maintainable, then really go for anything you want.
Personally, I strongly recommend NOT using as little scripts as possible. I worked on a game and decided to shove all of the game’s logic into only five scripts and used zero modules - I CANNOT tell you enough how much of a nightmare that was for me and the programmers who were hired after I left the project. Yes oh praise be this very minimal-looking structure, but getting into the scripts themselves was very unsightly. I myself couldn’t even keep up with my code and patching a simple exploit took me days whereas it should’ve been a 15-minute fix. Trying to update my code was an even worse experience. The game flopped and without me on the project, it just became a lost cause. We’re going to refactor it from ground-up soon.
5 Likes
I am generally against singleton ModuleScripts (a ModuleScript that’s only required once) except for rare cases of when it’s more readable to do it that way (e.g. items follow a common schema, so it makes sense to mass require them). A lot of developers will make one server/local script, then the rest of their code is modules.
Instead, I have a new Script/LocalScript whenever I want a new behavior. For example, if I want the client to receive haptic feedback, what benefit is there to making that a ModuleScript and requiring it? Instead, I’ll just make a new LocalScript and connect to whatever BindableEvents/normal Roblox events I have that might be relevant. In my opinion, this makes for much more decoupled and cleaner code. This also has benefits such as better to read microprofiling and the usage of the script performance window.
10 Likes
I prefer the service/controller architecture. By nature, this works really well with ModuleScripts. And because of that, I typically have a setup consisting of one Script and one LocalScript that drive the modules. This also allows me to abstract away the complicated implementation details. For instance, I can generate RemoteFunctions/Events in the background automatically, and easily create communication between client & server with no work at all. It also opens up incredibly simple communication between all the code. For instance, two modules on the client can easily talk to each other with ease.
This helps me stick closer to the architecture of most modern-day systems. For instance, I can simulate an MVC architecture very easily.
Without the help of a framework behind all of this, I wouldn’t really like it. It would be a lot of work to have to require the modules I want. The framework handles this for me. It can even lazy-load certain modules.
There’s not really a right-or-wrong answer to all of this. I think @Kampfkarren has good reasons to use multiple, and I also feel like my reasons are good too. It might even depend on what you’re trying to create. Do whatever works best for you.
28 Likes
Does this work with OOP too?
Bc currently i’m using OOP and I have a bunch of custom objects being instantiated. Then I have a main script (either local or regular script) manipulate those objects. (By using my custom methods)
I also have ‘events’ under those object modules like Heartbeat and BindToRenderstep upon instantiation and I was wondering if that’s a bad thing.
1 Like
Absolutely does. If you’re interested, my AeroGameFramework does all of this. It specifically has a category for objects, since they’re incredibly useful for game development. You could break down the code for that framework to see how it works.
4 Likes
That’s what I’ve been looking at. Lol
I’ve noticed that you don’t have any functions/events upon instantation like Heartbeat or BindToRenderstep. I’m doing this a lot. Is that fine?
Yeah I use those all over my code
Do you have an open source place for this? It’s kind of hard seeing the whole hierarchy n’ stuff on github.
Install the plugin and use it in a blank place. It will fetch all the files from GitHub for you
1 Like
Ok, did it
So, would you consider these “Controllers” custom objects or no?
Bc I don’t see many constructor functions in them.
DM’d
why not utilise a code outliner, such as JArchitect / SourceInsight to get a grasp of what structure is in those 5 scripts?
It’s not worth the trouble of installing opinionated tools to guess my intentions about code or expect that a single bug does not take down my entire game. Stuffing all your code into as little scripts as possible is an engineering nightmare and no well-meaning game, whether on Roblox or not, should aim for that.
If you have a cleanly broken-up codebase, it is easier for you to identify and isolate issues or work to be done on the code and you can clearly see the flow of code as well as the responsibilities of each part of your code. An outline comes fairly naturally with a properly componentised codebase.
The important part is though, that it’s not strictly just about how you can read it, it’s also about how you can maintain that codebase. I will not expect either myself or my collaborators to read scripts spanning multi-thousand lines with multiple responsibilities or make it difficult to reuse or join code together. An outliner doesn’t solve the underlying issues and practice problems that come with inappropriately consolidated code.
1 Like