How to avoid Enum + Inspector Spaghetti?

Unity Engine
, , , ,
1

I have an enum like


public enum myenum{

entryA,
entryB,
entryC

}

then i put it into a script

public myenum e;

then I modify the enum in the inspector to entryC.

If I go back into the code and develop the enum to

public enum myenum{

entryA,
entryD,
entryB,
entryC

}

My inspector field now displays entryB instead of entryC.

How can I prevent this?

while working with code I can always just very conveniently do

myenum.entryC

or


(int)myenum.entryC
2

I will suggest that it depends upon how you are using your enums. First question is why do you want entryD to be the second one? They are incrementing values where the actual value shouldn’t matter.

That said you can assign non-contiguous values. If you have gaps in the numbers you can insert one in the middle and you won’t affect the others.

3

You can explicitly set values to the enum so they stay consistent.

public enum myenum{
  entryA = 0,
  entryB = 1,
  entryC = 2,
}

Then even if you change the order or add an enum value in between it won’t change the serialized value.

1 Like
4

The other option is to avoid enums altogether.

Scriptable Objects or [SerializeReference] + some inspector support can generally replace them 99.99% of the time.

5

Well, there are only three ways to achieve this, broadly speaking.

You use system enums, but stick to how they’re supposed to be used. As technical enumerations or flag values, not for game design or high level identities which are supposed to be malleable over the course of game dev.

In this case, you have a strict and simple design in front of you, and all of your potential values are known in advance, or won’t change much in the future. This means that the fields are encapsulated, limited in growth, highly specific and so on. These could be dichotomies (like true/false) and other modal choices, operational combinable settings (think of switches and radio buttons that instruct the behavior of a state machine), or palettes of assorted values that are traditionally named (for example musical notes).

If you don’t restrict yourself in how exactly you’re using enums, there is always this lingering hazard of potentially breaking something very important, months or years from now.

You follow the advice from everyone, and don’t (ab)use system enums but instead use something else that is much more user-friendly, extensible, and plug and play in the long term. For example, ScriptableObjects are a good substitute, or some other (primitive) identities which you’re sure won’t shift around when modified.

You keep on using system enums, but don’t actually use the type enum, but instead make a different type that works almost exactly the same but is automatically serialized via string ids, letting you keep the benefits of an enum, but without the classic headaches of an enum.

For example ErsatzEnum.

2 Likes