Unity 3D

Source: Flickr

Since I happen to be ranked somewhat high when it comes to mentioning Unity 3D and XML, and some of the posts¹ happen to be outdated by now since I learned stuff². But most of all, I intend to learn even more.

That's why I choose to release those two projects into the wild and publish them on github.

GUIs are not exactly easy to program in Unity 3D, since there is only one method available (OnGUI()) that obviously has to take up everything.

This becomes a problem as soon you try to create different menu screens that have to be switched out. One way to do it would probably be to use different scenes (which would be cumbersome); another way to use a switch, which would be just as cumbersome.

My way of doing it is using delegates, which allows to keep each screen encapsulated in a distinct method, while still retaining the same scene all the time.

using UnityEngine;
using System.Collections;
using System; //Necessary to access Action
 
/// <summary>
/// An example for using delegates to show different menu screens.
/// </summary>
public class DelegateGUI : MonoBehaviour {
 
    #region Setup
 
    /// <summary>
    /// The delegate that is going to be used.
    /// </summary>
    private Action OnGUIMethod;
 
    /// <summary>
    /// The standard GUI method, as inherited by MonoBehaviour.
    /// </summary>
    private void OnGUI () 
    {
        if (OnGUIMethod != null) {
            OnGUIMethod();
        }
    }
 
    /// <summary>
    /// Define what screen to show first.
    /// </summary>
    private void Start () {
        OnGUIMethod = Screen1;
    }
 
    #endregion
 
    #region Screens
 
    /// <summary>
    /// A very simple function that will theoretically show two buttons,
    /// which in turn show the other screens.

Since I'm currently cleaning up my code to hand it in with my project, I figured I could write some of the stuff down I learned during my work on our game.

All of it applies, of course, to C#, and was used in Unity 3D.

Checking for a type

Using the is keyword, you can easily check whether a certain object is of a desired type. Also, you should be aware of the as keyword, that allows you to cast an object as something else (given that this is possible).

if (obj is ISource) {
    ISource s = obj as ISource;
    if (!s.isEndpoint) {
        Connect (s);
    }
}

Modelling Behaviour Over Multiple Frames Without Update()

Sometimes, you need to model some behaviour over several frames (like fading stuff in or out), but doing it in Update() or FixedUpdate() would require unwieldy if constructions.

So ... coroutines to the rescue! Using WaitForFixedUpdate(), you can model a behaviour over several frames without using FixedUpdate(), and quits as soon as it is done.

float i;
 
private void SomeMethod() {
    // do some stuff here
    i = 1f;
    StartCoroutine(FadeOut());
}
 
private IEnumerator FadeOut() {
    while (i > 0f) {
        yield return new WaitForFixedUpdate();
        i -= 0.1f;
    }
}

 Delegates – The Easier Way

I wrote about delegates before, explaining how they could be used.

Yes, this is yet another C#-in-Unity3D post. I hope you will forgive me ;)

Up until now, I would usually reference other GameObjects or components like this:

public class Foo : MonoBehaviour {
 
    public Bar b;
 
    void Start () {
        b = GameObject.FindObjectByTag("Player").GetComponent<Bar>();
    }
}

This works fine until you suddenly want to access a GameObject without knowing if it is already there.

My first solution would have been to rewrite the whole thing as a property:

public class Foo : MonoBehaviour {
 
    public Bar b {
        get {
            return GameObject.FindObjectByTag("Player").GetComponent<Bar>();
        }
    }
}

Of course, since there is no caching mechanism on the compiler level, this "solution" comes at a huge performance cost. The real solution: adding our own caching mechanism.

public class Foo : MonoBehaviour {
 
    private Bar _b;
    public Bar b {
        get {
            if (_b == null) { 
                _b = GameObject.FindObjectByTag("Player").GetComponent<Bar>();
            }
            return _b;
        }
    }
}

Of course, this pattern allows for even more sophisticated mechanisms, like fetching new data once the underlying object has changed, but getting the cached version in all other cases.

Thanks to UnityAnswers, that got me that answer so fast.

Animation curves in the new Unity 3 can not only be used for animation, but can be directly accessed by scripts.

By defining

AnimationCurve curve;

you can add a specific curve to the script in the editor. Using AnimationCurve.Evaluate() you can get the y value at a specific time. Using those curves, you are no longer limited to use Lerp() at every corner (or one of the additional functions provided by Mathfx).

Thanks to Mario von Rickenbach who mentioned that in a lesson as an aside …

Finite State Machines are quite a convenient design pattern in Game Design, as they allow for quite some flexibility when programming AI behaviour.

Unfortunately, our first encounter with FSMs was poorly explained, and badly executed in ActionScript 3 using a bunch of switch statements – disregarding the fact that there would have been clearly more elegant solutions.

So, let's do the same for Unity 3D in C#, using delegates.

using UnityEngine;
using System.Collections;
 
public class FiniteStateMachine : Monobehaviour {
 
    // Create the delegate
    private delegate void FState ();
 
    // Create a holder for the delegate
    private FState stateMethod;
 
    #region UnityEngine methods
 
    /// <summary>
    /// Sets up the controller and puts the object into the new mode.
    /// </summary>
    void Start ()
    {
        stateMethod = new FState (EnterStateA);
    }
 
    /// <summary>
    /// Executes in every frame once. Only calls the current state method.
    /// </summary>
    void FixedUpdate ()
    {
        stateMethod ();
    }
 
    #endregion
 
    #region State A
 
    /// <summary>
    /// Sets up State A.
    /// </summary>
    private void EnterStateA () {
        // Things to prepare State A come here.
 
        stateMethod = new FState (StateA);
 
        // The next line will ensure that the first run of State A
        // will occur in the same frame.

When preparing my game for Fantoche, I ran into problems several times, since upon building my game, the screen either remained black or parts of my game did not work, with the log showing a NullReferenceException.

In both times, it was related to me tagging objects in the Unity 3D editor. This is caused by the somewhat peculiar implementation of tagging in Unity which only allows one tag to be added to an object.

Pitfall No. 1: EditorOnly

Tagging objects in the editor as EditorOnly will make the game work in the editor – but not in the build, as those objects won't be included when building your game.

Pitfall No. 2: Trying to Access One of Several Objects with the Same Tag

When accessing GameObjects using the FindObjectsWithTag() function, make sure that only one object has this tag added.

The function returns the first object with this tag it encounters.

Just in case you are as stupid as I am and place the imported models in your Unity 3D scene and later realise that prefabs would have been rather fab: This is the solution: Drag your new prefab onto the old model in the hierarchy pane while having pressed alt – instant replacement. And once again, the day is saved.

Today when working on my Unity3D game for Fantoche, I noticed it again: a short little squeak at the start of a triggered sound clip.

This has happened before in my prototype, but I chalked it off to my inferior post production skills when doing the first sound clips. The new sound clips, however, were pristine, I was sure of it.

So the problem had to be somewhere else. Changing a suspect in my trigger script did not change a thing.

Yet turning off 3D Sound in the Audio Importer Inspector did the trick: no more weird squeaks.¹

Of course, there are situations where you would need the 3D Sound property set. I have yet to test this out. Maybe the squeak only occurred because my Audio Listener was so close to the Audio Source.