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:
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.
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:
thing as in the configurable value? if so, something like this:
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
sorry for all the questions btw, i am a max prestige overthinker
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.
