Would it be bad practice to use a module script to store variables and services and then use another script to do the actual processing?
e.g. ModuleScript1 just contains all the variables for a Gui and also services like Players
another script then using the variables and services.
To me, the inefficiency is that I could be declaring things that I never use in that script.
But if I am using only 1 modulescript it means I don’t have to keep redefining the same service across variables. Which would be more efficient (at least looking like it). I am not sure if the variables would technically be pointing to the same place in memory anyway so it might not really be more efficient in terms of performance but it might be better overall anyway.
No, it’s not bad practice. I’d personally recommend it strongly based on the kind of system you’re trying to make just as long as it actually makes sense to do so. If it doesn’t make sense then you really shouldn’t commit to it. The answer will change depending on the context, there’s no single answer here.
Just as an example, I have over 500+ ModuleScripts that represent data for sounds and music in my experience so that I don’t have sound instances lingering in the DataModel. It’s a practice that’s helped me reduce memory use by several hundred megabytes.
Could you elaborate on “I have over 500+ ModuleScripts that represent data for sounds and music in my experience so that I don’t have sound instances lingering in the DataModel.”.
Right: so I literally mean that there’s over 500 ModuleScripts dedicated to storing data for sounds, the figure’s not an exaggeration. Just a small peak at what that looks like:
Normally in an experience you might find Sound objects in an SFX folder but for us we only keep pure data about a sound here so you can think of each ModuleScript as a descriptor for a Sound object that can later be loaded into a Sound instance and played. For example, the contents of the Announcement ModuleScript at the top of that list:
So in that regard, I literally do mean I have over 500+ ModuleScripts that represent sound data.
Why do I do that? When you have actual Sound instances in the DataModel it’s going to consume memory like any other asset that needs to be downloaded from the site so the client can interact with it be it visuals, audio or whatever. The big problem is that it’s just idly consuming memory and you’re probably not going to be running those Sounds at all times.
It’s less expensive to keep pure data because at that point the only expense you have is the instance which is minimal. The rest relies on your code and you can just build a system to load up sounds you want, play them and then remove them when you don’t need them anymore. Audio, especially long audio is fairly memory intensive so you don’t want to keep Sound instances lingering in your environment. Removing them frees up that memory, plus you get some nice real estate on join times.
Yep. There’s a lot you can break out into ModuleScripts if it suits your needs, especially for systems where it would be easier to just write a data ModuleScript and then your systems can automatically register data given a valid format just like the sound example above.
The engine can read code very fast so it’s not unusual to have lots of ModuleScripts in a serious project whether it’s for actual code or just to store something. Example of a production-level place:
Just sometimes developers might see that and think about storing everything in data modules and it’s probably not applicable for every use case. Some things don’t need to be forced into data formats, other things might work a lot better that way. All depends on the system you’re trying to write.
A production-level experience, PWNED 3. I just picked out a map at random and opened the Lines Of Code plugin on it lol. It’s certainly a big number but in terms of how it performs it does as well as any experience that has a lower number of scripts.
