When you have a script with tons of different variables, more often than not you’ll just end up with a huge list of variables and it’ll get tedious trying to find the variables you want to change in the Inspector. There’s an easy way to remove this frustration – use the Header and Space attributes.
The ‘Header’ attribute is used to give a subtitle to groups of variables in the Inspector. Its syntax is [Header(name)], where name is a string of your choice which will act as the header. The ‘Space’ attribute can also help with organisation, as it leaves a small gap between variables in the Inspector. It’s used much the same as Header, except it’s given an integer parameter which tells the Inspector how many pixels high the gap should be. The syntax for Space is [Space(height)].
This is what a script looks like in the Inspector without any of these special attributes:
As you can see, it’s not terribly useful for all these variables to be so close together. It’s far worse when you have about fifty bloody variables with loads of different types and tons of different functions, at which point it becomes impossible to find where you’re supposed to modify values or assign game objects. In this example, it’d look much cleaner if we separated the attack variables from the rest and gave it a header. And that’s just what we’ll do:
This makes things very slightly neater than before. I’ve used Space to separate the ‘script’ parameter from the rest, and a Header to highlight the attack variables more clearly. Header provides a small amount of space on its own, so I didn’t need to worry about leaving a space above the header.
Bounding your variables
In this example, there’s something else we can do to make the designers’ lives easier and make things less likely to break due to human error. Imagine the example script above is to be attached to a player, and that ‘health’ is the player’s maximum health. Well, it probably has an upper limit, and it wouldn’t make too much sense for it to be negative, so we can use the Range attribute, with the syntax [Range(x, y)] (where x is the lower bound and y is the upper bound, both inclusive), to fix variables modified in the Inspector between two values.
This makes the values in the Inspector gain these neat little sliders too, which allows for a much more obvious representation of how large or small your variable’s value is compared to its maximum and minimum. Obviously Range can only be applied to variables of certain types – it wouldn’t make any sense applied to, say, an AudioClip – so make sure you only try using it with numerical types you can actually give a range to. Be careful in your code too – Range only impacts what you can set the variable as in the Inspector and doesn’t stop you freely changing it in code beyond Range’s, uh, range. However, it does make things tons easier for the designer since they won’t need to delve into the code to see any intended restrictions on what the variables’ values should be. And it seemingly has the nice effect of making your code twice as long.
This rounds up the first week’s worth of AGDTAD! I have plenty of ideas to continue the series (many A4 sheets were harmed in the making of this), so be sure to stay tuned for more funky and wacky ways to use Unity and other general game design tips! If you’re enjoying the series so far, be sure to share it with your friends and leave a comment if you want me to cover a certain area of game design in more detail.