I have the slight feeling that this should’ve been posted in Code Review, so please tell me if it is.
I’m working on a game that has multiple weapons with their own abilities, and I’m using modules to handle it. But I have no idea if how I’m doing it is… optimal, I guess you could say.
Note: There are going to be at least 4 swords in this game. So duplicate LinkedAbilities and LinkedSwordProceeds about 4-6 times. If anymore info is needed please askkkk
There’s nearly zero performance impact for using multiple ModuleScript instances like this. What you’re trading on here is organization, so if you find this setup easy to work with, use it!
You could easily get away with dozens of ModuleScripts per sword without noticing anything in terms of performance. Hundreds, even. Maybe not thousands.
i see no code to review, yet
i have never heard that game breaks because of “too many modules”
what would be in the duplicates?
as you might suspect, keeping same code there is not a good practice.
Each duplicate would have the same format but different code. (that makes sense right?)
Even if thousands, I doubt anyone would need so many 
if it’s comfortable for you to use then it’s fine, you won’t notice any performace issues because of these modules, don’t get stuck trying to hardcore optimize everything, you will almost never finish anything otherwise
I already barely finish anything
As long as this isn’t a bad way of handling things (and I’m comfortable with the setup) then I’m good.
learning anything from projects, whether you finish them or not, is always a win imo
Wait abt 2 hours then I’ll like ur post
stinky like limit
hurry up Robloxxxxx
That’s not true about optimization
It all depends on each case
About organization, I would say “balkanization” of code is what ruins organization
compared to a clear code in one place without unnecessary splitting.
As for OP, I think you are not creating a very good architecture, and instead you should store abilities in a single table if you are going for a centralized architecture requiring a lookup/initiation.
Does not matter whether an array or dictionary; it depends on architecture (array is preferable if it’s not name-dependent logic)
My personal architecture is a module script exposing such tables or functions that edit upvalues
So I could, for example, in runtime modify said logic
My game architecture is based on feature flags, so not all content is loaded instantly and may load/be inserted into the game data model only when feature flags are set, for example (useful for seasonal event triggers or such)
is it about a table with constants and modules require the table that return stubs if feature is disabled?..
No not like that
I talk about having architecture that exposes runtime upvalues via functions to edit
The feature flags is just MainModule require or asset inserted via assetservice if conditions are met (e.g. winter content if server detects on launch that its winter)
This way game is pretty much autonomous handling this content without bloating itself unnesesarily
This way its easier to register item logic etc
It is true that the amount of ModuleScript instances in a particular place strictly does not matter – what you put in them is what matters, which isn’t the question OP asked.
I agree with you that an excessive number of ModuleScripts does imply other issues that might be causing or contributing to performance issues, and I also agree that avoiding “unnecessary splitting” as you put it is 100% a good thing.
But I reiterate that OP’s case as described is not inherently problematic, so long as they understand and are comfortable with its organization.
I usually create a whole network of modules and make my entire codebase modular so that I don’t have to repeat require calls, and can use modules and information from other scripts without events.
I have a loader that loads all the client/server and shared modules.
Then, you have two modules like this
Movement
Stamina
Both can communicate with each other other, access eachothers variables, and call functions in each-other. But both are seperate modules.
And if you want, you can just create a seperate table inside the module to act as a Private table that other scripts cannot read.
Just makes it comfortable for me like C# because it feels more secure, easier to work with, and you can seperate features for easy modification and readability.
Otherwise this is good.
