Understanding events and actions.

Hey Nemox!

I had problems with events too, but after seeing a short example and just looking at it an inspecting it, I understood how they work. Here's the code:

class Button   // Button.cs
{ 
	public event Action Clicked;    //An event taking in a type delegate Action. 
	public void OnClick()     //The way we will initiate ALL the subscribers of the event Clicked.
		{ 
			if (Clicked != null)   //We check if any action is subscribed to our event. You must always do this.
			{ 
				Clicked();     //We initiate ALL actions subscribed to this event.
                        } 
		} 
 } 

class Program  //Program.cs
{

public void Main() 
{ 
     Button button = new Button();   //We create an object called button, from the Button class
     button.Clicked+= HandleClick;   //We subscribe the function HandleClick to the event.
     button.OnClick();               //We initiate all the subscribed functions to the event.

     Console.WriteLine();  //ignore this, it's just so it adds a line between both calls.

     button.Clicked+= AnotherClick;  //We can subscribe as many functions as we want.
     button.OnClick(); 

     Console.Readkey();
} 

    private void HandleClick() //This is the action we subscribed to the event.
	{ 
	Console.WriteLine("The Button's Click event was fired"); 
	} 

    private void AnotherClick() //This is the action we subscribed to the event.
	{ 
	Console.WriteLine("The Button's Click event was fired AGAIN!"); 
	} 

}

Of course we are not actually clicking here, I've just used it as an example.

So the output of this program would be.

The Button's Click event was fired

The Button's Click event was fired
The Button's Click event was fired AGAIN!

I encourage you to just look and inspect this code, and event's will be cleared up for you in no time. Feel free to ask anything about the program you don't understand.

Also, you can unsubscribe actions from the events too. So you would basically say:

button.Clicked -= HandleClick;

This will remove the function HandleClick() from firing when the OnClick() event is triggered.

Unsubscribing is an essential part of using events. Sometimes when you have an event subscribed you unsubscribe It right after its used. So it can be triggered again next time. That way you can use one event handler like OnClick(), and check if different events have been subscribed to and fire them when they do.

Cheers!

Pseudo--code for a non-GUI approach:

if(Inventory.checksForItems("Sword"))

{
// sets off event flag

eventScene = true;

}

Thanks for the posts! I'm sure this will be super helpful!

For example, I might need to have something happen when the player equips an item.

i find that event processing is usually easiest handled at the time it occurs, where it occurs. this avoids the need to store events and process them later, or use messaging systems or "event handlers" and such. although there are some events which are best stored and processed later all at once.

so for example, in the code that adds an item to the inventory, your invetory.add_item() method, you'd add a check like:

if (item==SWORD_ULTRA_BADNESS) message("You got the sword of ultra badness!");

generally speaking, storing data when you can just process it now is probably inefficient, overkill, and over-engineering.

however, i suspect we (gamedevs) all tend to over-engineer things a bit.

For example, I might need to have something happen when the player equips an item.

i find that event processing is usually easiest handled at the time it occurs, where it occurs. this avoids the need to store events and process them later, or use messaging systems or "event handlers" and such. although there are some events which are best stored and processed later all at once.

so for example, in the code that adds an item to the inventory, your invetory.add_item() method, you'd add a check like:

if (item==SWORD_ULTRA_BADNESS) message("You got the sword of ultra badness!");

generally speaking, storing data when you can just process it now is probably inefficient, overkill, and over-engineering.

however, i suspect we (gamedevs) all tend to over-engineer things a bit.

Indeed, but there are some things I will definitely need it for. For example, if a character has a passive special ability that lets him instantly attach to walls and climb up them, I'd much rather that work based off an event rather than having to hard-code it into the controls and have to handle it for every individual character.