How many modulescripts are too much?

Help and Feedback Scripting Support
#1

i am putting together a vehicle construction game that lets you place objects and configure them to create certain vehicles. i am thinking of different ways to save specific configurations for certain objects. for example, a motor might have a speed config that changes how fast it turns when the vehicle is spawned.

currently, the game uses value instances to control configurations of each individual object, though the number of instances will grow intensely once vehicles have up thousands of objects (this problem already exists.) i am currently developing a rewrite for the entire game, and i have two other ideas for storing configurations, and i can only think of one of them that actually helps me out.

the first method is attributes. it uses just one instance to store as much data as i want. however, i can’t create “sub-attributes” which is greatly required in my game. for example, a sub-attribute might be the unit at which a configuration is set to. so the motors speed is 1, but then a sub-attribute determines whether or not that is 1 rotation per minute, radians per second etc.

my last idea is using one modulescript per block that holds all of the configuration data and its subattributes. does anybody know if this will be too extreme on memory? though it will take up many less instances, will the amount of data it contains make too many problems? (assuming a player’s vehicle has 2000+ objects, which might mean up to 200 modulescripts depending on how many objects require functionality)

this is the format at which i would plan to store in a configuration module (an object could have up to 10 configurations at a time):

return {
 speed = {
  value = 1,
  _unit = "rot/sec",
 },
}

edit: i did forget to mention that specific units for a configuration are not the only types of data to be used in this sub-attribute way.
some configurations may need to have set min and max values. others might need to store extra bits of other information.

i know that this is a lot to read and many people might be discouraged to answer, but any suggestion or feedback helps. i am currently thinking of using modulescripts, but i just want to see what others think of this practice before i try it out.

3 Likes
#2

“Too Much” may be a complicated term but if you don’t put too many of them in ReplicatedStorage or any replicated environment it should be fine, because putting them there means that the client will have to load more objects.

1 Like
#3

i am managing modulescripts very well in the games backend framework. i am talking about a modulescript per object on the players plot to store the its information. think of NBT data in a minecraft entity

2 Likes
#4

Even though it contains minimal data, still try to merge them together. That would be my solution.

1 Like
#5

i see what you mean here. the problem with that though is having to index through many other blocks when just trying to change or access the configuration of just one

2 Likes
#6

It can be hard, but it’s the best way to do it. Make a single config file for each object instead of multiple.

1 Like
#7

It is difficult to tell if your question is solely what the title says or if you are looking to overcome a number of challenges and want advice in general. Can you elaborate on the advice you are seeking?

1 Like
#8

depends on what they do and how much crumpy stuff is in there, like you have 1 module with 10 while loops it will lag, but if you have one that prints “hello” you need a lot of them to crash the game

1 Like
#9

i apologize for the lack of transparency there. i’m trying to think decent or good practice on storing data for many individual objects. i’m looking to trying to see what other people think is a better idea.

1 Like
#10

It sounds like ModuleScript-based OOP is a natural fit. You can keep all your modules in one place, don’t make unnecessary clones of them. You can always have ModulesScripts write to attributes if you change your mind. Personally, I find complex configuration in a Lua table to be much easier to work with than a prefab instance with hundreds of attributes. You can use any data types in tables and nest properties hierarchically as much as your system demands.

You’re right to leave value objects behind. They are absolutely the worst when you have thousands. Having all the overhead of an Instance for a bool… yuck!

4 Likes
#11

That’s a great idea, honestly. I have never thought of using ModuleScripts in this way as an alternative and it makes a lot of sense. I love the idea on tables too!

1 Like