|
|
|
 |
Reply From: |
Zylann |
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.
Thanks for answering!
Actually yes, every variable is in reality a constant, and it is a common one (meaning that every ProductionSite has it).
Right now i created this structure: in the parent node i decleared a set of arrays, one for each constant, and in every array is stored the value for each type of production site.
After I instance a new empty ProductionSite template, i define it using the values stored in the array of the parent node.Here a rough structure to understand:
parent node:
const type=["well", "field", "mine", "orchard"]
const output=["water", "grain", "stone", "fruits"]
const whatever=[...,...,...,...]
ProductionSite node:
var type
var output
var whatever
func define(n): #n identify which elements of the arrays to use
type=parent.type[n]
output=parent.output[n]
whatever=parent.whatever[n]
It works as intended, but writing down all the properties of each production type is a pain when the arrays get longer and longer, and easier to do mistakes.
Maybe in the future i’ll write down a piece of code that does the same thing that define() does, but taking the data from an actual excel file (i guess it’s fine if slow, it should be done only once at the beginning)
Andrea | 2020-05-11 17:57
