Is there a commodity you always have to search before you buy it?
Are you a chemistry buff who would like to drop some knowledge on us?
Now’s your time to complain!
One minor but recurring piece of feedback is that the commodity categories on the markets aren’t sensible or accurate in some cases. There will never be a perfect solution for all commodities, but we’re taking suggestions and this is now the official place for it! Any commodities that are in the wrong place? Redundant categories? Incorrect nomenclature? Let us know.
Is there a strong design decision limiting resources to a single category? Could H2O be listed under both fluids and chemicals? Could oxygen be listed under elements and gases?
Could categories be hierarchical? Agriculture => raw produce; fertilisers (also chemicals, compounds).
I know ticker backgrounds are determined by category currently. Is this something that is planned to change?
what @Prdgi said. I know it’s confused me in the past. Like if I’m looking for H, do I look under gases, or elements? Technically, elements would be more accurate since there’s nothing saying you couldn’t have liquefied H. But some kind of crosslinking would be nice.
Very good point. I don’t know if this idea clashes with what’s planned, but if it doesn’t, I would appreciate it a lot as a player. I’ll put it on The List!
You could abstract the categorization away from resources themselves.
Rather than being assigned a category, resources could be assigned “tags”. A tag system would allow multiple tags to be applied to a single resource.
Then, tags themselves could organised into a hierarchy of categories.
Hydrogen could be tagged as “gas”, “element”, “combustible” etc…
“gas” could be a child of “physical_state” (as opposed to digital, which would include software) etc…
Really, by removing the direct categorization of resources, you can have a far more flexible system.
Hell, you could then create abstract recipes:
GRN, MAI are tagged as “carbohydrate”. NUT, VEG tagged as “fats”, BEA tagged as “protein”. These three tags could then be children of “edible”.
A ration recipe could be configured to include 3.0t of “carbohydrate”, 2.0t of “protein”, and 1.0t of “fats”. The player can use the same recipe (function) to pass different inputs (arguments) to achieve a result (return).
Then, you need never worry about having to add a whole heap of recipes if you ever want to expand the agriculture market.
I feel like generic recipes are one step too far, since they would eliminate the need for concrete commodities altogether. Why have NUT, VEG and BEA in the first place when they are all used the same way as “protein”?
However, I would very much like multiple categories (or tags, which comes down to the same thing) per commodity.
Your assertion is entirely correct within the current scope of the game. Most resources exist for a single purpose.
The ration chain currently offers pseudo-diversity - the crops are just there to offer variety, but they all just make rations anyway. You could replace the entire T1 agriculture sector with 3 resources - 1 for turning into rations, 1 for making clothes, and other for making carbon. 7 resources could be reduced to 3.
Where diversity really shows is when there are actual differences between the resources. For example, if crops had properties such as “carbon_content”, “water_content”, “protein_content”, “fat_content”, “sugar_content” etc… then there is actually a point to the diversity. Crops with a high “carbon_content” would be best for incinerating into carbon.
With higher diversity between crops, a generic ration recipe becomes viable, as players can mix and match crops to achieve the minimum nutritional values, say, 60% carbs, 5% sugars, 5% fats, 30% proteins.
All that said, if higher diversity between crops is not desired, the whole idea is moot. If resources are planned to only have a few, select uses, then generic recipes make no sense whatsoever.
I lifted it from one of my own designs where resources could be added on the fly via in game processes. Ergo, the ‘recipe’ system needed that layer of abstraction to keep the dataset manageable. It was designed to simulate domestication of crops and how plant properties were changed over time.
I was unsure how far you wanted to push with complexity.
A lot of my issues could be side stepped by having a “search” function in the commodity exchange; in stead of guessing what you were thinking when you categorized the items we could simply search for them.