When we were in the Wild West days of Aztec and to some extent Babylon, and unit prototypes were written in code and not imported, it was convenient to have them stored indexed by their name. Just refer to unitPrototypes["Warrior"] and you have a Warrior!
However, this is increasingly an anachronism, and isn't helpful when we have imported, variable unit types. I checked all of our references to unitPrototypes, and the ones that still use this style are all holdovers from those early days, and won't work reliably with "non-standard" unit names. More often, especially with newer code, we refer to the dictionary's values and ignore the keys altogether.
If we ever do need to find a unit prototype by name (perhaps for debugging purposes?), we can use a LINQ .Where or .Find clause.
So this refactor is basically to convert this data structure into a List.
When we were in the Wild West days of Aztec and to some extent Babylon, and unit prototypes were written in code and not imported, it was convenient to have them stored indexed by their name. Just refer to unitPrototypes["Warrior"] and you have a Warrior!
However, this is increasingly an anachronism, and isn't helpful when we have imported, variable unit types. I checked all of our references to unitPrototypes, and the ones that still use this style are all holdovers from those early days, and won't work reliably with "non-standard" unit names. More often, especially with newer code, we refer to the dictionary's values and ignore the keys altogether.
If we ever do need to find a unit prototype by name (perhaps for debugging purposes?), we can use a LINQ .Where or .Find clause.
So this refactor is basically to convert this data structure into a List.