Object construction with factory method

How to structure your code to produce loads of objects? Learn the Factory Method and how to implement it in Unity3d!

One of the most common things to do in making a game is instantiating objects at runtime. Be it bullets from a gun, enemies rushing forward or instances of software classes, sooner or later you’ll need to do it.

This is one of those classic problems of computer science that have been solved over and over again. The solution to it I’m going to talk about today is the Factory Method (not to be confused with the Abstract Factory, which is way more general in its application).

What’s a Factory Method?

factory-method-pattern

Basically it’s when you use an inherited method (either from a superclass or an interface) to create for you an instance of a Product. The Product will be set up just as you specified with the arguments that are given to the Factory Method.

For instance if you have an¬†EnemyFactory superclass, you could have a OgreFactory implement the FactoryMethod() for it. Then you could have an Ogre orc=datOgreFactory.FactoryMethod(100) to have orc‘s hit points set to 100.
Of course the GoblinFactory is another subclass of EnemyFactory but will still give you a 100 hp hulkling of a goblin if you ask for it with a Goblin hobGoblin=datGoblinFactory.FactoryMethod(100). It’s important to keep in mind that both Ogre and Goblin are one same kind of superclass: Enemy. This means they will share a common usage in their DieForLoot() function so that the kill procedure doesn’t need to know their specifics.

If you want a more technical definition, the internet is filled with it but I’d rather recommend to cut to the source and read it straight from the book written by the Gang of Four.

When to factory?

That’s more of a critical issue worth discussing. My personal answer would be to use it every single time you have more than exactly one thing to instantiate and most of the times you actually instantiate just one thing.

If you want dem clones, make a factory!
If you want dem clones, make a factory!

When you construct an instance of something twice, you are duplicating code and sure as hell it’s better not to write the same thing twice.

As for the reason I’d recommend to write one even if you are doing an instantiation just once:

  • if it’s something that will be a part of gameplay are you really sure you won’t be putting another one somewhere else?
  • Are you really sure you don’t need to test the instantiation itself indipendently?

Chances are, you will, and copy-pasting a bit of boilerplate code upfront is way better than refactoring after.

Also, it helps with respecting the single responsibility principle in the code: if instantiating that object was the only job of the class it’d be a factory, wouldn’t it?

But be careful: in some cases you might need to move even further and go full Abstract Factory. You might ask yourself:

  • Do I need to abstract everything or is it ok to work on concrete instances?
  • Do I need to hide my concrete code (i.e.: with a .dll)?
  • Do I need a factory of factories?

If you answered no to that, there’s no need for too much abstraction and you can just use the good old Factory Method.

blueprints-1837238_1920

How to build one in Unity3d

When working with Unity we have the usual problem of handling the references, which entails serious design decisions over how the factory should be realized. Plus in this case we have an additional issue: interface references won’t show up in the inspector, not even with a SerializeField .

Why? because just as generics (with the exception of the hardcoded List<T> ) interface references don’t get serialized in Unity, unless you write a workaround or pay sixty bucks …or at least five.

So this code:

public class FactoryUser : MonoBehaviour
{
    [SerializeField]
    IFactory thisWontSerialize;
    [SerializeField]
    MonoBehaviour factory;

will be rendered in the inspector like this:

immagine

So how to do a factory? Let’s begin with the interface (of course you can also make a superclass and skip half of the issues).

public interface IFactory 
{
    GameObject FactoryMethod(object[] parameters);
}

Why an array of objects? because we don’t know what we’ll need, so better have the thing that can do everything. A more type-safe approach would be to define a dedicated struct or class.

To have a working example we’ll implement a concrete factory that instantiates a number of childs of a main prefab:

public class ConcreteFactory : MonoBehaviour, IFactory
{
    [SerializeField]
    GameObject mainPrefab;
    [SerializeField]
    GameObject childPrefab;

First of all,¬† we add the references so that they can be seen in the inspector. Of course we’re going to make this class a MonoBehaviour, because to use the inspector is either that or ScriptableObjects and this is not a ScriptableObject tutorial. And I love the inspector.

inspector unity
He obviously prefers a platonic love ūüôĀ
    public GameObject FactoryMethod(object[] parameters)
    {
        GameObject mainObject = Instantiate(mainPrefab);
        int amount = (int)parameters[0];
        for (int i = 0; i < amount; i++)
        {
            GameObject childObject = Instantiate(childPrefab);
            childObject.transform.parent = mainObject.transform;
        }
        return mainObject;
    }

This is the method that implements the IFactory interface. What we now do is:

  1. Instantiate a copy of the main prefab.
  2. Dumbly take for granted that the first parameter really IS an int
  3. proceed to a runtime error to instantiate and reparent his child objects
  4. witness in horror as performance sinks since we didn’t use pooling here

Now that the concrete factory is done let’s see it in action:

public class FactoryUser : MonoBehaviour
{
    [SerializeField]
    MonoBehaviour factory;

Wait, why a MonoBehaviour reference? We don’t want any runtime checks, do we? This should be type-safe and checked at compile-time!

    public void OnValidate()
    {
        if (!(factory is IFactory))
        {
            Debug.LogError("Wrong reference type");
            factory = null;
        }
    }

Well, not really at compile time, we just need it to be done while the game isn’t running. So here’s a check that runs every time the field is modified in the inspector. Of course if you want to inject the factory instance or have it passed some other way, you can use an IFactory variable instead.

This is just a workaround to have both type-safety and serialization after all,¬†here’s another one if you don’t like it this way.

workaround unity interface serialization

But we’ll also avoid having to write a cast every time we use it:

    IFactory Factory { get { return factory as IFactory; } }

So we now can write:

    public void Start()
    {
        object[] parameters = new object[1];
        parameters[0] = 2;
        Factory.FactoryMethod(parameters);
    }

And finally, here it’s at work. Easy as pie. So easy it will be a pleasure to test and spam everywhere (provided you pooled everything).

Where’s the advantage of using this approach? Say your level designer wants to change the enemy type that is spawned in front of the castle gates, he can do it in the inspector simply by changing the factory that is referenced in the castle gate spawn component. No coding required, just a drag&drop.

That’s all folks!

Here’s a Unity project where you can grab al the code and see it in action, plus scroll down for a copy-pasteable version of it.

I hope you liked this tutorial, please tell me if you find this kind of guide interesting or not, either here or on my Twitter. If you don’t want to miss my next thing consider subscribing to my newsletter.

P.S.: I’m currently looking for a job, if you are interested here’s my portfolio.

public class ConcreteFactory : MonoBehaviour, IFactory
{
    [SerializeField]
    GameObject mainPrefab;
    [SerializeField]
    GameObject childPrefab;

    public GameObject FactoryMethod(object[] parameters)
    {
        GameObject mainObject = Instantiate(mainPrefab);
        int amount = (int)parameters[0];
        for (int i = 0; i < amount; i++)
        {
            GameObject childObject = Instantiate(childPrefab);
            childObject.transform.parent = mainObject.transform;
        }
        return mainObject;
    }
}
public interface IFactory 
{
    GameObject FactoryMethod(object[] parameters);
}
public class FactoryUser : MonoBehaviour
{
    [SerializeField]
    MonoBehaviour factory;
    IFactory Factory { get { return factory as IFactory; } }

    public void OnValidate()
    {
        if (!(factory is IFactory))
        {
            Debug.LogError("Wrong reference type");
            factory = null;
        }
    }

    public void Start()
    {
        object[] parameters = new object[1];
        parameters[0] = 2;
        Factory.FactoryMethod(parameters);
    }
}
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

The singleton post – making a Singleton in Unity3d with inheritance

You already know what a singleton is? See how to do it by inheriting from a SingletonBehaviour<T>, skip to “How to singleton”

Sometimes when programming you are just reinventing the wheel. And by sometimes I mean all the time. Basically every problem a programmer faces is an already solved problem from an algorithmic perspective. Either that or you’d have better refused that job unless you are in academy.

So why not to look at all the already found solutions and use the ones matching your problem? The best solutions to the most common problems have been codified a long time ago, both for programming in general (ever heard of the Gang of Four?) and for game programming in particular.

Today I’ll¬†talk about one of these standardized solutions, the most famous one: the Singleton.

What’s “singleton”?

one-way-street-362172_1920

A singleton is a class that you want to make sure is unique and globally accessible.¬†This means that there’s only one in your scene and that it’s accessible from everywhere and everything.

Of course in Unity you won’t have a class floating in nothingness, althought you could do so with a static class. In Unity you want to use that sweet inspector to tweak the singleton’s variables, so you want to make it a component to an object.

When to singleton

gummibarchen-359950_1280

There’s a lot of cases in which a Singleton is just a good idea.¬†For instance since you only have one touch input source on a mobile device, it would be a good idea to have a singleton deal with it.

Also, if you are in need of managing the timing of all the enemy attacks in your musical shump a singleton would be the best candidate to handle the coordination. You need a lot of slowmotions and want to check if there’s overlap? Get a singleton to do that!

You should ask yourself these two questions to check if you need a singleton:

