i am creating a rewrite for my game. players can place up to tens of thousands of objects to create interactable machines and vehicles.
almost each functional object will hold a configuration. what are the pros and cons of storing these configurations in a modulescript (red) or as an instance in a folder (blue)?
keep in mind that i want each block to also maybe even hold some type of coding/program. a modulescript may benefit this situation.
this is what i can think of so far.
modulescript pros
-less instances
-could support coding easier?? cons
-memory???
Normal people would use attributes… ValueInstances are only used when attributes cannot support a value they want to store, such as an object reference.
Another radical idea, store all the configurations inside a single table in {[Object]: ConfigurationTable} format. Whenever you want to read/write an object’s config, you just index that table for the object.
thank you for your reply. based on your information, i might try going towards using attributes.
i am still unsure of whether or not i want the code to be global or local to the object (global meaning there is only one thread running that accesses all of the objects in the vehicle, local meaning that each individual object can be locally scripted)
Ideally it should be global, because ideally there should be single “manager” script that does everything building-related. Anything else that wants to do something with the player’s creation should weave through the building API for organization purposes.
i know that i am bumping this back up, but i think i’m going to use modulescripts. this is because a lot of configurations need subconfigurations like “units”. for example, a player can change the speed of a motor, but they can also change the unit the motor is running on like “radians/sec” or “rotations/min”. i’m just a little worried about up to like 1000 modulescripts in a players vehicle at once (servers fit 10 players). i guess at the same time, attributes would take up just as much data, i’m just not really that sure.
They should all use the same unit internally? The player can choose to enter a motor’s speed in either rpm or rad/s, but at the engine level it is always going to be rad/s, because that’s what the constraints use. Seamlessly convert the unit to the universal one after the player entered the value. You can keep track of the unit the player used in a datastore and seamlessly convert it back to be displayed in the config UI when it’s being accessed by the player.
Side note, allowing players to enter different units could be a design flaw. There’s a reason why physics, engineering, and science in general all use SI units. Even when the US is still “imperial”, in terms of science and technology it’s going to be metric. Having a consistent system of measurement is important for any technological endeavors, including your engineering game. That being said, rad/s is the conventional unit and you should stick with that.
You could always just benchmark it. Create thousands of modulescripts versus thousands of attributes. Measure the difference in reading/writing config data and the memory usage. In fact, just saying that should already give you an idea. You are creating thousands of brand new instances, compared to thousands of method calls. There’s going to be a trade-off somewhere and you’ll have to find it and see if it’s worth the cost.
my goal is to let the player choose which unit individual objects run off of depending on the certain situation that object is in. the only point behind it is QOL for the players. i’ve talked to my community about different units and they seem to agree that it’s best for them to decide for each individual block.
If you’re going to go with user choice then it might be easier to do it as a single game setting rather than specifying it for each individual part. Then when a user inputs their value it gets converted based off whatever their global unit setting is.
another problem is that many configuration values may also need to have minimum and maximum values to be entered. different types of configurations are going to have to store different types of data. the unit example is one of many.
i apologize for bumping this up. i did make a more recent post that goes more in-depth about this topic right after bumping this.
