[Fyron]

It does allow multiple components to exist with the same name though, such as different versions of a component based on the racial traits you possess. The game could store some sort of checksum of the data fields for each component and throw everything into a hash table, alleviating the need to store an array-type index. Unfortunately, this scheme would be broken by modifying the values of any item.

Anything other than an array-type (or hash table) data structure would probably lead to horribly slow access times. Imagine having to potentially scan through the entire list to load the pictures for each component shown in the ship design window. Or worse, the component display sections when viewing a ship design's details. You could reduce this by checking each item you need displayed for every item accessed in the list, but it still won't be pretty.

There could be a balance tree storing the components by names, allowing multiple items to exist with the same name. This would allow for far more rapid access times (on the order of the length of the longest component name), but it would be tricky to properly handle multiple components with the same name. How do you differentiate between them while still allowing the data fields (and the name itself) to be changed and maintain savegame compatibility? You could disallow name changes, which is probably ok. But if you allow other fields to be changed, you can't very well use them to differentiate between different components with the same name. Since the tree would have to be rebuilt after reloading the game, we are back to a scheme of ordering components with identical names by position in the file. They at least would have to be kept in the same order, with any new copies added after their position in the file.

You could have some fancy "array" that is indexed by component name, but you run into the same problem for components of the same name.