How to properly differentiate between ModuleScripts in Roblox Studio?

Help and Feedback Scripting Support
, , , ,
1

A common thing I’ve picked up on is that modules, packages, libraries, frameworks, classes (although not usually I think as OOP turned out to me to be quite straightforward), and even utilities, are all often confused with each other, and even after doing some research, it still eludes me how I can keep up with some of these definitions, considering some of Roblox’s implementations that can land further confusion on many that use Studio to develop…

An example of something that got me heavily confused with are how to organize between Roblox packages and modular packages; in the case of Roblox’s system, packages are used to serve as the main central points for imported instances (those things with PackageLinks that is), whereas packages in programming are way more different; from research I’ve taken recently, I’ve read that modules contain sets of methods or functions that are to be used elsewhere, packages are collections of modules, libraries are collections of packages, and frameworks essentially act as the central points that us as developers would use to power general code workflow - collections of libraries - so this therefore opens up a massive bracket to confusion, especially considering that I still don’t know how true any of this is at this point…

Even if this all is true, how are we supposed to separate these kinds of modules, from systems that have already been made, the key one I’ve referred to throughout being modular packages from Roblox packages?

I also don’t know whether or not using a “Utilities” folder was a correct practice of more or not.

Furthermore, I’d like to delve into the depths to secure a better structure of how ModuleScripts should be organized, as yes this is preventing me from continuing making games for the time being.

(I apologise in advance as I created this post originally under Development Discussion which was incorrect of me to do.)

2 Likes
2

packages rn only work inside your games as far as i know.
You seem to not understand what modulescript even is.
Its just so damn stuipid and is literally like a function that runs once and every other time it gets called it returns already cached value.

3

No, I know what a ModuleScript is and how to use them, that is not the problem here. I’m more so asking about the different types of module scripts that are being used, since many people often talk about frameworks, libraries, aforementioned, and the definitions often get mixed around/are not clarified in much detail. I’m also asking about how modular packages should be separated from Roblox packages (which you can publish), I’m thinking of just having it another folder in an assets folder, not as an open thing, but the lack of clarity over that again is something I’m unsure about.

I hope this has cleared up some confusion.

4

Packages are not specifically made to ModuleScripts.
We dont really need to roblox to be bloatwared to have each class have a separate “Package” version.
Packages literally can be made out of all serializable instances as far as i know pretty much; From Models to Scripts and so on.

5

This may be not entirely relevant, but don’t overcomplicate your work and organization with packages, libraries, frameworks, and so on. These are not always useful and don’t necessarily improve organization, reusability, or performance. Keep things simple, with straightforward scripts and modules, that’s all you need to make games effectively on Roblox.

Most front-page games you see on the platform don’t bother with all these things. At the very least, the only useful features are simple and reusable frameworks for certain systems, such as data stores, tools, vehicles, and other potentially complex and large systems. However, overall, about 75% of a game’s scripting is made up of simple scripts and modules.

1 Like
6

Thank you for your input. Yes it isn’t really relevant here, however please know that I’ve considered this prior, and that I’m not planning on necessarily using many frameworks and things, however I do love to use ModuleScripts more generally speaking, and I’m more looking ahead into being ready for change - making my games have the required folders for anything and everything ready for any sort of change, as I currently manage a lot on the back end of a team I’m in. Consider it sort of like how, you only really get one shot at making something, like Roblox in example. Anything they add to their API, they can’t really remove, or don’t tend to change, as that would result in further work for programmers fixing up their once working scripts. Yeah I’m trying to do a similar sort of thing, except it’s been going horribly my end as I’ve had to go over things like my game’s folder structure and how I’ve organize my modules, numerous times by now. I want to put an end to having to do that by settling on a fixed structure, using widely used terms to separate my modules, and making sure that those modules are all correct for what they’re individually put under.

1 Like
7

If I’m getting you correctly, it sounds like you’re struggling about organizing your workplace and standardizing your workflow,—especially with all the terminologies that you hear get thrown around from left and right—is that correct? I just want to make sure before I try to answer you. :slight_smile:

