When working with variables, as the gamedev joke goes, thinking of a good name for them is one of the hardest tasks. We all have our own standards and ideas regarding this, but I generally rely a lot on UE4’s categories to keep relevant variables grouped together.
One thing I have been relying on a lot to keep my scripts readable are eNums. Though the idea behind it is undoubtedly more complex, I try to see them as variables with a set number of possible options. Where a variable that is an integer can be any whole number, an eNum variable can only ever be what you list as options in the eNum you create. As such it can make certain functions and scripts a lot more readable.
In UE4 you can create your own eNum through the Blueprints pop-up menu when you create a new asset.
Once you’ve named it, in this example above “myENUM”, you can add as many display names as you need and give them a descriptive name. If you’re planning on using UE4’s localisation dashboard it is probably a good idea to press the little down arrow next to the Display Name field and set it to “not localisable” so it won’t show up when you gather text. This is, after all, a variable you’ll only use in your scripts, and is never exposed to the player, so there is no need to localise it (unless you’re using eNums to drive on-screen texts, but there would be easier ways of doing that).
Then in your BluePrint you create a new variable, and for the variable type you select the eNum you just created. It is a lot easier to find it if you type the name you gave it in the search field, otherwise it will be under user created.
Now your variable can be used in the BluePrint and all its possible options are preset. For example, if you pull out a “Switch on” node, you will automatically see the possible options as you’ve written them in your eNum list.
Compare this, for example, to an integer-based variable. It’s easy to create a rule that “0 = Cheese Pizza”, “1 = Garlic Bread” and “2 = Chicken Parm”. Then you create an INT variable, but whenever you pull a Switch node off it you have to manually add 0, 1 and 2 as outputs. Plus you have to remember (or note down somewhere) what 0, 1 and 2 meant. In effect eNums do exactly this.
I use eNums a lot for behind the scene presets. For example, I like to keep all my save and load scripts together in one BluePrint and call on it as a function from wherever in the project. So instead of making separate inputs for saving or loading, I’ve made an eNum that listed “save”, “load” or “reset”. In my function I added an INPUT based on that eNum.
Whenever I want to call up a save or load, I call the function and from the little drop-down menu I can select whether I want to save data, load it, or reset it. Now all my save and load functions are neatly within one function.
Amother area I’m using eNums is language settings, for example. Rather than rely on the rather abstract naming the code uses (“en”, “ko”, “de”, etc.) I have merely created an eNum where I spell out the language fully (“English”, “Korean”, “German”, etc.) and call upon whatever language-related function I need to by the easily understandable eNum variable options. And if there is a Switch required per language I can just pull out a Switch node and it’ll be automatically filled in with all possible options.
Not all variables require eNums, of course. Booleans function perfectly fine without having to create an eNum that contains “on” and “off” and using that variable. Huge lists can also benefit from being code-driven and based on integers.
But wherever useful eNums can not only vastly speed up your scripting, but more importantly it can keep parts of your BluePrints extremely readable and concise, and avoids the need to keep extensive notes on the meaning of more abstract variables.