With my script, the developer will select what ore he wants and thats the ore the player will get. However to do this I need to loop through the added ores until it matches the select enum.
What I want to do is select a enum attached with a class/go which will eleminate the need for a loop.
public class OreVein : MonoBehaviour {
public Item[] itemOres;
public veins selectOre;
public enum veins {
Iron,
Gold,
Steel
}
public void Activation () {
for (int i = 0; i < itemOres.Length; i++)
{
if (itemOres[i].ItemName.Contains(selectOre.ToString())) //Is currently == not contains.
{
Debug.Log("once!");
PlayerInventory.Inventory.Add(itemOres[i]);
break;
}
}
}
}
Why don’t you just provide a more specific item array, such as an ore array? I’m just asking, since the array variable is already named ‘itemOres’ but is still of type ‘Item’ which could be any item. And you surely don’t want to have other item types in that array, which could happen by accident.
This would eliminate the need to check against ore names completely and you could just add the next item to your inventory, which results in an O(1) complexity.
Also, please note you’re adding a reference to your inventory, which could possibly be added multiple times. This may introduce bugs under certain circumstances.
With all the above, it’s probably worth thinking about a different vein (or even item) model.
For instance, a vein could hold a number indicating how many ore-pieces are left, and an itemtype-ID which identifies a specific ore type. You’d only track theoretical values instead of actual ore instances.
The Item’s in ‘itemOres’ are being added by human hand rather than a script. So it should be impossible for a non-ore item to be added by accident. There are no scripts adding to this array.
To be specific, I add a gameobject/prefab to the ‘itemOres’ variable (by hand) with has the ‘Item’ script attached to it. 'Item’s variables are tweaked to the appropriate values, item name etc. See below image.
Im wanting to have a single low performance script that can be adapted.
This is wrong from the perspective of imperfection.
Nothing is impossible unless you have a strict constraint (i.e. a more specific type constraint and given that the underlying system is flawless in this regard), especially when it’s done manually.
Instead of prefabs you could also use ScriptableObjects, they serve extremely well as data containers.
Without changing your system too much, I’d still change the vein class and make different prefabs out of it, one for each ore. As I said earlier, this eliminates the check for the correct type, eliminates the loop and you would choose the ore type by dragging the desired vein prefab. There’s no need why a vein needs to know about other ores when it’s determined to only serve as an XYZ vein.
If you still want to be able to choose it by dropdown, you can also do that and resolve the ore type in Awake() using a lookup/mapping for the corresponding ore prefab/SO. This would effectively allow you to place the same vein everywhere and simply change the enum which will get itself the needed instance to provide when it’s being mined.
Most importantly, both attempts would enforce you to do the mapping in a single place and if it gets messed up, you know where to start searching for bugs. It also reduces the number of ore references for a vein from currently 6 to 1. Not that I’d care about memory thaaat much, but it’s still worth a thought and helps to keep the inspector view short and clean. But the already mentioned maintainability and flexibility is way more important.
public class ItemOre
{
public veins Vein { get; set; }
//....
}
for (int i = 0; i < itemOres.Length; i++)
{
if (itemOres[i].Vein == selectedOre)
{
Debug.Log("once!");
PlayerInventory.Inventory.Add(itemOres[i]);
break;
}
}
But… depends on how often, when you’re doing this… the last option I provided will allocated an extra IEnumerable so I would recommend it for during-gameplay as it might trigger extra GC cycles.