8

That is correct, however I’m leaning more towards organizing general use APIs/ModuleScripts as there are many different terms that relate to ModuleScripts, and although I do sort of get the general gist now from having done the research, I’m more so wondering how we should do it in Roblox, though I’m mostly only getting at the packages thing that I mentioned before. Also to do with any other essential folders I may need to have, if any, ready for future change.

1 Like
9

Alrighty! Here is my attempt at clearing things up for you. First and foremost:

Your understanding of these terminologies is good enough! Though, do understand that this is only half of the “organization” picture. To be concise, what ModuleScripts (e.g. those packages, libraries, etc.) organize is code logic and responsibility.

I mean, yea; a module that’s made to manage inputs should only be concerned with managing the inputs—nothing more, nothing less. It should also be named aptly, like InputManager (though packages that do something similar can choose to break this rule if they want to brand themselves to be distinguishable from other similar packages, besides, you can always rename them if you want :slightly_smiling_face:)
P.S.: Formally, this is called separation of concerns. :kissing_smiling_eyes:

But wait, we’re only talking about one module right now, a single responsibility…

You’ve mentioned that you’re working on a game, and a game obviously doesn’t just consist of a single facet of development; especially if it features various gameplay elements! Not only are we talking about the implementation of their respective system, we could be talking about managing controls, camera, data storage, UI, client-server communication and so much more!

It also sounds like you’re struggling with getting the correct names for folders to categorize these scripts into; this is also the other half of the picture I previously mentioned, so lets talk about that!

While there isn’t a global standard format for structuring & categorizing modules, they usually go by the following:

  • core - where we put fundamental ModuleScripts— the building blocks — things everything else uses that don’t depend on other high-level logic
    e.g. central debug/logging tool, global config values, schedulers, etc.

  • system (or systems) - where we put ModuleScripts that implement actual functionality — systems or features, whether it’s related to gameplay, backend, or etc.
    e.g. custom character control system, combat system, inventory system… you get the point

  • util (or utils or utility …or utilities) - often the most misused; but this is where we put ModuleScripts which are pure, reusable, stateless helpers. They don’t track game state, don’t call systems, and don’t manipulate UI. They just solve common problems.
    e.g. a custom math library, custom string manipulation library, etc.

  • ui - pretty self-explanatory, this is where we put UI-related stuff*. If this folder is going to contain a different classes of stuff, like GuiObjects, ModuleScripts, and LocalScripts, consider doing further categorizations, like making two folders called components and scripts where you put exactly what they say they should contain.

The last part about “further subcategorizing a folder” goes out to all of the aforementioned folders, feel completely free to do so if required! Other than this, by no means do am I trying to say that you should strictly follow this way of categorization, but only mentioning them since they’re common place and for the most part, good enough!

I hope I did a good job at making things clearer for you. I mean after all, I spent almost 2 hours writing this… Sorry for taking so long, I haven’t written something this long for a long time. :sweat_smile:

1 Like
10

Man I really appreciate the time you put into the post! Thank you dearly, this has cleared up the most part of some of my confusion. However, I’m more so looking into how to get past the packages issue over anything else at the moment. I understand that no organization system is completely correct, or better than any other one, as they are all different, however I’m moreso looking at the general base terms here…

All around the place, I look around and see the terms “modules”, “packages”, “libraries”, “frameworks” - in this case, after doing the research, I concluded that those terms in themselves all relate, as aforementioned, as you go up the definitions, one definition is just a collection of the previous. I get utilities however, but after using AI and things, aren’t utils/utilities basically the same as how one would describe a module? I’d post a link to a place where I got these definitions, however I’m afraid that I’d get flagged for posting a URL that is not permitted, so I’ll go and link below what was said.

Content Researched:

Module

Is the smallest piece of software. A module is a set of methods or functions ready to be used somewhere else.

Package

Is a collection of modules. This may sound funny, but usually what a package does, is gather a number of modules holding in general the same functional purpose. Making it easier to include all the related modules at once.

Library

