I don’t know whether it’s different within Unity (just come back after a long time away and still only exploring this wonderful software.)
However, events, C# style:
// Player.cs
namespace PlayerStuff
{
public delegate void PlayerRespawnedEventHandler(float x, float y);
class Player
{
public event PlayerRespawnedEventHandler PlayerHasRespawned;
private Vec2 m_pos;
public Player(Vec2 pos)
{
// Initialise player
m_pos = pos;
}
// Lots of player stuff
private PlayerDied()
{
// Respawn player
// null check not necessary, but helps
if(PlayerHasRespawned != null)
{
// All listeners will be invoked
PlayerHasRespawned(m_pos.x, m_pos.y);
}
}
}
}
Then some other file
// GameEvents.cs
namespace GameStuff
{
class Status
{
// Doing stuff
public Status()
{
// Get handle to player game object
// Now hook up to event
playerGameObject.PlayerHasRespawned += new PlayerRespawnedEventHandler(ActOnRespawn);
}
private void ActOnRespawn(float x, float y)
{
// Do the funky chicken.
}
}
]
The event that Player exposes is of type PlayerRespawnedEvenHandler. This defines the data that will be supplied when the event is called. Our GameStff class wants to know when a player has respawned and so after getting a handle to the instance (will be via a Unity API call, I guess) can hook up to the event. It is effectively saying when the event happens, I’ll (GameStuff) do some actions that you (Player) don’t need to know about. You could also say Player has delegated some work away from itself, but given the paradigm, it’s verging on chicken/egg debate. Anywho, the GameStuff tells the event that when it is invoked, it should call the function ActOnRespawn, which as we can see, has the necessary parameters in the function definition.
So, when the player dies, we’ll assume PlayerDied gets called to respawn the player. Within this, it checks to see if anyone cares about the event (not a necessary check, but a good safety) and will invoke the event if necessary. You can think of this as calling a function, as that is pretty much what it is, it just doesn’t know if/where these functions are in memory until they are hooked up at runtime.
In your case, you could simply define the event as an EventHandler, which takes no arguments (and means no need for declaring the delegate) so Player.cs would be:
namespace GenericEvents
{
class EventTriggerer
{
public event EventHandler OurEvent;
public void TriggerEvent()
{
if(OurEvent != null)
{
OurEvent();
}
}
}
class OtherObject
{
private EventTriggerer m_trig;
public SomeFunction()
{
if(GUI.Button)
{
m_trig.TriggerEvent();
}
}
}
}
Every object that was going to trigger the event would need a handle to the object that contained the event to be triggered, but it would enable that event to be triggered by any other given object at any time and so anything that was in turn subscribed to the event OurEvent would be invoked accordingly.
Hopefully that makes sense. It’s late and when you use something every day, it sometimes becomes difficult to explain clearly without going into too much, unnecessary detail.
