About RMC & Unity3D Rivello Multimedia Consulting (RMC) provides consulting services for applications and games. RMC specializes in Unity3D development (see our work here). Please contact us today with any questions, comments, and project quotes. As always, RivelloMultimediaConsulting.com/unity/ will be the central location for deep articles and tutorials, Facebook.com/RivelloMultimediaConsulting (like us!) will engage the growing RMC+Unity community, and for the latest opinions and cool links follow me at Twitter.com/srivello.

Why Use The Inspector?

For a complete introduction to Unity see my “Intro To Unity” Article. For a quick review: games in Unity are made up of multiple GameObjects that contain meshes, scripts, sounds, or other graphical elements like Lights. The Inspector displays detailed information about your currently selected GameObject, including all attached Components and their properties. Here, you modify the functionality of GameObjects in your scene. Any public field (publicly accessible variable) that is displayed in the Inspector can be directly modified while in edit mode and also while in play mode (the game is playing live). That is great.

The Inspector is a vital part of the Unity toolset with many powerful features. However, here I’ll focus on the specific programming-centric benefits of using the inspector.

Reasons

• Gives us an (editable) view to all public fields on a game object.
• Very powerful for experimentation, prototyping, and debugging.
• Improves our interface to the code. E.g. instead of setting a color in code as #ff0000, you can have a GUI color picker in the inspector.

Example
[actionscript3]
public float myNumberField_float = 10f;
[/actionscript3]
NOTE: Only public fields are shown in the inspector.

NOTE: Adding the attribute [HideInInspector] before a public field name will allow it to be public (for coding) but not be shown in the inspector. This is outside the scope of this article, but it is quite useful sometimes.

Why Use Properties?

As we learn in C# In Depth, for every type you write, you should consider its interface to the rest of the world (including classes within the same assembly). This is its description of what it makes available, its outward persona. Implementation shouldn’t be part of that description, any more than it absolutely has to be. (That’s why I prefer composition to inheritance, where the choice makes sense – inheritance generally exposes or limits possible implementations.)

A property communicates the idea of “I will make a value available to you, or accept a value from you.” It’s not an implementation concept, it’s an interface concept. A field, on the other hand, communicates the implementation – it says “this type represents a value in this very specific way”. There’s no encapsulation, it’s the bare storage format. This is part of the reason fields aren’t part of interfaces – they don’t belong there, as they talk about how something is achieved rather than what is achieved.

I quite agree that a lot of the time, fields could actually be used with no issues in the lifetime of the application. It’s just not clear beforehand which those times are, and it still violates the design principle of not exposing implementation.

Reasons

• Through encapsulation you now have a publicly accessible ‘thing’ just like a field, but here you can more completely control it. For example, within the set {}  you could check the incoming ‘value’ and ensure it is between 1 and 10 before accepting the change.
• Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
• Want to log all access? Just add logging to the getter.
• Properties can be used for more advanced language features (like binding) too

Example
[actionscript3]
private float myNumberProperty_float = 10f;
public float myNumberProperty
{
set {
myNumberProperty_float = value;
}
get {
return myNumberProperty_float;
}
}
[/actionscript3]

Using Properties Via Inspector

By default, while Unity allows the inspector to shows with fields (variables), it does not render properties (getter/setters).

However, now you can do it all. I created the uExposeProperties (uEP) project. It is an asset store project for free. I’m hoping the community finds great uses for it. With uEP you get the best of both worlds; benefits of the inspector as well as properties.

Reasons

• You get the benefits of the inspector
• You get the benefits of properties
• Your code stays very clean (only one simple attribute is added per property)

Example

NOTE: You must download the uEP package to use this functionality. It is not included in Unity.
[actionscript3]
private float myNumberProperty_float = 10f;
[ExposeProperty]
public float myNumberProperty
{
set {
myNumberProperty_float = value;
}
get {
return myNumberProperty_float;
}

}
[/actionscript3]

Drawbacks

• There is one major drawback: theoretical performance. The current implementation depends on the OnInspectorGUI() event which is far more expensive than not using it.
• Any ideas on how to improve that?

Next Steps

• Download the source-code (See ‘Member Resources’). Available Now.
• Get uEP on the asset-store (Coming Soon!)

Member Resources

[private_Free member]Enjoy this members-only content!

• Download the source-code for uExposeProperties

[/private_Free member]