Game Development Reference
In-Depth Information
Note
If you are applying this to the GUI that repositions itself to the scene like with Com-
mandBar , the visual aspect you see in the editor may not be the same as when the game
is running. So, things may position differently. You either manage it in the code or live
with it in the editor; it's up to you.
If you have portions of your script that rely on other components that may not be active in
the editor, be sure to check for null references in your code to avoid nasty errors in the
console that may lead you down a dark path.
For example, in the CommandBar script, we need to have null checking on the Mes-
sagingManager calls and the SetPosition function, which have been updated in
the sample app.
Also, any calls to Static classes in the OnDestroy method may generate errors/warn-
ings when they are run in the editor; so just be aware!
Alternative approaches
There is always more than one way to cut the cheese as they say, and so too it is with Un-
ity. Some more advanced options to run the scripts in the editor include the following
methods.
The [InitialiseOnLoad] attribute
Another advanced feature with the editor is to make use of the [InitialiseOnLoad]
attribute. What this attribute does is run whatever class or script it is attached to when the
editor opens or when a build event occurs (such as after you edit a script or run the pro-
ject). Most developers use this for tracking purposes or to have background processes run
whenever something is changed. This is especially useful if you have some level data
stored in a custom file and need to regenerate a scene or level based on that configuration.
Note
Unlike [ExecuteInEditMode] , the [InitialiseOnLoad] attribute is an editor-
only feature, and the scripts using it must be placed in the special Editor folder in your
project.
Search WWH ::




Custom Search