Another slightly silly question: would using this approach make it harder to add new resource yields? Suppose you wanted to implement steel and synthetics; would that require additional mods of the SDK, or would that already be done so one could simply add it in XML?
Well... the short answer is: No, you would need to do SDK work.
The reason: The yield types are predefined in the CvEnums.h file in the SDK because under the current system, the three yields are processed in different ways and thus you need to be able to refer to them up front... so, for example:
I'm not great with proper coding vocabulary, so pardon me for putting it into lay terms, but when the city calculates the food difference between what you have and what you consume, it has to get the yield rate value in the yield rate array for the food index, that index value is stored as YIELD_FOOD.
The problem is that if that enum value of YIELD_FOOD is not predefined in the SDK, you can't just stick it in there with the idea that the value will be determined later when the game is run and the XML is loaded. It simply won't let you compile if you haven't defined that value.
However... it is not beyond the realm of possibility that the code could be generalized, with a bit of work, so that you would get rid of those inherent distinctions between production, commerce and food and make everything interchangeable with the actual behaviors and properties for each being defined by modders in XML.
There is something to be said for this... in this case, you could have a general consumption rate, general yield rate and inventory per city rather than specific values for the food consumption, food difference, and stored food values. This would allow, for example, if you were to create a new yield called Power that would be able to be consumed by the population, or a Fuel/Oil yield would be able to be consumed by the population, and it would require no actual additions to the code with new functions, etc. to do this once the system is created.
I don't know that it's necessarily possible, but I think it's quite probable that it can be done. Then you'd just be able to add new yields into the XML without having to make SDK changes. The only thing that would need to be done then is changes in python to show these new new yields in the city screen, which is relatively simple although beyond my knowledge.
However, I don't know if it would provide solutions to our resource problems because yield modifiers and changes are
everywhere in the code... there's dozens and dozens of instances where the yields are run through, and there are many arrays for storing yield values. For every new yield you add, that array gets larger. For every yield you add, those loops need to run through one more time... so for every yield you add, that's a tiny bit more system resources needed.
But you can also make the argument that you will need even more arrays to have quantified resources, and you would need to add in all those same modifiers for resources, and that in the end, to create a separate but virtually identical system for quantitative resources would actually consume more resources... So turning all 40+ bonuses into yields would be a bad idea because you'd be basically increasing the required memory and processing time by 10 fold (this would not be
total processing time but just processing related to yields which could still double total processing time I would think). Adding the most important strategic resources, however, might work... if you keep the total number at about 15: the 3 current yields and maybe 12 strategic resources.
Is this the best route? I'm not sure... but I will say this, a separate system for quantitative resources will parallel this quite closely, and it might be better to try to get a national inventory system for yields complete and running smoothly as a dry run to a quantitative resource system... and at the very least, if the quant. resources seems like too much work or too difficult to pull off, this would provide the fallback.