  • is this a thing that must not be duplicated or otherwise there could be problems?
  • is this a thing that I want to have easily accessible from everywhere?

When not to

Since the singleton is very quick to implement (and with this inheritance-based approach¬†you’ll need just a few characters to do so) it’s easy to over-use it and to add useless singletons.

An example is the case where you make a singleton EnemyManager and an Enemy¬†script, where the latter only has some data and the former’s only aim is to extend the Enemy¬†with methods. In that case is better to just add the methods in the Enemy script.

To check if you really need that singleton ask yourself:

  • do I need to hold some information in this class or it’s just methods?
  • can’t I just do the same things by extending something else?
  • will this raise my codebase’s coupling too much?

Also, since this is basically a global variable on steroids it goes without saying that if you have a problem with global variables you should use anything but this (i.e.: if you want to perform unit testing). In general a lot of people have a lot to object to the use of singletons, so inform yourself and make it your call.

singleton unity3d inheritance

How to singleton

[Notice: this part was written differently due to a buggy behaviour that now I can’t reproduce]

Since this is a design pattern you will find a host of different implementations of it and they will all be just as correct as this is, the real question is which way is more suitable to you.

In unity for instance if you use the singleton as a component in a GameObject you can be pretty sure that you won’t need to¬†bother with locks as they did in the unity wiki.

Also, I assume you aren’t trying to implement just one singleton class but that you’ll need a number of them and that you want to do it without duplicating code.

Well, its one kind of singleton inheritance, I guess...
Well, its one kind of singleton inheritance, I guess…

Given these assumptions here’s my implementation of it: we start with a generic class called SingletonBehaviour that inherits from MonoBehaviour, then whenever you want to create a singleton you just mark that class as inheriting¬†SingletonBehaviour.

Let’s look at the code:

public class SingletonBehaviour<T> : MonoBehaviour where T : MonoBehaviour
{

As I said this will be a generic class, that uses T as a parameter to indicate the actual type of the singleton we want to instantiate by inheritance. And that type will only be constrained to be a MonoBehaviour, so that only scripts that can be a component of a gameobject can be used for this.

    public static T instance;

This is where the references of our subclasses will be stored. Since it’s static only one instance per type is allowed.

Now let’s see what we do when an instance is created:

    public virtual void Awake()
    {
        if (instance != null)
        {
            Debug.LogError("Duplicate subclass of type " + typeof(T) + "! eliminating " + name + " while preserving " + instance.name);
            Destroy(gameObject);
        }
        else
        {
            instance = this as T;
        }
    }

The first thing to do is to check if this class has already been instantiated (notice, you can also use¬†if(instance)¬†if you don’t care for readability as you should), if that’s the case the GameObject is to be destroyed. Why the whole GameObject? Because this is a kind of failure so serious you want it to flash everything, add a Debug.Break()¬†too if needed.

For this tutorial’s purpose I’ve also added a (quite verbose) error message. Otherwise, we set the current class’ instance in the instance variable.

    public virtual void OnDestroy()
    {
        if (instance == this)
            instance = null;
    }

That is, only if the instance being destroyed is the same one being stored we go on and clean the contents of the instance variable.

So, now to use this one only needs to inherit from this class like this:

public class SomeSingleton : SingletonBehaviour<SomeSingleton>

Notice that¬†you are not enforced to use the same class as generic parameter by the compiler, which means that you could even have different classes compete for the same slot. I won’t recommend doing that on purpose: if you want to manage different singletons for one “slot” it’s best done explicitly instead of by relying on who gets there first.

That’s all folks!

Once again instead¬†I’ve built for you a test project so that you can download and test it in action, but of course down here comes also the copy-pasteable version.

I hope you enjoyed this tutorial, and that you will consider joining my newsletter. Please also tell me what you think of this and if you think I should cover more design patterns, either here or by hitting me up on twitter.

P.S.: I’m currently looking for a job, give a look to my portfolio if you are interested.

using UnityEngine;

public class SingletonBehaviour<T> : MonoBehaviour where T : MonoBehaviour
{
    public static T instance;

    public virtual void Awake()
    {
        if (instance)
        {
            Debug.LogError("Duplicate subclass of type " + typeof(T) + "! eliminating " + name + " while preserving " + instance.name);
            Destroy(gameObject);
        }
        else
        {
            instance = this as T;
        }
    }

    public virtual void OnDestroy()
    {
        if (instance == this)
            instance = null;
    }
}
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Crossfade gallery, a simple and cool UI element

Last week I’ve released a new UI demo project with some effects made entirely in Unity3D’s UI and it had quite a good reception, in particular at some point I was asked to share.

untitled

Well, I’m not ready to put it on GitHub yet (some parts of the code need more polish before being released without shaming myself), but I do want to share. So I’ll¬†give a downloadable link to¬†the project in my newsletter and start a new tutorial series on the topic here.

Today’s topic is the first panel: the sequential crossfader.

What does crossfade mean?

You have probably seen this transition a gazillion times in your life. It’s when an image fades away and a new one takes its place.

How it’s done is quite simple: for each pixel you lerp its color between the color of the former image and the one of the next.

Luckily for us, we don’t have to even deal with that simple operation, UnityEngine.UI.Graphic has already all that we need.

Let’s wrap Graphic

wrap it tight
wrap it tight

From this class we only need one thing: the CrossFadeAlpha function. But we will need to do 3 things with it.

  1. reset the values to an initial state
  2. fade in
  3. fade out

To do this, we’ll just use a small MonoBehaviour component, but please notice that if you want to do this with whole panels instead of a single graphic, you’ll need to add a canvas group¬†as target and change the functions¬†to manually lerp its alpha value.

So, here’s the code:

using UnityEngine;
using UnityEngine.UI;

public class UICrossFader : MonoBehaviour
{
    [SerializeField]
    Graphic toCrossFade;
    [HideInInspector]
    public float inAlphaLevel = 1f;
    [HideInInspector]
    public float outAlphaLevel = 0f;
    [HideInInspector]
    public float duration = 1f;
    [HideInInspector]
    public bool ignoreTimeScale = false;

    public void FadeIn()
    {
        toCrossFade.CrossFadeAlpha(inAlphaLevel, duration, ignoreTimeScale);
    }

    public void FadeOut()
    {
        toCrossFade.CrossFadeAlpha(outAlphaLevel, duration, ignoreTimeScale);
    }
    
    public void Preset(bool isIn)
    {
        if (isIn)
            toCrossFade.CrossFadeAlpha(inAlphaLevel, 0f, true);
        else
            toCrossFade.CrossFadeAlpha(outAlphaLevel, 0f, true);
    }
}

Why are almost all the variables public but hidden? because if you want to control this behaviour you’ll want to do it¬†by code and you don’t want anyone who doesn’t know what he’s doing to fiddle with it.

As you can see the Preset function can either set something to be visible or invisible (in or out) according to the isIn parameter and does so in just a frame, regardless of the timescale. This is because that function is meant to work behind the scenes, not while the show is going on.

The fade functions are just another wrap for the CrossFadeAlpha with pre-set values. This component is indeed very simple, but keep in mind that not everything in UI is a Graphic, and that also you may want to extend this to do more complex stuff one day.

Managing a sequence with a coroutine Start

flight-1179587_640

    public GameObject listParent;
    [SerializeField]
    float startDelay;
    [SerializeField]
    float interval = 4f;
    [SerializeField]
    bool doLoop = true;

We need just a few variables to decide:

