Enums! (an introduction to enumeration types with Unity)
I think there often comes a point for a budding Unity developer when we want to, say, specify something in the inspector to give an object a custom type of sorts. When starting out, we might leave a serialised private string field or we might leave a public string field for us to enter the type in the inspector. For instance, lets say in our game there are four ‘Items’ we can buy at the store, and these can be: ‘Mocha’, ‘Latte’, ‘Cappuccino’, and ‘Croissant’. With this system, I might then need to type out the one I want from this list, hope I always spell it correctly, and then find out which type the item belongs to using an if or switch statement:
This can be fine on small scales, but what if we need our colleagues to enter these values in, and what if we need to drastically increase the number of items that can be bought? The risk for human errors goes up very quickly with this: it’s only inevitable that someone will mistype, mis-capitalise, or mis-hyphenate these when writing them out, making them unrecognisable to the program. We might then wish there was a way to remove the need for typing these out each time, maybe even have a dropdown of all the valid options available in the inspector. That’s where enums can come in, letting us define exactly what types are available and accepted:
Here, we’ve declared an enumeration type called “ItemType” and have populated it with these four possible values. By declaring this, we can now create a public or serialised variable of that enum type:
This’ll then appear in Unity’s Inspector as a dropdown, containing the four possible values as options:
Some of the real potential of using enums is that they allow us to use the same class in different ways depending on the value of an enum variable. For example, let’s say we have red enemies, blue enemies, and yellow enemies. They all have similar characteristics (a set number of lives for instance), but they look different and perhaps have different movement patterns. We could create a dedicated script for each of these enemy types, and indeed there will be times when it’ll be cleaner to. But if the variations are fairly slight, we could just have a single enemy class, then use and EnemyType enum, and perform the desired logic for each:
We could now just place this script onto an enemy GameObject we’ve created, duplicate it twice, set the enums to one of these three types, and then turn these into prefabs. Now what we have is one class which determines the way these three enemies are setup and how they behave, without us needing to write out separate scripts and potentially rewrite lots of code.
Since we’ve made this enemyType variable public, we could also access this from another script, check to see if it’s of a particular type, and then perform logic accordingly. Again, there will almost certainly be times when it’d be better to create dedicated scripts, especially when the enemies types work in very different and fairly complicated ways.
As an important note, each element in an enum is essentially just a constant integer value represented by a more human-readable identifier. By default, the first element in an enum will be ‘0’, the second ‘1’, and so forth:
This can be problematic if we were to then, say, add in “Muffin” between Cappuccino and Croissant. Any instance of ItemType.Croissant in the inspector would become ItemType.Muffin (since that’ll now be the fourth element in the enum). We can however, assign hard-coded integer values to get around this:
This way, even though “Muffin” will now appear between Croissant and Cappuccino in the Inspector our previously-assigned enum variables won’t be shifted.
There are a couple other nifty things we can do with enumeration types, such as making use of the “Flags” attribute to assign multiple types/elements to a single variable, but I’ll try to cover that in a separate article 😉 Hope this helps in getting started with enums!
