Unity Coding Tips Part 1: Events and Delegates

[juicymangoze]

Whilst I find the plug-ins from Prime31 great, the attitude and C# snobbery is pure amateur.

Sorry, but I've now spoken to a few very very experienced game technicians (i.e. they're not just programmers, they build engines, tools etc), and they've taken a look at Unity and Javascript (mono), and said that C# is not superior in any way, and in fact, said Javascript actually made more sense for unity.

So get off your high horse Prime31

[prime31studios]

@juicymangoze 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)

[PoorOldRisingSun]

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!

[freakoid99]

@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.

[johnny3734]

There's nothing wrong with JavaScript, I think it's the funnest to code out of any.

[1970mcgraw]

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 :-)

[Octamed]

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 :)

[chemicalvamp]

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

[RecluseIndustries]

@chemicalvamp 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.

[markhula]

Top stuff!

[markhula]

Top stuff!

[HokutoTC]

Hi Again, I started to use them in my code and I got it to work for me. Initially I thought I could trigger the event from anywhere so I had problems; "events can only be invoked from within the class that declared them" (msdn)... just as you did in your video with the GUi.Button. (msdn does talk about protected invoking method to allow derived classes to invoke events, but for me is baby steps now :)).

[HokutoTC]

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

[Octamed]

@HokutoTC 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

[St4rdog]

This seems similar to "CSharpMessenger Extended" (google it). Other than performance is there any reason it's better? I notice for one thing you will get AutoComplete for the event name, instead of having to type a string.

[prime31studios]

@St4rdog its similar but the key difference is that native events are associated with an object whereas the Messenger Extended is a string based publisher/subscriber system.  Events will be faster due to skipping the initial string match.

[HokutoTC]

Great tutorial, practical and to the point. Thanks!

I found some generic information about this topic online but your example did it for me, will be using events/delegates from today :) - please do more :) c#/Unity :)

QUESTION: In term of performance on iOS, are events/delegates (with maybe quite a few events and listeners in a scene...) good to use or is there some performance issue compared to use some other solution to do the same things?

[prime31studios]

@HokutoTC performance will be excellent on mobile. Events are WAY faster than SendMessage and will beat out any alternatives (like subscriber/message solutions).

[spaaske]

Thanks for your effort prime31studios, I'm a developer switching from AS3 to C# and this was exactly what I was looking for. So happy you made this :)

[lucidskater]

any tips for learning from scratch, i cant seem to find a good tutorial for someone who doesnt know how any of it works

[prime31studios]

@lucidskater there is an absolutely vast amount of C# tutorials for beginners on the web. That is one of the major reasons I always suggest C# over UnityScript. If you search the web for UnityScript tutorials you find next to nothing because it only exists in Unity. C# on the other hand has literally thousands of books and countless tutorials available.

[prime31studios]

@lucidskater a quick web search will get you literally thousands of C# tutorials for beginners. There are also tons of books as well.

[juicymangoze]

@lucidskater and you won't.

[ferrouswheel]

Wow - thanks! I went and created some adhoc event system using C# reflection, but I wish I'd found this first. Oh well - at least it was a learning experience.

[evilrobotmechanic]

@Prime Thank you so much for this video. I have been looking for ways to help me to improve my c# skills and this fits the bill!

I was thinking a good way to apply this was to have a "game manager" listen to player events (health, ammo, state), then have the manager broadcast the events to the UI objects like updating the health bar.

Would this be an appropriate way to utilize events and delegates?

[prime31studios]

@evilrobotmechanic that sounds like a good use. Messengers could be a good topic for another tutorial video also...hmmm...

[JessyUV]

Oh, where were you before last September when I taught myself about events?! :-O Good stuff; events have changed my Unity coding life so much for the better, and this is a great intro to them. A couple questions, though, on convention. You used camelCase for onPoweredUp. I've used PascalCase for my events. Have you found a standard on this? The references I've found seem to use PascalCase. And what about the use of the prefix "On"? Got any info on standards for its usage? Thanks!

[blackishgames]

Thanks a lot! Very, very useful!

[3duaun]

such a useful tut, thanks Prime31, cant wait to see more!

[jjonasz]

Great video! What would be the benefit/difference of using events instead of a Messenger system?

[prime31studios]

@jjonasz a messenger system is very similar. The difference here is mainly that you are listening to a specific event on a specific object and getting under the covers native Mono performance. A quick example based on the bouncing boxes in the tutorial: you could have a split screen game with 2 players playing at the same time. When player 2 gets a power up, you only want the boxes on player 2's screen to bounce so you could have a manager object for each player posting the events.

[TravisTouch]

one word: AWESOME

[maglat]

AMAZING! I love you prime :)