It sounds like you have lots of variables because you have lots of types of production sites. I would not put them together if they are not actually common variables. That means you should not need a giant match
by type. Instead, one function (or factory object) per type may do a more focused job. You can make it work on a registration basis, like a dictionary mapping type to function/factory to call, so it's easier to add more.
If there are common variables, I'd group them into a common data structure, and leave the rest to specific ones, instead of putting them all together. For example, each production site might have a common pack of data which can be re-used, and then packs of specific data that are found in one or more sites.
If most of that data is constant, you could indeed set this up in a configuration file, resource, or create them in advance in a static helper script (which behave like quick internal config files if you use const
and preload
/load
).
Otherwise, if the rest needs to be set dynamically from variables of the game, then... well face it, assign them^^ No point in trying to hide them somehow.
The point is, if you repeat yourself in some areas, use static helpers, factories, eventually pack into components if a type has multiple types of common data attached (i.e attaching child nodes instead of inheriting, or attach resources to group datas, or eventually use duck typing magic to still have them together), find what's constant, find what's variable.
I think there is never a "best way" (as so commonly asked), but there are useful patterns to apply depending on your situation.