A race was taking place on the other side of a tall brick wall to James so he couldn’t see what was taking place in the race. He wanted to set off fireworks when a winner crossed the finishing line. Despite not being able to see the race directly, a light was placed above the brick wall that lit up when a winner crossed the finish line. By watching this light, James could set off fireworks when it lit up. The winner crossing the finish line is referred to as an event.
	Events in the overwatch workshop follow the same idea. The rule represents James, waiting for the light on the game box to turn on indicating that something has happened, for example a player taking damage.
	By creating a new rule that listens for the event of player taking damage, we can perform actions when that occurs. In this case, the action will be to pause the game time.
	Testing this rule, we can see that when a player takes damage, the game time is paused.
	The next race came around and James wanted to do something more this time. As well as setting off fireworks when the winner crossed the finish line, he wanted to have the winner’s name appear on a display. Thankfully, the race itself had also been upgraded. Though there was still a wall between James and the race, there was new a digital display instead of a light that turned on when a winner crossed the finish line. As well as indicating that there was a winner, the display also showed information about the winner, such as their name, picture, time taken to finish the race and so on.
	This information that is passed alongside the event allows us to perform specific actions and check specific conditions based on the player that the event occurred to. In the overwatch workshop, all information about the relevant player is passed through event player.
	Similarly to James, we may want to create a rule such that when a player takes damage, the hero that they are currently playing is written on the top of the screen. For this, we create a rule that listens for the player take damage event. The action can be to create a big message (this is text that appears on the top of the screen), shown to all players, where the text shown is the hero of the event player. As the event player is the one who took damage, the hero that they are playing will be the hero that took damage, and will be written on the top of the screen.
	Taking self-damage on pharah shows this to be true, as when the rocket impact damage hits, the hero being damaged – pharah – is written on the top of the screen.
	The scope of events can also be limited. In the race example, James may only want to be told about a winner of the same nationality of him. In the workshop, events can be limited by team which allows for each team to have different behaviour and by slot, allowing for each individual player to have different behaviour.
	The next race came along, and it was upgraded even further. As well as the displays that showed notable events, a live video stream of each of the players was shown. This meant that James could monitor every player to see who was in the lead.
	These are referred to as ongoing events. They do not run when a specific event happens, but constantly runs throughout the race, allowing spectators to pick out the information about the players relevant for them. In James’ case, the distance travelled.
	The two ongoing events available inside of the workshop are global and for each player, and both run every game cycle but are slightly different.
	The global ongoing event does not pass though an event player, and is used to act on the game state as a whole. For example, checking if a game is in progress, if any players are within the capture area of an objective and how many players are left alive. A global ongoing event may be used to declare one team victorious should they have more players alive upon capturing an objective.
	The player ongoing event runs for every player in the game, passing in each player as the event player for that player. It’s as if when using the on damage event, every player in the game took damage all the time, and allows for more complex behaviour.
	Say we want a player to die when they come in contact with the ground. Player touching ground is not an event available in the dropdown, so we select ongoing each player. In the conditions tab, add a new condition. We want to check if the player is on the ground, so in the first value dropdown select is on ground. The event player this case is the current player being checked, and will go through every single player in the game in turn, so we want to check if the event player is on the ground. If this condition returns true, the current event player is on the ground so we want to kill them. Add an action to kill the event player, leaving the killer on null.
	In the next guide, I will be going through actions in more detail. If you have any questions about the content of this video feel free to ask, and any feedback regarding how I made this guide is appreciated.