Well library at it’s core, is a collections of packages. It’s purpose is to offer a set of functionalities ready to use without worrying about the subsequent packages. So a library is what you include when you want to add some functionality to your code. It does not force any coding style on you either.

Framework

It’s a set of libraries. But this time, the framework does not just offer functionalities, but it also provides an architecture for the development work. In other words you don’t include a framework. You integrate you code into it. He is the wire frame of the project. That’s why a framework forces its coding style on you.

So yeah, I can understand the above categories you mentioned @seanjosep39, however I can see that you haven’t considered some modules that appear to be “nested”, such as frameworks that contain a collection of libraries, in example.

Really appreciate the time you spent writing however, thank you!

[Edit: I don’t mind integrating more folders, or any of the things you mentioned if they are general use, however if they fall under any of the four categories I’ve mostly delved into then I’d much rather have sub-categories inside them, unless they are completely separate. Additionally, I’m still stuck on how I should separate Roblox packages from modular packages - perhaps putting them in under a main “Assets” folder would do? I’m not sure that’s appropriate however.]

1 Like
11

Ahh, your understanding definition of the word “module” is a very broad definition of it. While it is true, it isn’t exactly helpful because it is an umbrella term, it doesn’t describe anything in particular. “module” just refers just refers to any reusable piece of code logic.

Utility modules are different because they are modules that are (so we actually have a stricter definition here) stateless and generic that just solve common problems. Like, they aren’t tied to any theme, or quirk, or game mechanic; they just solve.

I don’t think the distinctions really matter for the most part. If you feel obligated to make distinction, feel free to do so as long as it doesn’t become a pain in the bum to deal with programmatically. In my opinion, if the package’s class is consistent with the rest of the folder’s items, it can belong there.

Again, sorry for taking so long despite being such a short amount of text. While writing this, I went under a lot of self-scrutinization and rethinking…:upside_down_face:

1 Like
12

Please don’t apologise man, I really appreciate the time you’ve spent answering today, and the fact that you’ve gone over to make sure it all makes sense - that’s better than what I do! :happy2:

I also understand a bit more what you’re on about now, and at least in the case of Roblox Studio, yeah probably “Modules” isn’t a great folder name in general. However, I still wonder whether it’s better to stick to the general, agreed conventions for the different types, or to replace certain ones. I have decided on adding “Packages” under “Assets” in my storage services, however I’m not really happy as there isn’t really a single definition for what is what, which could get frustrating. You see things like Wally (package manager), and wonder where you’d put assets generated by a manager like that, then think where would I put Roblox packages, that’s what’s annoying me. Something like TopbarPlus is a general-use Roblox package, however all it is is a Folder with an “Icon” ModuleScript inside of it, which has constructor(s) - therefore something like a “Class” - however I don’t know whether or not to put that in a “Classes” Folder, or to put it inside “Packages”, as it technically is either. Then again, TopbarPlus does have a lot of modules and other things under it…

I like to have my folders often named uniquely in general, and have only specific instances under the folders of those unique names, so yeah it may end up that I’d stick with the setup as is, unless there is a better way… shame that Roblox had to name that feature similar to something else already existing, though it is what it is I guess… I might just in the case of Roblox, to save more confusion, do what the AIs are telling me - to ignore the “Packages” in the sense that now it would be “Modules” → “Libraries” → “Frameworks” (ignoring packages there), however the issue arises when you convert the system to something out of Roblox. I guess maybe perhaps well, there’s nothing you can do about that then…

And uh, as said before @seanjosep39, I might keep the “Modules” folder, and have “Utilities” as a sub-folder of that, due to the research over those common terms, to maintain consistency within things. Thanks for your suggestions though, I’ll also add stuff like “UI” too!

1 Like
13

After much thought, I’ve concluded that I’ll eliminate the use of modular packages, and reason why is: Roblox doesn’t get that much in-depth into systematic architectures really, I really only think that Modules → Libraries → Frameworks are needed. I’ll mark @seanjosep39 as having solved this as he provided a clear and concise method for how he organizes things. If you have any more ideas please don’t hesitate to let me know your thoughts!

2 Likes