  • what list of elements we’re going to fade (all the children of listParent who have a UICrossFader)
  • after how much time it will start
  • how much time each element should stay visible before we start the fading
  • if this sequence should be looped or not
    IEnumerator Start()
    {
    	bool executeLoop = true;
        UICrossFader[] crossfadeImagesList=null;

        yield return new WaitForSeconds(startDelay);

As you may know (or not, since as of now this seems to be an undocumented feature), the Start function of Monobehaviour can be used as a coroutine. All that you need to do is to change its return type to IEnumerator. I know, it’s crazy, but they did it this way and it IS very comfortable not to write a coroutine call every time you need it.

In the beginning we just declare a couple of variables we’ll need later on and let the execution to wait for the right time to start.

    if (listParent != null)
    {       
        crossfadeImagesList = listParent.GetComponentsInChildren<UICrossFader>();
        if (crossfadeImagesList.Length <= 0)
            Debug.LogError("SequenceFader error, list empity, check that children of listParent do have UICrossFader component");
        else
        {
             //everything else...
        }
    }
    else
    {
        Debug.LogError("SequenceFader error, listParent not assigned!");
    }

The first thing we do is to check that listParent has been set, otherwise an error is due. Then we need¬†to see is if it has stuff to crossfade in it or another error must be raised. And at last, if we have something to crossfade we’ll start doing so.

Now let’s get into that “everything else”:

                foreach (var item in crossfadeImagesList)
                {
                    item.Preset(false);
                }

                System.Collections.IEnumerator crossfadeEnumerator = crossfadeImagesList.GetEnumerator();
                crossfadeEnumerator.MoveNext();
                UICrossFader currentFader = (UICrossFader)crossfadeEnumerator.Current;
                currentFader.Preset(true);
                UICrossFader last = currentFader;
                yield return new WaitForSeconds(interval);

Another bit of initializations is now due: we begin with nothing visible, then we get the first element of the list and set it as visible. We also record it as a last element to have been visible. Then we wait the moment we’ll show the next¬†image.

                while (executeLoop)
                {
                    currentFader = (UICrossFader)crossfadeEnumerator.Current;
                    last.FadeOut();
                    currentFader.FadeIn();
                    last = currentFader;
                    if (!crossfadeEnumerator.MoveNext())
                    {
                        if (doLoop)
                        {
                            crossfadeEnumerator = crossfadeImagesList.GetEnumerator();
                            crossfadeEnumerator.MoveNext();
                        }
                        else executeLoop = false;
                    }
                    yield return new WaitForSeconds(interval);
                }

Usually one would just have the iterator MoveNext be called inside the while condition, but now we may want to stay inside the loop once that all the list is traversed and start from the beginning, so instead we’ll use the executeLoop flag. At each loop we get a new current element to fade in and start the crossfade by calling in the appropriate functions of the UICrossFader, then we update the last and check if¬†this was the last element of the list while at the same time advancing the enumerator with its MoveNext.

to loop or not to loop? this is the question!
to loop or not to loop? this is the question!

If it was the last element, then we have 2 possibilities: if we should not loop, the executeLoop is set to false and we’re out¬†for good; if we should loop then the enumerator is reset to its first element.

After this check we just wait one more interval before continuing the loop.

That’s all folks!

And we’re done, now your images will transition one after another with a nice crossfade. You can use this for all sorts of purposes and even extend it to a “video” fader in which a dialog is played one image after another (I did so for a then killed project back in the day). If you want to get updates on the next tutorials or just download the full project, get on my newsletter, I’ll give a download link for it next week too (maybe with some minor updates since I’m polishing the code to write this tutorial series). For any questions or comments don’t hesitate writing me here¬†or hitting me up on twitter.

P.S.: I’m currently looking¬†for a gamedev job, if you are interested give a look at my portfolio. Also, if you are a fellow Unity3D dev, let’s connect!

using UnityEngine;
using UnityEngine.UI;

public class UICrossFader : MonoBehaviour
{
    [SerializeField]
    Graphic toCrossFade;
    [HideInInspector]
    public float inAlphaLevel = 1f;
    [HideInInspector]
    public float outAlphaLevel = 0f;
    [HideInInspector]
    public float duration = 1f;
    [HideInInspector]
    public bool ignoreTimeScale = false;

    public void FadeIn()
    {
        toCrossFade.CrossFadeAlpha(inAlphaLevel, duration, ignoreTimeScale);
    }

    public void FadeOut()
    {
        toCrossFade.CrossFadeAlpha(outAlphaLevel, duration, ignoreTimeScale);
    }
    
    public void Preset(bool isIn)
    {
        if (isIn)
            toCrossFade.CrossFadeAlpha(inAlphaLevel, 0f, true);
        else
            toCrossFade.CrossFadeAlpha(outAlphaLevel, 0f, true);
    }
}
public class SequenceFader : MonoBehaviour
{
    public GameObject listParent;
    [SerializeField]
    float startDelay;
    [SerializeField]
    float interval = 4f;
    [SerializeField]
    bool doLoop = true;
    bool executeLoop = true;


    IEnumerator Start()
    {
    	bool executeLoop = true;
        UICrossFader[] crossfadeImagesList=null;

        yield return new WaitForSeconds(startDelay);

        if (listParent != null)
        {       
            crossfadeImagesList = listParent.GetComponentsInChildren<UICrossFader>();
            if (crossfadeImagesList.Length <= 0)
                Debug.LogError("SequenceFader error, list empity, check that children of listParent do have UICrossFader component");
            else
            {
                foreach (var item in crossfadeImagesList)
                {
                    item.Preset(false);
                }

                System.Collections.IEnumerator crossfadeEnumerator = crossfadeImagesList.GetEnumerator();
                crossfadeEnumerator.MoveNext();
                UICrossFader currentFader = (UICrossFader)crossfadeEnumerator.Current;
                currentFader.Preset(true);
                UICrossFader last = currentFader;

                yield return new WaitForSeconds(interval);
                while (executeLoop)
                {
                    currentFader = (UICrossFader)crossfadeEnumerator.Current;
                    last.FadeOut();
                    currentFader.FadeIn();
                    last = currentFader;
                    if (!crossfadeEnumerator.MoveNext())
                    {
                        if (doLoop)
                        {
                            crossfadeEnumerator = crossfadeImagesList.GetEnumerator();
                            crossfadeEnumerator.MoveNext();
                        }
                        else executeLoop = false;
                    }
                    yield return new WaitForSeconds(interval);
                }
            }
        }
        else
        {
            Debug.LogError("SequenceFader error, listParent not assigned!");
        }
    }
}

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Input management with Dependency Injection

Object oriented programming has a lot of patterns that can be very useful for making games. One of those patterns is the Dependency Injection, a pattern that helps to decouple classes that would otherwise be tightly connected. So let’s take something that’s really connected and see how dependency injection can help us: the input management.

Wait what’s this Dependency Injection?


Usually if you have a¬†thing (call it client) that uses another thing (call it service), when you change the service, then you have to also change the client. And that’s bad. Let’s say the client is your game logic and you are porting your game from¬†pc to mobile, and that therefore you need to switch from a keyboard + mouse input to a touch one. Since all inputs are changed (perhaps radically since your WASD is now a UI element) you now need to change some input-read line in your game logic even if you used an intermediate class to get those button inputs.

The Dependency Injection way to do it instead is to have the input manager call the game logic functions. Without it knowing whose functions they are. You just set them as callbacks and call them when needed. Who sets the callbacks? The naive option is: the client. But then you still have a direct dependency between the classes. Enter the DIC: Dependency Injection Container. He takes the callbacks from the client and gives them to the service, thus eliminating the dependency between them (and adding another class to your code, that’s not a free lunch).

And what are those de-leee-gates?

Delegate

A delegate is just a way to pass a function as an argument, it can also be stored as a variable and given a type name to be checked so that only the functions that match a certain signature can be stored or passed as a delegate of a specific type.

Let’s read some Input!

    [SerializeField]
    string XbuttonName = "Fire1";
   
// other button names 

    [SerializeField]
    string LeftStickHorizontalName = "Horizontal";
    [SerializeField]
    string LeftStickVerticalName = "Vertical";
//other axis names

First of all we’ll need the names of the input buttons and axis we’re going to read, for this example I’ve used a regular xbox controller. We’ll do this with the old unity input system, not the (currently) experimental one, so we’ll need a string name for it.¬†If you’ve read my other tutorials you know I’ve a personal feud with strings, but this is one of the few cases you really have to use them: if you are building an input manager you don’t want to force whoever uses it to edit code just to rename an input field, so you really want to have that in the inspector, which means a serialized string. Notice that for¬†thumbsticks we’ll need two axis per stick, so two thumbsticks means four¬†axis.

    public static InputManager instance;

    [SerializeField]
    InputManagerDIC inputDIC;

    [SerializeField]
    float triggerSensibility = 0.2f;

As for the other variables, the instance reference will be used to make this class a singleton, the inputDIC is needed to ask for the injection, and the trigger sensibility trashold will be used to get a button behaviour from an axis, because back in my days triggers were fucking buttons and I like it that way.

public delegate void buttonReaction();
public delegate void axisEffect(Vector2 axisVal);

Although we could make this all with predefined System Actions, I’d rather estabilish a more specific interface that reminds whoever writes the game logic code what is supposed to act as a button and what is supposed to act as an axis. It’s just a reminder,¬†nothing more.

good old controller
good old controller
    public static buttonReaction XbuttonPress = delegate () { };
    //other press callbacks ...
    public static buttonReaction XbuttonPressContinuous = delegate () { };
    //other continuous callbacks 
    public static axisEffect leftStickEffect = delegate (Vector2 a) { };
    public static axisEffect rightStickEffect = delegate (Vector2 a) { };
    public static System.Action InputStartRead = delegate () { };

Each callback is initialized to an empty delegate because if for whatever reason we don’t want to use something, we don’t want a nullreference exception to pop out after the change.

Now, we can define a lot of callbacks for each Input since every button has four relevant conditions:

  • just pressed
  • pressed (continuously)
  • just released
  • released (continuously)

In this example I’ll use four¬†buttons and the triggers and read only two condition for the buttons (just pressed and continuous press) and one for the triggers (continuous press), for each of the conditions I want to read I need to define a callback.

The same goes for what to do with thumbsticks, but in that case I just want to read a direction out of them and let the game logic interpret it.

The last callback isn’t really needed but for this tutorial I’ve also built a public repository where you can download a test scene and I need to clean the UI state at the beginning of every frame, so I want a callback for that too.

void Awake()
    {
        if (instance == null)
            instance = this;
        else
            Destroy(gameObject);
        inputDIC.LoadInputManager();
    }

As I said before this is going to be a Singleton. And at the beginning of execution we want the DIC to inject his callbacks in the InputManager, so we’ll call his loading function here.

    void Update()
    {
        InputStartRead();
        if (Input.GetButtonDown(XbuttonName))
        { XbuttonPress(); }
        //read other buttonDowns
        if (Input.GetButton(XbuttonName))
        { XbuttonPressContinuous(); }
        //read other buttons
        if (Input.GetAxis(leftTriggerName) > triggerSensibility)
        { leftTriggerPressContinuous(); }
        if (Input.GetAxis(rightTriggerName) > triggerSensibility)
        { rightTriggerPressContinuous(); }

        leftStickEffect(new Vector2(Input.GetAxis(LeftStickHorizontalName), Input.GetAxis(LeftStickVerticalName)));
        rightStickEffect(new Vector2(Input.GetAxis(RightStickHorizontalName), Input.GetAxis(RightStickVerticalName)));
    }

And at last here’s the action. At first we call the “start reading” callback, then for each button we check the relevant states. Notice that for the trigger we read an axis input and only when it’s over the trashold we’ve set before we call a callback just as if it were a regular button. From the game logic standpoint that trigger will be undistinguishable from a button, it even uses the same delegate type for the callback. For the thumbsticks instead we’ll read the two axis in a single Vector2 variable and use that to call the appropriate axisEffect callback.

How about a UI class for testing this?

a really simple ui
a really simple ui

I’ve made it as basic as it gets, sorry but no fancy stuff here:

    [SerializeField]
    Toggle xButton;
    //other toggles
    [SerializeField]
    Text rStick;
    //other texts

For each button I’ll set a toggle on and off, while for the sticks I’ll show the direction in a text. All the references are passed with serialized fields in the inspector.

    public void LogCallTLCont() { ShowLogButton(lTriggerButton, "TL Cont"); }
    public void LogCallTRCont() { ShowLogButton(rTriggerButton, "TR Cont"); }
    public void LogCallA() { ShowLogButton(aButton, "A "); }
    public void LogCallB() { ShowLogButton(bButton, "B "); }
    public void LogCallX() { ShowLogButton(xButton, "X "); }
    public void LogCallY() { ShowLogButton(yButton, "Y "); }
    public void LogCallACont() { ShowLogButton(aButton, "A Cont"); }
    public void LogCallBCont() { ShowLogButton(bButton, "B Cont"); }
    public void LogCallXCont() { ShowLogButton(xButton, "X Cont"); }
    public void LogCallYCont() { ShowLogButton(yButton, "Y Cont"); }
    public void LogCallL(Vector2 direction) { ShowLogAxis(lStick, "L stick with dir", direction); }
    public void LogCallR(Vector2 direction) { ShowLogAxis(rStick, "R stick with dir", direction); }

    void ShowLogButton(Toggle toggle, string text)
    {
        toggle.isOn = true;
        Debug.Log(text);
    }

    void ShowLogAxis(Text field, string text, Vector2 direction)
    {
        field.text = direction.ToString();
        Debug.Log(text + direction);
    }

All the callbacks are actually using the same couple of functions, logging and setting an UI element each time. But who’s going to reset all those toggles when we didn’t¬†read the¬†button’s release? Our reset function of course:

    public void ResetUI()
    {
        xButton.isOn = false;
        yButton.isOn = false;
        aButton.isOn = false;
        bButton.isOn = false;
        lTriggerButton.isOn = false;
        rTriggerButton.isOn = false;
        rStick.text = Vector2.zero.ToString();
        lStick.text = Vector2.zero.ToString();
    }

¬†It’s Injection time

dependency injection input time
dependency injection input time

Also the DIC is really simple, all it does is to set the callbacks in the InputManager, so it only needs a load function and a field to specify from which class instance it should take the callbacks:

    [SerializeField]
    UserExample target;
    public void LoadInputManager()
    {
        InputManager.XbuttonPress = target.LogCallX;
        InputManager.YbuttonPress = target.LogCallY;
        InputManager.AbuttonPress = target.LogCallA;
        InputManager.BbuttonPress = target.LogCallB;
        InputManager.XbuttonPressContinuous = target.LogCallXCont;
        InputManager.YbuttonPressContinuous = target.LogCallYCont;
        InputManager.AbuttonPressContinuous = target.LogCallACont;
        InputManager.BbuttonPressContinuous = target.LogCallBCont;
        InputManager.leftStickEffect = target.LogCallL;
        InputManager.rightStickEffect = target.LogCallR;
        InputManager.leftTriggerPressContinuous = target.LogCallTLCont;
        InputManager.rightTriggerPressContinuous = target.LogCallTRCont;
        InputManager.InputStartRead = target.ResetUI;

    }

So, as you can see the InputManager has no dependecy towards the client class and the UserExample doesn’t even know that his functions are¬†linked to an input. Any maintenance change on either class will stop here in the DIC and will be as trivial as just changing wich callback is assigned to what variable since that’s all that can happen here.

But what if I just changed Input Settings instead of doing all that?

That’s cool and that’s also the proper way to do it (until you are not porting from pc/console to mobile). Really, until you are not changing between radically different input sources in unity, you’re better off using Unity3d’s input system to remap controls¬†and avoid changing code. I only used the Input management as the easiest-to-explain example, if one thinks this technique is just for that, he’s totally missing the point. This technique can (and according to some people should) be used for absolutely everything.

That’s all folks

Thanks for the read. This time no copy-paste, you get a repository with the whole project already set up and ready to use here. If you have any questions or comments please do express that either in the comments here or just hit me on twitter. And if you don’t want to lose my future stuff, consider my newsletter.

P.S.: I’m currently looking for a job,¬†if you are interested take a look at my portfolio.

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Pooling in unity3d – a simple tutorial

We’ve been through it: instantiations at runtime can be a huge problem. It can cause a spike in the workload of any game, and then you have to find ways to fix that when it happens. Or you can use a technique called pooling, like pros do.

you can have a lot of pools
you can have a lot of pools

What’s pooling in unity3d?

The same it should be anywhere else: instead of instantiating objects wherever and whenever you need them, you create a pool beforehand (while the loading screen is on) and then when it’s needed you grab an object from the pool.

To make a pool you’ll need 3 things:

  • a pool script
  • a pool interface
  • a pool host
    Let’s start with the trivial stuff first.

Pool interface iPoolable

It's objects in a pool, got it?
It’s objects in a pool, got it?

When an object is “in the pool” it’s better if it’s inactive in all conceivable ways. But of course the pool script should not be required to know how to inactivate every single object because that would be a maintenance nightmare. Therefore we’ll need this simple interface to be implemented by one script at the root of the pooled gameobject:

public interface iPoolable
{
  Pool source { get; set; }
  void Initialize();
  void Deactivate();
}

The source property is a reference to the pool script that holds the object’s pool, oviously. Why should the pooled object need to know that? So that it can return to the pool by itself by calling:

source.PutInPool(gameObject);

The Initialize function’s duty is to prep the object to enter the scene in an active state, just as if it was actually instantiated at the very end of the function.

The Deactivate function instead is called when the object would have been removed from the scene weren’t we pooling it. It has to minimize the impact on both memory and cpu/gpu for holding the object in the pool. This usually involves at least a SetActive(false) and a stop on all coroutines on the object if any, but one can get creative and also switch layers and stuff like that.

The pool host

This isn’t a strictly needed element for pooling to work, but if like me you don’t enjoy having a bunch of gameobjects floating around in your game’s hierarchy, you want to do this:

public class PoolHost : MonoBehaviour
{
    public static PoolHost instance;

    void Awake()
    {
        if (instance == null)
            instance = this;
        else
            Destroy(gameObject);
    }

    public static void Hold(GameObject poolable)
    {
        poolable.transform.parent = instance.transform;
    }
}

It’s just a singleton with one static function to hold the pooled gameobject inside the one this script is attached to. You could, of course, separate the pools by type, but why?

but why?

The actual Pool script

This script is designed to be used as a field in another script. This approach enables you to do all sorts of customizations, for instance your weapons can have a pool of bullets, so that you can make more weapons by changing the bullet prefab reference in the pool field.

[System.Serializable]
public class Pool
{
    Stack<GameObject> pool;
    [SerializeField]
    int initialPoolSize;
    [SerializeField]
    int expansionPoolSize;
    [SerializeField]
    GameObject prefabReference;

    public void Populate()
    {
        //stuff..
    }

    void ExpandPoolPopulation(int amount, GameObject prefabReference)
    {
        //stuff..
    }

    public GameObject Allocate()
    {
        //stuff..
    }

    public void PutInPool(GameObject handled)
    {
        //stuff..
    }
}

As you can see it’s entirely serializable, so that we may edit its parameters from the inspector when we use it as a field. The initialPoolSize variable is used to set how many gameobjects we should instantiate in the Populate call, while the expansionPoolSize indicates how many should be instantiated when the pool is empity and an allocation is requested.

Guess what the prefabReference is. Right! It’s where you drag-and-drop your prefab from the project explorer.

drag-and-drop

So, the idea is that the object using this pool needs to Populate it at first, then it can Allocate instances from it and when it’s done it (or the pooled object itself) can PutInPool back the pooled thingy.

Now, let’s see the single functions:

    public void Populate()
    {
        pool = new Stack<GameObject>();
        ExpandPoolPopulation(initialPoolSize, prefabReference);
    }

This one is damn easy. It initializes the pool variable with a brand new Stack (of course you can use my garbageless list instead!), then calls ExpandPoolPopulation to instantiate the very first objects in the pool.

    void ExpandPoolPopulation(int amount, GameObject prefabReference)
    {
        for (int j = 0; j < amount; j++)
        {
            GameObject result = GameObject.Instantiate(prefabReference);
            result.GetComponent<iPoolable>().source = this;
            PutInPool(result);
        }
    }

This one is really straightforward too. It just instantiates the prefab a number of times, sets the source for the object and then puts it in the pool. It’s as obvious as it gets.

    public void PutInPool(GameObject handled)
    {
        handled.GetComponent<iPoolable>().Deactivate();

        handled.SetActive(false);

        handled.transform.position = Vector3.zero;
        handled.transform.rotation = Quaternion.identity;
        handled.transform.localScale = Vector3.one;

        PoolHost.Hold(handled);

        pool.Push(handled);
    }

Here the first thing to do is to call the Deactivate function through the iPoolable interface so that it performs the object specific stuff, then we take care of the operations that can be done on every single gameobject, like moving it in the poolHost so that our hierarchy is clean. Obviously you don’t necessarily have to reset the transform values, but if that’s something that causes you problems, well, you are doing something very wrong.

Last thing we do, is to put the reference to the gameobject inside the pool stack, so that its ready to be used.

    public GameObject Allocate()
    {
        if (pool.Count <= 0)
            ExpandPoolPopulation(expansionPoolSize, prefabReference);

        GameObject result = pool.Pop();

        result.SetActive(true);
        result.GetComponent<iPoolable>().Initialize();
        return result;
    }

Now that we know how the stuff gets inside the pool we can look to how it’s taken out of it. The allocate function first of all checks wether the pool is empity or not. It it’s empity you need more stuff, so you have to expand it.
If this allocation is too much for you, just raise the initialPoolSize and put an error message here, but you are more likely to be better off this way.

Then it recovers the gameobject instance from the pool and initializes it so that it’s prepared just as if it was instantiated right now and returns it to whatever script called this function.

That’s all folks!

Thanks for the attention, copy-pasteable code is just ahead. Remember that the populate function is quite expensive so you’ll probably need to use it behind a loading screen, if you don’t need to then you probably don’t need pooling either.

For any question please don’t hesitate to contact me on my twitter account, and if you don’t want to miss my next tutorial¬†consider subscribing to¬†my Newsletter!

And by the way, I’m currently looking for a job, if you think you may have one for me, take a look at my portfolio!

public interface iPoolable
{
  Pool source { get; set; }
  void Initialize();
  void Deactivate();
}


public class PoolHost : MonoBehaviour
{
    public static PoolHost instance;

    void Awake()
    {
        if (instance == null)
            instance = this;
        else
            Destroy(gameObject);
    }

    public static void Hold(GameObject poolable)
    {
        poolable.transform.parent = instance.transform;
    }
}


[System.Serializable]
public class Pool
{
    Stack<GameObject> pool;
    [SerializeField]
    int initialPoolSize;
    [SerializeField]
    int expansionPoolSize;
    [SerializeField]
    GameObject prefabReference;

    public void Populate()
    {
        pool = new Stack<GameObject>();
        ExpandPoolPopulation(initialPoolSize, prefabReference);
    }

    void ExpandPoolPopulation(int amount, GameObject prefabReference)
    {
        for (int j = 0; j < amount; j++)
        {
            GameObject result = GameObject.Instantiate(prefabReference);
            result.GetComponent<iPoolable>().source = this;
            PutInPool(result);
        }
    }

    public GameObject Allocate()
    {
        if (pool.Count <= 0)
            ExpandPoolPopulation(expansionPoolSize, prefabReference);

        GameObject result = pool.Pop();

        result.SetActive(true);
        result.GetComponent<iPoolable>().Initialize();
        return result;
    }

    public void PutInPool(GameObject handled)
    {
        handled.GetComponent<iPoolable>().Deactivate();

        handled.SetActive(false);

        handled.transform.position = Vector3.zero;
        handled.transform.rotation = Quaternion.identity;
        handled.transform.localScale = Vector3.one;

        PoolHost.Hold(handled);

        pool.Push(handled);
    }
}

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Platform dependent compilation: debug on event dispatcher

  • Part 1: basics event system
  • Part 2: event picker drawer for in-editor usage
  • Part 3: debugging with platform dependant compilation [you are here]
  • Part 4: multiple dispatchers
  • Part 5: optimization

In today’s tutorial I’ll delve in a bit of meta-programming, the obscure art of telling the compiler what to do to generate code, instead of plainly writing it yourself. But don’t worry,¬†at the end of the day, we’ll be using just an if. In this tutorial we’ll be¬†editing my event-system in order to add a debugging feature to it, so that we can log what handlers get invoked on what events and comfortably control that in the inspector.

Platform Dependent Compilation
Platform Dependent Compilation allows you to change code depending on target platform

What’s Platform Dependent Compilation again?

It’s a nice trick you can use in unity to avoid burdening one platform with the code that’s only required for another one. And something that will render your in-editor tests useless when found in some platform-specific plugin, as I learned the painful way. In Unity3d is done by taking one compiler directive to check if some constants are already defined.¬†Unity will define these constants according to build target. If you are developing, for instance, with pc as build target and write¬†#if¬†UNITY_ANDROID¬†all the following code until the¬†#endif¬†will be as commented from the IDE’s point of view.

And when it’s time to build your code, that stuff will just be treated as a comment and not be included in your final build… unless you are building for that platform. In that case that code will be there as if nothing happened.¬†This can be very useful, for instance, when it comes to dealing with input methods in a cross-platform game that’s both on mobile and pc.

Lets debug this
Lets debug this

How do we use Platform dependent compilation to debug an event system?

Basically, the only place where we’ll need it is the editor, so we’ll check for the variable¬†UNITY_EDITOR¬†and that’s it.

And here’s what we’ll need to add to our event script in terms of variables:

#if UNITY_EDITOR
    public bool debug;//print debug when any event is broadcasted, unless debugSpecificEvent is true, in which case only that one event is debugged
    public bool debugAdds; //print debug when any listener is added
    public bool debugRemovals;//print debug when any listener is removed
    public bool debugSpecificEvent;//print debug when a specific event is broadcasted, after each callback, 
    public EventPicker picker; //component that gives the UI element to select the event to debug with dropdowns
    //invoked after a debugAll check
    bool shouldDebugEvent(Enum ev)
    {
        return (!debugSpecificEvent) || (ev.ToString().Equals(picker.Selected.ToString()));
    }
    
    void OnValidate()
    {
        if (debugSpecificEvent)
            debug = true;
    }
#endif

So, inside the platform dependent code block we insert a series of flags and an EventPicker so that we’ll be able to manage what to debug when and even select a specific event to debug in isolation.

There are a couple of lines of code there that aren’t actually variables, let’s explain them:

  • shouldDebugEvent is a function,¬†returns true in two cases, either when¬†we’re not debugging a specific event, or when the event in argument is the one selected in thepicker.
  • OnValidate is a monobehaviour method that is invoked every time the data is changed in the inspector. In this case we want to ensure that when we’re debugging a specific event thedebugflag isn’t forgotten since it’ll need to be true to actually print anything.

Then we’ll need to change quite drastically our Broadcast , AddListener and RemoveListener functions.

This is our new broadcast:

    public static void Broadcast(eventChannels evType, Enum ev, eventArgExtend e)
    {
#if UNITY_EDITOR
        //if the flags are true prints a list of what is going to be invoked before execution
        var list = ListenerFunctions[evType][ev].GetInvocationList();
        if (list != null && debug &&  shouldDebugEvent(ev))
        {
            Debug.Log("EventHandleManager Broadcast" + evType + " - " + ev + " calling " + list.Length + " functions:");
            for (int i = 0; i < list.Length; i++)
            {
                Debug.Log(evType + " - " + ev + " [" + i + "](" + list[i].Method.DeclaringType.ToString() + ">" + list[i].Method.ToString() + ")");
            }
        }
#endif
        //invoke event delegates
        ListenerFunctions[evType][ev](e);
#if UNITY_EDITOR
        if (debug &&  shouldDebugEvent(ev))
        {
            Debug.Log("EventHandleManager Broadcast - OVER");
        }
#endif
    }

The first thing that’s coming to many people’s mind right now is: “wait, what the fuck is that Method.ToString()?!”. Well, it’s C# reflection again. It keeps creeping in, but what we say to the god of the 10’000-words-long tutorials?

t4w9s7

So, just know that that debug code will print the name of the classes and the functions that the event dispatcher will invoke.
In the beginning¬†we recover the list of functions that will be called from the delegate with GetInvocationList, then (provided this event broadcast should be debugged) for each one of them we’ll print its name and¬†source, along with the¬†position number.

Then we invoke the functions, and at last¬†we print a nice “over” after the event reactions are finished.

Registering and unregistering

    static void AddListener(eventChannels evType, Enum ev, gameEventHandler eventListener)
    {
#if UNITY_EDITOR
        //if this event's execution should be logged, add a debugging delegate before the method
        if (debug && shouldDebugEvent(ev))
            ListenerFunctions[evType][ev] += new gameEventHandler(delegate (eventArgExtend e)
            {
                Debug.Log("EventHandleManager execution" + evType + " - " + ev +
                    " finished " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
            });
        if (debugAdds)
            Debug.Log("EventHandleManager Added event " + evType + " - " + ev +
                        " by " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
#endif
        ListenerFunctions[evType][ev] += eventListener;
    }

Here we do two things: in case the event broadcast debugging is active for this event we add a delegate that prints event¬†channel, event name, invoking class and method name. Then, if we’re debugging registration we also log that, again with the same debug message.

The latter will also be done for the unregister function:

    public static void RemoveListener(eventChannels evType, Enum ev, gameEventHandler eventListener, Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> target)
    {
#if UNITY_EDITOR
        if (debugRemovals)
            Debug.Log("EventHandleManager Removed event " + evType + " - " + ev +
                        " by " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
#endif
        ListenerFunctions[evType][ev] -= eventListener;
    }

Here again we log all the same information when the listener is removed from the event.

So, wrapping this up, we’ve added debugging features to our event dispatcher and can now place it in any scene so that we can handle the debug operations in it using¬†the inspector. As usual the full code is down here for copy-paste purposes, we’ll get next time to the semi-final form of the script that will allow not just one single dispatcher in the whole game but multiple independent channels of communication so that for instance a single character can have its own internal event system. Register to the newsletter if you don’t want to lose it and hit me on twitter for any questions!

And by the way, I’m looking for a job right now, check out my portfolio here!

using System;
using System.Collections.Generic;
using UnityEngine;

public class eventHandlerManager : MonoBehaviour
{
#if UNITY_EDITOR
    public bool debug;//print debug when any event is broadcasted, unless debugSpecificEvent is true, in which case only that one event is debugged
    public bool debugAdds; //print debug when any listener is added
    public bool debugRemovals;//print debug when any listener is removed
    public bool debugSpecificEvent;//print debug when a specific event is broadcasted, after each callback, 
    public EventPicker picker; //component that gives the UI element to select the event to debug with dropdowns
    //invoked after a debugAll check
    bool shouldDebugEvent(Enum ev)
    {
        return (!debugSpecificEvent) || (ev.ToString().Equals(picker.Selected.ToString()));
    }
    
    void OnValidate()
    {
        if (debugSpecificEvent)
            debug = true;
    }
#endif
    public static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> ListenerFunctions = initializeDicts();

    public static void Broadcast(eventChannels evType, Enum ev, eventArgExtend e)
    {
#if UNITY_EDITOR
        //if the flags are true prints a list of what is going to be invoked before execution
        var list = ListenerFunctions[evType][ev].GetInvocationList();
        if (list != null && debug &&  shouldDebugEvent(ev))
        {
            Debug.Log("EventHandleManager Broadcast" + evType + " - " + ev + " calling " + list.Length + " functions:");
            for (int i = 0; i < list.Length; i++)
            {
                Debug.Log(evType + " - " + ev + " [" + i + "](" + list[i].Method.DeclaringType.ToString() + ">" + list[i].Method.ToString() + ")");
            }
        }
#endif
        //invoke event delegates
        ListenerFunctions[evType][ev](e);
#if UNITY_EDITOR
        if (debug &&  shouldDebugEvent(ev))
        {
            Debug.Log("EventHandleManager Broadcast - OVER");
        }
#endif
    }
    static void AddListener(eventChannels evType, Enum ev, gameEventHandler eventListener)
    {
#if UNITY_EDITOR
        //if this event's execution should be logged, add a debugging delegate before the method
        if (debug && shouldDebugEvent(ev))
            ListenerFunctions[evType][ev] += new gameEventHandler(delegate (eventArgExtend e)
            {
                Debug.Log("EventHandleManager execution" + evType + " - " + ev +
                    " finished " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
            });
        if (debugAdds)
            Debug.Log("EventHandleManager Added event " + evType + " - " + ev +
                        " by " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
#endif
        ListenerFunctions[evType][ev] += eventListener;
    }

    public static void RemoveListener(eventChannels evType, Enum ev, gameEventHandler eventListener, Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> target)
    {
#if UNITY_EDITOR
        if (debugRemovals)
            Debug.Log("EventHandleManager Removed event " + evType + " - " + ev +
                        " by " + eventListener.Method.DeclaringType.ToString() + " >" + eventListener.Method.ToString());
#endif
        ListenerFunctions[evType][ev] -= eventListener;
    }
    public void OnDestroy()
    {
        ListenerFunctions = initializeDicts();
    }

    static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> initializeDicts()
    {
        Dictionary<eventChannels, Array> enumChannelEventList = ChannelEnums.getChannelEnumList();
        Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> result = new Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>>();
        foreach (var val in (eventChannels[])Enum.GetValues(typeof(eventChannels)))
        {
            result.Add(val, new Dictionary<Enum, gameEventHandler>());
            foreach (var ev in enumChannelEventList[val])
            {
                result[val].Add((Enum)ev, new gameEventHandler(delegate (eventArgExtend e) { }));
            }
        }
        return result;
    }
}
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Event system: tutorial for Unity3D & C#

  • Part 1: basics event system [you are here]
  • Part 2: event picker drawer for in-editor usage
  • Part 3: debugging with platform dependant compilation
  • Part 4: multiple dispatchers
  • Part 5: optimization

Today I’ll start presenting you the single most useful piece of code that I’ve ever written. Since writing it I used it in every single project I’ve made, however simple. Even in game jams.
I’m speaking of an Event System. A¬†class with no other purpose than to let other objects communicate with each other, with as little overhead as possible. And it’s implemented with delegates.

And it’s way better than SendMessage, if you ask me.

event_driven_programming

What’s an Event System?

Those of you who already know, just skip this paragraph. Still with me? good. The main problem you’ll have with SendMessage is that it needs to use a¬†method’s name as an input. So the object sending the message not only needs to know¬†what method should be invoked by the receiver, but also his name. In a case sensitive way. Want to change that name? too bad, the IDE won’t change the string for you. You’ll have to remember every single one of those and do it by yourself… or never change a function name ever again. Or remove one.

Sounds bad? it is. It’s a maintenance nightmare. Plus, it uses strings. Fuck strings. Strings are evil. They use your memory, trigger your garbage collector and spit on your mother. Never use them unless at gunpoint… and even then think twice about it and instead use an enum.ToString() if you can.

So what’s the solution?¬†we need something more like this: you need to send a message between objects (or scripts) when a “thing” happens. So the scripts in the other object react to the “thing”. The caller script doesn’t need to know who or how will do anything in reaction to the “thing”. It just needs to shout out “Hey! I have a thing here!” and eventually how big the “thing” is. For instance, “Hey! I have a 3.5 Damage here!”. Then the health script subtracts the damage and the particle script spills blood everywhere. But the collider doesn’t need to know that. The “thing” is an Event. Shouting is a Broadcast. The reactions are called Callbacks or Handlers.

But this is nothing I invented, you can just study it here or here, or even here.

What’s a Delegate?

As before, if you know already, just skip ahead. Delegates are something I wish they did teach me in university, because they are just awesome. To put it bluntly: in C# you can treat functions as if they were variables and pass them as an argument to other functions. This means that you can change behaviours of an object at runtime. Or have an object hold and call a function without it even knowing what it does. Absolute decoupling. A maintenance heaven.

Before you can use a delegate, you first need to declare its type. Which means telling the compiler which return type and what arguments will be assigned to it. Not its name. Not its content. Just the signature structure. Of course, if you use as a signature something like:

public delegate object nameFunct(object o);

you can then pass anything and get anything (but say goodbye to compiler type-checks).

After you have declared a delegate type, you can then declare a delegate variable and assign to it a function with a matching signature. Just like you would do with any other variable. If you still need to delve deeper you can go here or here.

Get on with it!

gowi-2

Now, if you have seen my portfolio the event system there can be quite intimidating, but don’t worry, we won’t be doing that version right now. We’ll start with version 0.0.3 while that one is 1.0.1 [edit: this was before optimizing for the last part of the tutorial]. That¬†makes¬†about 100 rows of code and 20 headaches of difference.

Before we get to the main class, the event dispatcher, let’s define some stuff we’ll use there.

public delegate void gameEventHandler(eventArgExtend e);

This will be our event signature. Nothing to return because we don’t want the event sender to have anything to do with the receivers. The event type is this thing here:

public class eventArgExtend : System.EventArgs { }

Why didn’t I use directlySystem.EventArgs?¬†Because in the future I may want to add something between those parentheses and when it happens it will¬†cost me nothing to do so. Had I used directly that type it could require more work to do it.

Now, let’s get to something more interesting: defining the events themselves. To do so I’ll use something infinitely superior to strings: enums.

public enum eventChannels
{
    inGame
}
public enum inGameChannelEvents
{
    thing
}

Now we’ll need a comfortable way to pass this information to the dispatcher.¬†For this¬†I just created a class with a static function:

public class ChannelEnums
{
    public static Dictionary<eventChannels, System.Array> getChannelEnumList()
    {

        Dictionary<eventChannels, System.Array> enumChannelEventList = new Dictionary<eventChannels, System.Array>();
        enumChannelEventList.Add(eventChannels.inGame, System.Enum.GetValues(typeof(inGameChannelEvents)));
        return enumChannelEventList;
    }
}

Notice: adding a channel requires to add a new enum type, and there is no automated way to set a link between an enum value ineventChannelsand an other enumtype. So for each channel you need to add, you’ll have to write a new row of code like the one just before thereturn.

What we did here is to create a static function for the dispatcher. The function will recovery every event channel and every corresponding array of values, so that we can initialize the list of listeners in the dispatcher. All in the nice form of a Dictionary.

Now let’s get to the Event System

Our event system needs to be usable at EVERY stage of game play. This includes the Awake function of the first objects to be present in the first scene. Which means that I can’t use the Awake function to initialize the event system, or I would get in a race condition. That’s fucked up. But years of Unity3D ninjutsu allowed me to discover a precious thing: default values are initialized before Awake, and you can get them with static functions.

public class eventHandlerManager : MonoBehaviour
{
    static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> ListenerFunctions = initializeDicts();

What’s thatinitializeDicts? we’ll see later. For now just look at the type of ListenerFunctions: it’s a dictionary of dictionaries. It allows us to index¬†gameEventHandler¬†delegates first by channel and then by event.

Now we can write the key functions of the dispatcher: one to raise an event, one to add a delegate as listener, one to remove it.

public static void Broadcast( eventChannels evType,Enum ev,eventArgExtend e) 
	{
		ListenerFunctions[evType][ev](e);
	}
	
	public static void AddListener(eventChannels evType,Enum ev, gameEventHandler eventListener)
	{
		ListenerFunctions[evType][ev]+=eventListener;
	}
	public static void RemoveListener(eventChannels evType,Enum ev, gameEventHandler eventListener)
	{
		ListenerFunctions[evType][ev]-=eventListener;
	}

Why are they all static? because that way you don’t need to get the other classes to find the instance. Yes, this is limiting: you can’t have a damage event that only gets notified to one character. But for something more selective¬†we’ll need to make a lot of changes, for the time being just add an identifier as field in the argument. Then have the receivers check that value. We’ll get back to that in future tutorials.

This is all that’s needed on the outside to use this event handler. Other classes that want to react to an event just need to declare a function that matches thegameEventHandlersignature and then invoke theaddListenerfunction giving that function as the last argument (without parentheses), and do the same for removal like this:

eventHandlerManager.AddListener(eventChannels.inGame, inGameChannelEvents.thing, onThing);

The broadcast use is even simpler:

eventHandlerManager.Broadcast(eventChannels.inGame, inGameChannelEvents.thing, new eventArgExtend());

So, now we’re almost done. There is just one last detail for the magic to fully work: how do we initialize and cleanListenerFunctions?

    public void OnDestroy()
    {
        ListenerFunctions = initializeDicts();
    }

    static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> initializeDicts()
    {
        Dictionary<eventChannels, Array> enumChannelEventList = ChannelEnums.getChannelEnumList();
        Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> result = new Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>>();
        foreach (var val in (eventChannels[])Enum.GetValues(typeof(eventChannels)))
        {
            result.Add(val, new Dictionary<Enum, gameEventHandler>());
            foreach (var ev in enumChannelEventList[val])
            {
                result[val].Add((Enum)ev, new gameEventHandler(delegate (eventArgExtend e) { }));
            }
        }
        return result;
    }

Wait a minute: did I initialize ListenerFunctions on destroy? Yes, because that is a static field. It will survive to the existence of the eventHandlerManager instance. And since that should only happen on a scene load, I can be sure that nothing should stay in the dictionary and that the new scene has a ready new clean slate to work on when the first Awake is called.

The initialization works by first getting the enum data from the static function we defined before in ChannelEnums, then using that data to initialize every field of the dictionary with an empitygameEventHandler; this way we can later add the Handlers with a+=instead of checking for a null field every time.

That’s all folks!

Not really. Actually there is a lot more that we can add to this class, mainly for debugging purposes, plus the “local” version of the event dispatcher that I mentioned before. But this tutorial is already huge, so maybe it’s better to deal with that stuff¬†next week. If you want to be sure not losing it, subscribe to my newsletter. For any feedback comments are below or you can just add me on twitter.

using System;
using System.Collections.Generic;
using UnityEngine;

public class eventHandlerManager : MonoBehaviour
{
    public static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> ListenerFunctions = initializeDicts();

    public static void Broadcast(eventChannels evType, Enum ev, eventArgExtend e)
    {
        ListenerFunctions[evType][ev](e);
    }

    public static void AddListener(eventChannels evType, Enum ev, gameEventHandler eventListener)
    {
        ListenerFunctions[evType][ev] += eventListener;
    }
    public static void RemoveListener(eventChannels evType, Enum ev, gameEventHandler eventListener)
    {
        ListenerFunctions[evType][ev] -= eventListener;
    }

    public void OnDestroy()
    {
        ListenerFunctions = initializeDicts();
    }

    static Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> initializeDicts()
    {
        Dictionary<eventChannels, Array> enumChannelEventList = ChannelEnums.getChannelEnumList();
        Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>> result = new Dictionary<eventChannels, Dictionary<Enum, gameEventHandler>>();
        foreach (var val in (eventChannels[])Enum.GetValues(typeof(eventChannels)))
        {
            result.Add(val, new Dictionary<Enum, gameEventHandler>());
            foreach (var ev in enumChannelEventList[val])
            {
                result[val].Add((Enum)ev, new gameEventHandler(delegate (eventArgExtend e) { }));
            }
        }
        return result;
    }
}

public enum eventChannels
{
    inGame
}

public enum inGameChannelEvents
{
    thing
}

public class eventArgExtend : System.EventArgs { }

public delegate void gameEventHandler(eventArgExtend e);

public class ChannelEnums
{
    public static Dictionary<eventChannels, System.Array> getChannelEnumList()
    {

        Dictionary<eventChannels, System.Array> enumChannelEventList = new Dictionary<eventChannels, System.Array>();
        enumChannelEventList.Add(eventChannels.inGame, System.Enum.GetValues(typeof(inGameChannelEvents)));
        return enumChannelEventList;
    }
}

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Unity3d WebGL input mapping for Xbox controller

So, this weekend ludum dare 35 happened and I made my entry using xbox 360 controller as my intended imput source. Only one problem there: no existing input guide spoke of how to map buttons on the Xbox controller for unity3d webGL. And that was my target platform.

So, long story short, here’s what I wasted precious jam time looking for:

xbox controller unity3d webgl input map

xbox_360_controller-button-map

For xbox controller usually you would have the triggers on the back as a 3rd or 5th axis, instead on webGL they are mapped only as standard buttons.

As for the axis: left stick is X and Y axis (as usual), right stick is 3rd and 4th axis.

You can set them like this:

xbox controller unity axis input
xbox controller unity axis input

By the way, there’s a simple way to test these mappings on your own!
You can just use this script:

public class testbuttons : MonoBehaviour
{
    [SerializeField]
    Text t;
    // Update is called once per frame
    void Update()
    {
        t.text = "";
        for (int i = 0; i < 20; i++)
        {
            t.text += "Button " + i + "=" + Input.GetKey("joystick button " + i) + "| ";
        }
    }
}

Make an empty scene, add a UI>Text element and stick this script on it. Then run it and read what turns to true when any button is pressed on your controller.

As easy as pie… unless you are in a game jam frenzy, with severe sleep deprivation and panicking like I was…¬†Want more tutorials like this? Join my newsletter! Want to tell me anything? Hit me up¬†on twitter.

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Validating email in C#

Input sanitation is a must when dealing with web services, but it’s also smart to avoid to waste precious seconds in registration procedures due to a wrong email address. That’s true in web development, that’s true in mobile apps, that’s just true on any digital platform.
So it’s best to validate email in unity3d too before any web service is called.

The variables

First we get the references via unity editor to catch both theInputFieldandButton.

    [SerializeField]
    InputField mail;
    [SerializeField]
    Button sendButton;

Then we create aRegexusing the mail validation pattern from .Net framework (be aware, it’s not perfect, but it’s good enough).

    System.Text.RegularExpressions.Regex mailValidator = new System.Text.RegularExpressions.Regex(@"^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$");

TheRegexclass will provide us with a pattern-matching function that we can easily use to check if the pattern on which is built does or not match any input. The pattern will follow the regex syntax. Which by the way I found out not to be a regular expression language any more due to backreferences.

Validate email

Then, on eachUpdatewe first reset the button’s state, then we make it notinteractableagain only if any of the validation criteria is false. So only if the mail validation check DOES NOT recognize¬†our string as a mail¬†address it should make it notinteractable, but in the converse case it shouldn’t make itinteractablesince another validation criteria may fail independently.

    void Update()
    {
        sendButton.interactable = true;

        //other sanitation for other stuff

        if (!mailValidator.IsMatch(mail.text))
                sendButton.interactable = false;
    }

That’s all folks!

Really? really.
It’s not more than just 15 lines of code but it’s a big deal in reducing friction during your registration process for any service or game. If you like this kind of tutorial or just want to hear from me in the future, join my newsletter.

And here’s everything ready for¬†copy-paste :

    [SerializeField]
    InputField mail;
    [SerializeField]
    Button sendButton;
    System.Text.RegularExpressions.Regex mailValidator= new System.Text.RegularExpressions.Regex(@"^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$");
    void Update()
    {
        sendButton.interactable = true;

        //other sanitation for other stuff

        if (!mailValidator.IsMatch(mail.text))
                sendButton.interactable = false;
    }
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Webservices in unity3d: Post, JSON and wait

Working with webservices in mobile apps is quite a common task, ¬†but what if you are developing in Unity3d and need to send a Post¬†request with JSON data? Well, there’s a quick and painless way of dealing with it, in less than 40¬†lines of code, complete of “wait…” screen management, from call to loggable answer.

First of all we’ll need a little coroutine and a JSON script you can get here.

The coroutine

It’s actually a very small one:

    IEnumerator afterConditionExecutor<T>(System.Action<T> del, T param, bool cond)
    {
        while (!cond)
        { yield return new WaitForEndOfFrame(); }
        del(param);
    }

This will just wait for our condition to be true, then execute the delegatedelgiving it the parameter it needs. We could just put here our wait screen control code, but you may want to customize it so we’ll handle that later (plus, this coroutine is so generally useful, you may want to put it in a library).

Sending the Post request

Let’s get to the meat of the issue, where the POST request is sent along with all our JSON data:

    public void sendMessage(JSONObject data, string url, bool addCookie, MonoBehaviour reqSource, System.Action<WWW> callBack)
    {
        Dictionary<string, string> headers = null;
        if (addCookie)
        {
            headers = new Dictionary<string, string>();
            headers.Add("Cookie", "SomeHeaderContent");
        }

        byte[] pData = Encoding.ASCII.GetBytes(data.ToString().ToCharArray());

        WWW www = new WWW(url,pData, headers);
        reqSource.StartCoroutine(afterConditionExecutor<T>(delegate (WWW mmm)
        {
            Debug.Log("sendMessage to: " + mmm.url + " returned: " + mmm.text);
            callBack(mmm);
        }, www, www.isDone);
    }

In the first part we prepare the request headers. Those are tipically the same across all webservice requests (eg.: login tokens) so it can be convenient to just generate them there and have a bool to control if they are added or not. Otherwise just add a parameter and pass it along from the source.

After that we encode ourJSONObjectin a byte array, so that is in the right format for theWWWobject constructor¬†to pick up. When this constructor is called the webservice request will be sent as a POST http request, but we cannot just parse the reply right away because it won’t be ready. Even for whole seconds. Since it would be too long of a time to freeze our game/app, this call is conveniently Asynchronous. When is done,WWWclass will tell us by turning true thewww.isDoneflag (see reference docs¬†here).

This is the reason why we start a coroutine on behalf of the message-sending class that will use our coroutine to wait until the proper moment and then call our callBack function.

Since there may be some standard error handling to do (eg: no internet connection) we do this inside a dedicated delegate that is passed as argument to the coroutine. Notice that theWWWargument of the delegate is named differently from the object we are just creating so that it links to the one being passed from the coroutine as an argument, this avoids a compilation error.

Let’s see a usage example:

    public void executeLogin(string username, string password)
    {
        JSONObject loginReqJS = new JSONObject();
        loginReqJS.AddField("username", username);
        loginReqJS.AddField("password", password);

        waitLayer.SetActive(true);
        sendMessage(loginReqJS, "http://your url/request/url", false, this, delegate (WWW www)
        {
            waitLayer.SetActive(false);
            Debug.Log("executeLogin to: " + www.url + " returned: " + www.text);
        });
    }

The first thing we do here is to prepare aJSONObjectwith the appropriate parameters for¬†the situation, then we activate our “wait” UI element and finally call oursendMessagefunction.

Inside the delegate that will handle the server reply we also¬†make our “wait” screen go away (non-standard error handling goes here, eg: wrong password), in this case we just log what’s been returned, but in real-life cases you’d transition from a login to your main menu.

This will produce the following http request:

POST /request/url HTTP/1.1
Cookie: "SomeHeaderContent"

{"username":"username","password":"password"}

And here you go. Hope you’ll find this tutorial useful. For more unity3d tutorials join my newsletter¬†ūüėČ

Here’s everything in a more copy-pastable format:

    IEnumerator afterConditionExecutor<T>(System.Action<T> del, T param, bool cond)
    {
        while (!cond)
        { yield return new WaitForEndOfFrame(); }
        del(param);
    }

    public void executeLogin(string username, string password)
    {
        JSONObject loginReqJS = new JSONObject();
        loginReqJS.AddField("username", username);
        loginReqJS.AddField("password", password);

        waitLayer.SetActive(true);
        sendMessage(loginReqJS, "http://your url/request/url", false, this, delegate (WWW www)
        {
            waitLayer.SetActive(false);
            Debug.Log("executeLogin to: " + www.url + " returned: " + www.text);
        });
    }

    public void sendMessage(JSONObject data, string url, bool addCookie, MonoBehaviour reqSource, System.Action<WWW> callBack)
    {
        Dictionary<string, string> headers = null;
        if (addCookie)
        {
            headers = new Dictionary<string, string>();
            headers.Add("Cookie", "SomeHeaderContent");
        }

        byte[] pData = Encoding.ASCII.GetBytes(data.ToString().ToCharArray());

        WWW www = new WWW(url, pData, headers);
        reqSource.StartCoroutine(afterConditionExecutor<T>(delegate (WWW mmm)
        {
            Debug.Log("sendMessage to: " + mmm.url + " returned: " + mmm.text);
            callBack(mmm);
        }, www, www.isDone);
    }

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •