Single ModuleScript storing configs for everything: is this a good idea?

hello everyone! i’ve been developing a game inspired by bee swarm simulator and i want to know if what i’m doing is a good practice or i should resort to a different method

in my game, i have a module called GameConfig and it holds configuration for everything that needs configs such as tools, fields, etc. it looks something like this:

local module = {}

module.Equipment = {
[“ToolName”] = {
Cooldown = 1,
}
}

return module

sorry for the bad formatting, had to type all of this up on my phone

5 Likes

No, please use multiple ModuleScripts to split your configurations based on feature type so it’s more accessible to you when developing. You can have a script consolidate all your configurations into a table if you’d like during run time but during development keep them separate.

Example: I use over 500 ModuleScripts to individually define configurations for sounds. I also have configurations for categorically-split manual localisation keys, math, NPC information, inventory, chat titles and more. My codebase of 2.5K+ ModuleScripts is almost evenly split down the middle between configuration files and actual game code.

2 Likes

2.5k modules?! and it isn’t a hassle to work with?

also as an example i would split tools into their own, same with fields, flowers, world values like regen speed, etc?

The only hassle I’ve ever had to deal with is some of our legacy content since the original codebase was built as a monolithic script, meaning everything was in one script, and breaking even the slightest thing would break the whole game. We have internal tooling (e.g. plugins) and smart division to keep things clean and continue to iterate upon it as we update.

Here’s an image that shows a part of it for the current update. Still needs a lot more work though.

You have the right idea though; all those should be separate configurations. Frankly you could split them even further and have one configuration file per thing; for example, if you have 5 fields, then 5 ModuleScripts per field, and one to collate those configuration files which also helps external scripts grab those configurations via a get method or something. Example:

1 Like

thing as in the configurable value? if so, something like this:

image

also should i structure the modules like this? or how you have it?

local module = {}

module.SizeChance = {
	Small = 3,
	Medium = 1,
	Large = 0.6,
}

return module

and one more thing, should i split each mechanic into their own server scripts? i know that question has been asked for a while, but i would like to hear from you since you know your stuff :sweat_smile:

sorry for all the questions btw, i am a max prestige overthinker

1 Like

Any way you like is fine; you will have to use your head a lot and apply some thinking to what you think would feel best for development. For me personally, SizeChance and ColorChance would probably be too small to be fit for their own configuration files so I’d put them in with Rose.

I usually just think about how appropriate it is for something to exist as its own ModuleScript or not and go from there. For items, one ModuleScript is typically enough to contain all the configurations for that specific item. You can split it down further if you feel it’d be justified, such as a subconfiguration that’s just really huge. In the example I posted, they weren’t enough to justify any splits (besides the fact that it’s also an old ported configuration so it’s all one table).

For mechanics, same thing applies - I always split. The only thing is that I use single script architecture so my game mechanics are also ModuleScripts and help in controlling code flow and easily writing defensively architectured code where I don’t have to strictly rely on execution timing. It’s a bit more difficult but not impossible to do with Scripts/LocalScripts.

My team’s thinking is just “do first, ask and clean later”. Does help overcome some of the thinking barricades and sometimes the first thing we get down is the way we like it and works well. Don’t get too trapped in the prettiness and thinking, but definitely do put a bit of thought into it.

3 Likes

amazing insight, thanks so much!

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.