Unity Coding Tips Part 1: Events and Delegates

Unity Coding Tips Part 1: Events and Delegates

The first tutorial in a series aimed at showing some of the more esoteric features available to Unity developers. In this tutorial, we cover the basics of events and delegates. You will learn some simple techniques to make your code a lot more coherent and easier to manage. This directly relates to our plugins (prime31.com many of which employ events for dispatching asynchronous operations.
Video Tutorial Rating: 5 / 5

Don’t forget to check out our other video tutorials or share this video with a friend.

1 Star2 Stars3 Stars4 Stars5 Stars 0 votes
Loading... 2,794 views





19 responses to “Unity Coding Tips Part 1: Events and Delegates”

  1. Patrick Davis says:

    I just stumbled on this from the iTween website, and I wanted to thank you guys for putting this out here. Events are something I’ve struggled with in other languages and being new to C# having a clear discussion of what is a very elegant solution is great. Thank you!

  2. hozoneTV says:

    Thanks ;D

  3. Simon Drexler says:

    I really want to thank you for this video - first time i really understood delegates and Events, thanks a lot!!

  4. evilrobotmechanic says:

    I want to create a sound effects manager that manages all the audio in my scene.

    However, instead of having multiple listeners and one manager firing off the events to all of them, like in your video, the way I am doing it will yield one listener listening to multiple eventManagers in a scene. It’s basically backwards.

    While it seems to work, is this an incorrect usage of Events and Delegates?

  5. aaronlloydpeterson says:

    Observer pattern! Isn’t this the most important game development pattern? Surprised there aren’t more Unity videos about it.

  6. Florent POUJOL says:

    Hi, great tuto, but I have got 2 questions :
    Why use the “event” keyword since it works without it ?
    Wen you click on the buttons several times, it seems from the console output that the methods are called only once ? Why is that ?
    Thanks.

  7. David Kingsbury says:

    Your post is filled with so much “WTF”, I don’t even know where to start with a response.

  8. derkoi says:

    Thank you, I’m just learning and this was just what I needed to get buttons from your UIToolkit to do something. I have my eye on a few of your plugins too. Thanks again. 🙂

  9. prime31studios says:

    Many thanks for including your opinion just as we did in the video. We are making tutorial videos and thus would like those watching to be using the best tool. The advantages of C# over JS are concrete and there are many of them but that is a discussion too large for here. Some advantages are:
    - TONS of C# learning/documentation resources
    – language features that are not available in JS
    – no sneaky compiled code (look at compiled output of JS transform.position.x = 3 as an example)

  10. RecluseIndustries says:

    actually it isn’t – once your C#, JS or Boo scripts are compiled they all run the same – Unity would never have used it otherwise.

  11. PoorOldRisingSun says:

    This is a wonderful tutorial! I went from a modest understanding of listeners and subscriptions to feeling ready to begin using them in complex applications in just 11 minutes. I found it especially helpful that you took time to explain each line and its role using both proper terminology and newbie-friendly explanations. Thanks a bunch!

  12. freakoid99 says:

    @johnny3734 I used to think the same thing. (I started out with unityscript for unity) but what it comes down to is.. there aren’t any resources available for unityscript (unity does not use pure javascript!) and there are myriads of resources available for c#. If you’re smart, you’ll drop unityscript and use c# asap. You’ll thank me later.

  13. Mike McGraw says:

    Thanks for this tutorial – I’ve been hacking around in Unity for a while but have decided to grow up a bit and learn to do some things correctly. Enjoyed the first tutorial – looking forward to following along with the rest 🙂

  14. Octamed says:

    to get around having to check for null everytime you fire an event you can give it a single empty delegate so you technically never have zero listeners.
    eg
    static event DelegateThing OnThingEvent = delegate {};
    It’s messy but it works well 🙂

  15. Octamed says:

    A common method is to put events in a seperate postoffice style class. Each event then has a method to invoke it. So this solves the ‘must be called from the same class’ problem PLUS allows you to intercept event calls and do sanity checks and debugging easier. In fact ReSharper for visual studio will write the invoker function for you (maybe plain VS does too).
    The other way around it is to NOT use events, just delegates alone which don’t have those restrictions, but it’s more risky

  16. chemicalvamp says:

    You forgot to mention C# is 20 times faster than java script.

  17. markhula says:

    Top stuff!
    

  18. markhula says:

    Top stuff!
    

  19. HokutoTC says:

    So what I am doing for now is having a – public static bool varName – that I can set to true or false from anywhere/any script, then if this static var is true my event is set to true (triggered) in the class that declared the event.

    Is this ok, or maybe I am overusing static variables and it would be better/safer to trigger events in a different way? Really happy about this video tutorial, I started using events/delegates only after watching this. Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *