Category: Programming

Sebastian Lague A* Tutorial Series – Algorithm Implementation – Pt. 03

digm520admin / / A*, AI, Programming, Tutorial, TutorialList, Unity
November 20, 2019

A* Tutorial Series

Pt. 03 – Algorithm Implementation

A* Pathfinding (E03: algorithm implementation)

Link – Tutorial

By: Sebastian Lague


Intro:

Since these sections are very coding intensive, I just setup a breakdown into the different classes that are worked on. I try to discuss anything done within the class in that class’s section here. As should be expected, they do not continuosly do a single section and move to the next, they jump back and forth so that the references and fields make more sense for why they exist, so I try to mention that if needed.

Pathfinding

This class begins to implement the psuedo code logic for the actual A* algorithm. It starts with a method, FindPath, that takes in two Vector3 values, one for the starting position and one for the target position. It then uses our NodeFromWorldPoint method in AGrid to determine which nodes those positions are associated with so we can do all the work with our node system.

It then creates a List of nodes for the openSet and a HashSet of nodes for the closed set, as seen in the psuedo code. It is around here that they begin to update the Node class since it will need to hold more information.

The next part is the meat of the algorithm, where it searches through the entire openSet to determine which node to explore further (by using the logic of finding the one with the lowest fCost, and in the case of ties, that with the lowest hCost). Once found, it removes this node from the openSet and adds it to the closedSet. It is mentioned that this is very unoptimized, but it is one of the simplest ways of setting it up initially (they return to this for optimization in future tutorials).

Continuing to follow the psuedo code, they go through the list of neighbors for the currentNode and check to see if any are walkable and not already in the closedSet to determine which to further explore.

Here they create the distance calculating method that will serve as the foundation for finding the gCost and hCost. This method, named GetDistance, takes two nodes and returns the total distance between them in terms of the grid system. Just to reiterate, it returns an approximated and scaled integer distance value between two nodes. Orthogonal moves have a normalized distance of 1, where diagonal moves are then relatively the sqrt(2), which is approximately 1.4. These values are then multiplied by 10 to give their respective values of 10 and 14 for ease of use and readability.

If it is determined that the neighbor node should be evaluated, it calculates the gCost of that neighbor from the current node by adding the distance to the neighbor from the currentNode to the currentNode gCost. It then checks if this is lower than the neighbor node’s current gCost (so they found a cheaper route to the same node) or if neighbor is not in the openSet (which means it has never been evaluated, so has no gCost to compare). If these criteria are met, it sets the gCost of the neighbor to this determined value, and calculates the hCost using the new GetDistance method created between the neighbor node and the targetNode.

It finally sets that neighbor node’s parent as the currentNode, and checks if the neighbor was already in the openSet. If not, it adds this node to the openSet.

The RetracePath method was created, which determines the path of nodes to follow once the target has finally been reached. Starting with the endNode (target position), it cycles through each node’s parent by continually changing the checked node to the current node’s parent until it gets back to the startNode, and adds them to a list named path. Finally, it reverses the list so they are in the proper order matching the actual object’s traversal path (since doing it this way effectively gives you the list of nodes backwards, starting with the end).

Node

They add the gCost, hCost, and fCost as public ints here finally. The fCost is actually just a getter function that returns gCost + hCost. This is a nice setup that provides some extra encapsulation as fCost will never be anything else so it may as well only return that sum whenever it is called.

Later they also add ints gridX and gridY, which are references to their indices in the overall grid array. This helps locate them, as well as their neighbors, more easily in later code.

A field is created of the type Node named parent to hold a reference to a parent node. This serves as the link between nodes to give a path to follow once the final destination has been reached. As the lowest fCost nodes are found, they will create a chain of parent nodes which can be followed. This is done with the RetracePath method in Pathfinding.

AGrid

They added the GetNeighbors method here. It takes in a node, then returns a list of nodes that are its neighbors. It effectively checks the 8 potential areas around the node with simple for loops spanning -/+ 1 in the x and y axes relative to the given node. It skips the node itself by ignoring the check when x and y are both 0. It also makes sure any potential locations to check exist within the grid borders (so it does not look for nodes outside of the grid for nodes on the edges for example).

Sebastian Lague A* Tutorial Series – Node Grid – Pt. 02

digm520admin / / A*, AI, Programming, Tutorial, TutorialList, Unity
November 20, 2019

A* Tutorial Series

Pt. 02 – Node Grid

A* Pathfinding (E02: node grid)

Link – Tutorial

By: Sebastian Lague


Intro:

This started by creating the overall Node class to contain valuable information for each individual node, and the Grid class that would be dealing with the overall grid of all the nodes (I rename this to AGrid to avoid errors in Unity).

Node

For now, this simply holds a bool walkable, which represents whether this node contains an obstacle or not, and a Vector3 worldPosition, which contains data on its Unity real world position.

AGrid

This class has a couple parameters that influence the coverage and resolution of the overall A* system. The gridWorldSize represents the two dimensions covered by the entire grid (so 30, 30 will cover a 30 by 30 area in Unity units). The nodeRadius is half the dimension of a node square, which will be used to fill the entire grid. The lower the nodeRadius, the more nodes (so higher resolution, but more computing cost).

The intial setup is a lot of work that simply breaks down whatever the overall area being covered by the grid into int size chunks to use as indices to work with a 2D array containing all the nodes. The NodeFromWorldPoint method is also created, which is a nice method that takes in a Vector3 value and returns the node encompassing that point. I like the extra step of clamping the values here to reduce possible errors in the future.

Unity Feature Notes:

Clamp Example:

// Clamped to prevent values from going out of bounds (will never be less than 0 or greater than 1)
percentX = Mathf.Clamp01(percentX);
percentY = Mathf.Clamp01(percentY);

Mathf.Clamp01 clamps a value within the bounds of 0 and 1. This percent value should never be outside of those for the purposes of the grid anyway (they help determine basically what percentage away a node is on the x and y axes separately relative to the bottom left node). So in error cases, this will simply give a node that is at least on the border of the grid.

The CreateGrid method in the AGrid script uses a Physics.CheckSphere method to determine if a node is traversable or not. This simply creates a collision sphere of a determined radius that returns information on anything it collides with.

Gizmos:

They use the DrawWireCube Gizmos, which just lets you create a wire cube outline with defined dimensions. This is very nifty for conveying the general area covered by something visually in your editor.

Warning:

Unity had an issue with naming the one script “Grid”, as they already something named Grid built into the system. It gave me a warning that I would not be able to use components with this object. Just to make sure I did not run into any future issues, I renamed it “AGrid”.

digm520admin / / A*, AI, Pathfinding, Programming, Tutorial, TutorialList, Unity

Sebastian Lague A* Tutorial Series – Algorithm Explanation – Pt. 01

November 20, 2019

A* Tutorial Series

Pt. 01 – Algorithm Explanation

A* Pathfinding (E01: algorithm explanation)

Link – Tutorial

By: Sebastian Lague


Notes:

G cost = distance from starting node H cost (heuristic) = distance from the end node F cost = G cost + H cost

A* starts by creating a grid of an area. There is a starting node (initial position) and an end node (destination). Generally, you can move orthogonally (which is normalized as a distance of 1) or diagonally (which would then be a value of sqrt of 2, which is approx. 1.4). Just to make it look nicer and easier to read, it is standard to multiply these distances by 10 so that moving orthogonally has a value of 10, and diagonally has a value of 14.

The A* algorithm starts by generating the G cost and H cost of all 8 squares around the starting point (in a 2D example for ease of understanding). These are then used to calculate the F cost for each square. It starts by searching for the lowest F cost and then expanding the calculations to every square in contact with it (orthogonally and diagonally). Recalculations may be necessary if a certain path finds a way to reach the same square with a lower F cost. If multiple squares have the same F cost, it prioritizes the one with the lowest H cost (closest to the end node). And if there is still a tie, it basically can just pick one at random.

It is worth reiterating that the costs of a square can be updated through a single pathfinding event. This however only occurs, if the resulting F cost would be lower than what is already found in that square. This is actually very important as the search can lead to strange paths to certain squares giving them higher F costs than they should have when there is a much more direct way to reach that same square from the starting node.

Coding Approach

Psuedo Code (directly from tutorial):
OPEN //the set of nodes to be evaluated
CLOSED //the set of nodes already evaluated
add the start node to OPEN

loop
current = node in OPEN with the lowest f_cost
remove current from OPEN
add current to CLOSED

if current is the target node //path has been found
return

foreach neighbour of the current node
if neighbour is not traversable OR neighbour is in CLOSED
skip to the next neighbour

if new path to neighbour is shorter OR neighbour is not in OPEN
set f_cost of neighbour
set parent of neighbour to current
if neighbour is not in OPEN
add neighbour to OPEN

There are two lists of nodes: OPEN and CLOSED. The OPEN list are those nodes selected to be evaluated, and the CLOSED list are nodes that have already been evaluated. It starts by finding the node in the OPEN list with the lowest F cost. They then move this node from the OPEN list to the CLOSED list.

If that current node is the target node, it can be assumed the path has been determined so it can end right there. Otherwise, it checks each neighbour of the current node. If that neighbour is not traversable (an obstacle) or it is in the CLOSED list, it just skips to check the next neighbour.

Once it finds a neighbour to check, it checks that it is either not in the OPEN list (so this neighbour is a completely unchecked node since it is in no list since we also just checked to make sure it was not in the CLOSED list) or there is a new path to this neighbour that is shorter (which is done by calculating the current F cost of that neighbour, since it could be different now). If either of these are met it sets the calculated F cost as the actual F cost of this neighbour (since it is either lower or has never been calculated), and then sets the current node as a parent of this neighbour node. Finally, if neighbour was not in the OPEN list, it is added to the OPEN list.

Setting the current node as the parent of the neighbour in the last part of the psuedo code is helpful for keeping track of the full path. This gives some indication of where a node “came from”, so that when you reach the end you have some reference of which nodes to traverse.

UnityLearn – Beginner Programming – Finite State Machine – Pt. 02 – Finite State Machines

digm520admin / / AI, Programming, StateMachine, Tutorial, TutorialList, Unity, UnityLearn
Novemeber 18, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Finite State Machines

Building the Machine

This part of the tutorial has a lot more hands on parts, so I skip some of the sections for note purposes when there is not much substance to them other than following inputs.

A key in finite state machines is that an object can only ever be in exactly one state at a time. This helps ensure each state be completely self contained.

Elements of a Finite State Machine:
Context: maintains an instance of a concrete state as the current state
Abstract State: defines an interface which encapsulates behaviors common to all concrete states
Concrete State: implements behaviors specific to a particular state of context

To get started in the tutorial, they created a public abstract class PlayerBaseState which will be the abstract state for this example. PlayerController_FSM is the context. They note that while in this case all the abstract state methods take the PlayerController_FSM (the context) in as a parameter in this case, that does not necessarily have to be the case for the general FSM pattern.

Concrete States

It is noted that the context in a FSM needs to hold a reference to a concrete state as the current state. This is done in the example by creating a variable which holds that of the type that is our abstract state, which is PlayerBaseState in this case. They then create a method called TransitionToState which takes a PlayerBaseState in as a parameter. It then sets the currentState to that parameter state, and then calls the new state’s EnterState method (all states have this method as it is dictated by the abstract class they all implement). This determines what actions should be done immediately upon entering this new state.

Example:

public void TransitionToState(PlayerBaseState state)
{
currentState = state;
currentState.EnterState(this);
}

The tutorial also shows a way to take control of the context’s general Unity methods and pass the work on to the concrete states instead. This example did this with Update and OnCollisionEnter. The abstract state, and in turn, all of the concrete states, have their own Update and OnCollisionEnter method. The context, PlayerController_FSM, then simply calls currentState.Update(this) in its Update method, and currentState.OnCollisionEnter(this) in its OnCollisionEnter method, so that the current concrete state’s logic for these methods are used without flooding the context itself with any more code.

Since it is necessary that your context has some initial state, they do this by simply calling the TransitionToState method within the Start method and entering the IdleState. IdleState is the initial state for this case.

Beginning the Implementation

Important benefits seen using this system:
While working on the concrete classes themselves, we never needed to go back to the PlayerController_FSM class (the context) to modify any code there. The entire behvior is handled within the concrete states and is abstracted from the character controller (the context). Setting expressions was much easier as no checks are needed and this can just be set in the EnterState method of each concrete state.

It is already clear that this method removes a lot of boolean checks from the overall code, and helps organize the code by ensuring any logic about a state is contained within the class for that state itself (with less bleeding into the code of other states).

Continuing the Implementation

It is worth noting that PlayerController_FSM holds a reference to every concrete state except the spinning state. This was done because they actually have the jumping state create a new spinning state on transition each time it is invoked. They apparently do this so that the local field for rotation within the spinning state is reset to 0 each time it is called, but it seems like there would be other ways to do this that seem less wasteful (such as resetting it to 0 when exiting the state). I am also not sure if this is intended behavior, but the spin also immediately cancels upon contacting the ground (resetting the player rotation to 0) with this setup, where as in the previous behavioral setup the spin completed even if the player contacted the ground.

Module Conclusion

Benefits of FSM:

  • More modular
  • Easier to read and maintain
  • Less difficult to debug
  • More extensible

Cons of FSM:

  • Take time to setup initially
  • More moving parts
  • Potentially less performant

Just something very notable with this approach, it seems much harder for me to break than the naive implementation. If I spammed key presses (like pressing jump and duck a lot) with the naive approach, sometimes I could break the system and have the player stuck in the duck position or be ducking while jumping. I have not been able to break it at all with the full FSM setup, which makes sense since transition behaviors solely exist within the states themselves so these inputs cannot be jumbled in any way.

SUMMARY

Using state machine systems appear way easier to use and build on than the “naive” approach of basic boolean behaviors (with lots of if statements and boolean checks). Not only was I very excited about how much easier this appears to work as a scalable option, it also just worked better and more cleanly when it was all put together.

The other version had small bugs that would pop up if you spammed all the different action keys (such as getting stuck ducking or being ducked in a jump), which were possible just because the key presses would get recorded before reaching the bools or if statements that should be telling them that they are not proper options. These very separated states make that type of error impossible as it is only concerned with a single state at a time.

This type of system just seems much cleaner, more organized, and less error prone than what I have done before and I am very excited to try and build a system like this for my own project (for both players and enemy AI).

UnityLearn – Beginner Programming – Finite State Machine – Pt. 01 – Managing State

digm520admin / / AI, Programming, Tutorial, TutorialList, Unity, UnityLearn
Novemeber 15, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Managing State

Project Overview

This part of the tutorial has a lot more hands on parts, so I skip some of the sections for note purposes when there is not much substance to them other than following inputs.

The basics covered in this section are:
What is state and how to manage it
Finite State Machine pattern
Build your own finite state machine

Introduction

State: condition of something variable
State Examples: Game state, Player state, NPC State

Finite State Machine: abstract machine that can be in exactly one of a finite number of states at any given time

Parts of a Finite State Machine:
  • List of possible states
  • Conditions for transitioning between those states
  • State its in when initialized (initial state)

Naive Approach to Managing State

This naive approach focuses on boolean states and if staements. It uses a lot of if and else if statements in the Update method to determine what state the player is in and if/when/how they can switch to another state. Even with two states this becomes tedious and somewhat difficult to read. This example is just to emphasize the use of proper finite state machines.

Actions, Triggers, & Conditions

Look at your actions as a set of: actions, triggers, conditions.
Example for Arthur jumping:

  • Actions: Arthur jumps; jumping expression
  • Triggers: Spacebar is pressed
  • Conditions: Arthur is not jumping

Continuing to follow the naive state management approach, we see that everytime we add a new state it makes all snippets about other states more complex and harder to follow. This is very clear that this will become unmanagealbe with only a few states even.

Module Overview

The biggest issue with the naive approach is the interdependent logic of the various states. It makes each state exponentially harder to work with with every state that is added, so it is very limited on its scalability. This does not even come with a benefit to readability, as it also becomes difficult to read quickly.

SUMMARY

Using the naive approach (boolean fields and if/else statements) to manage state is only really useable for extremely simple cases. As soon as you reach 3 or 4 states with even small amounts of logic to manage them, this approach becomes very awkward and unwieldy. Fininte State Machines should hopefully open up a better way to manage more states with better scalability and allow for more complexity with better readability.

Programming A* in Unity

digm520admin / / A*, AI, C#, Programming, Tutorial, TutorialList, Unity
November 14, 2019

A* Programming

Unity

A* Pathfinding (E01: algorithm explanation)

Tutorial #1 – Link

By: Sebastian Lague


Unity – A Star Pathfinding Tutorial

Tutorial #2 – Link

By: Daniel


Unity3D – How to Code Astar A*

Tutorial #3 – Link

By: Coding With Unity


I have used A* before, but I would like to learn how to setup my own system using it so that I can make my own alterations to it. I would like to explore some of the AI methods and techniques I have discovered in my AI class and use that to alter a foundational pathfinding system built with A* to come up with some interesting ways to influence pathfinding in games. I would eventually like to have the AI “learn” from the player’s patterns in some way to influenece their overall “A* type” pathfinding to find different ways to approach or avoid the player.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 03 – The Observer Pattern

digm520admin / / Programming, Tutorial, TutorialList, Unity, UnityLearn
Novemeber 7, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

The Observer Pattern

The Observer Pattern

Observer Pattern: software design pattern in which an object, called the subject, maintains a list of dependents, called observers, and notifies them of any state change, usually by calling one of their methods

Observer Pattern Anatomy

Subject

  • collection of observers
  • method: AddObserver
  • method: RemoveObserver
  • method: NotifyObservers

Observer

  • method: Notify (what to do when notified)

An interface is a good way to ensure observers have the types of methods you need to exist when notified by the subject.

Implementing the Observer Pattern

This was an example of how to setup a basic observer pattern using the example project. First they created the interface for the observers, which was named IEndGameObserver. This simply held an empty method named Notify().

They then used the GameSceneController script as the subject for the observer pattern. To do so, they created a list of IEndGameObserver objects, created a method AddObserver which could add to that list, created a method RemoveObserver which could remove from that list, and finally a method called NotifyObservers that was a simple foreach loop that went through each IEndGameObserver in the list and called their Notify() method.

NotifyObservers then just needs to be called when the event or state is reached where the observers need to be informed that a change has occurred. Since this example was to inform objects of when the game ended, NotifyObservers was called within the GameSceneController script when the player ran out of lives.

Concrete Observers

Concrete Observers: just objects that implement the observer interface

This example showed that with this setup, either the observer or the subject can be used to add observers to the subject’s collection of observers. The HUDController already had a reference to the GameSceneController (subject) so it made sense to just have it add itself to the observer collection through that reference.

While the EnemyController and PowerupController do not have reference to the GameSceneController, the GameSceneController has references to them created on instantiating them. These could then be used with the GameSceneController to add them to the observer collection upon instantiation.

***Could possibly use this observer pattern in my thesis project to easily collect all of the various Create classes into the Scenario classes (and potentially again to collect the Scenario classes into the SystemManager).

Removing Observers

To avoid nullreferenceexceptions, you must ensure that observers that are destroyed are also removed from the subject’s collection of observers.

To apply this to the example, we added a method called RemoveAndDestroy to both the PowerupController and the EnemyController class which both removed it from the observer collection and destroyed it. This method was exactly the same for both, so this could indicate that it should be added to the interface itself to keep it consistent amongst all observers using this interface.

The Observer Pattern and C# Events

Example Problem with C# Events:
The ProjectileController has an event that occurs when it reaches the bounds of the screen. The PlayerController subscribes to this event by adding one of its methods to this event. There are some cases where the projectile exists while the player is destroyed, so when the projectile goes out of bounds (and calls its event), it tries to invoke a method from the destroyed PlayerController class, which gives an error.

Similar to the observer pattern where we want to remove observers from the collection when they are destroyed to prevent errors, we want to unsubscribe classes from events when they are destroyed. This ensures that they are revmoved from the events invocation list so that they do not try to call methods of destroyed objects which will create errors.

The Publisher Subscriber Pattern

Publisher Subscriber Pattern: similar to Observer Pattern, but adds another entity, the broker, which is in charge of keeping track of and notifying subscribers.

Observer Pattern has a single subject, but publisher subscriber pattern can have any number of publishers. Each of these publishers has a reference to the broker to notify it when a noteworthy happening occurs.

Example:
They created a class called EventBroker that just contained a public static event ProjectileOutOfBounds and a public static method named CallProjectileOutOfBounds (which just checked that the event wasn’t empty and then called that event). The PlayerController subscribes to this event by adding its EnableProjectile method to it on Start (and removes it OnDisable), both of which are very direct since everything is public static in EventBroker. Finally, the ProjectileController invokes the event CallProjectileOutOfBounds when the projectile leaves the screen, which now invokes the PlayerController’s EnableProjectile method.

This setup allows the ProjectileController to effectively communicate with the PlayerController without references to each other in anyway by going through the EventBroker.

SUMMARY

Using delegates, events, and actions can provide a clean and effective way to communicate important happenings throughout many objects and have them act accordingly. The Observer Pattern uses a single subject and multiple observers which receive information from the subject when to do something. The Publisher Subscriber system is similar, but adds a middle man entity of a broker which communicates the information between the publisher and subscribers without the publishers or subscribers needing any direct reference between each other.

HFFWS Thesis Project – Theory for General Generation System Architecture

digm520admin / / HFFWS, Programming, Thesis, Unity
November 6, 2019

HFFWS Puzzle Generation System

General System Architecture

General Notes

Pulley Varieties

I wanted to start with sketching out the general structure of a single puzzle type to help me get a better idea of what a useful general structure might look like for the overall puzzle generating system I want to make.

  • Hook on an end to latch onto other objects
  • Object to move can be used as a platform
  • Open heavy door
  • Focus on rotation of wheel
  • Build a pulley
  • (Rope puzzle) Move two rope conjoined objects somewhere to accomplish a goal

Breakdown of what I can currently alter/generate in rope/pulley tool

  • Objects (at ends of rope)
  • Objects (for wheels)
  • Length (of rope)
  • Position (of rope)
  • Position(s) (of wheel(s))

I then quickly sketched out what I could change with the current controllable parameters to match the various puzzle variations (I only did the first three for now just to work it into testing quicker).

Hook on end

  • Objects at ends
    • Hook
    • Grabbing Mass (i.e. small sphere)
  • Outside objects
    • Objects that need pulled by hook

Objects attached can be used as platforms

  • Objects at ends
    • Platform type objects
  • Outside objects
    • Mass objects to influence pulley movement

Open heavy door

  • Objects at ends
    • Heavy Door
  • Outside objects
    • Mass objects to influence pulley movement

Architecture Design (1st Pass)

The overall flow of information is:
GenerationManager -> ScenarioManager -> “Create” type classes

GenerationManager

Passes down highest level information to ScenarioManager. This will include puzzle type, variation type within that puzzle type, and any other high level information such as overall positioning or how many scenarios in total to generate.

ScenarioManager

Will take that information and use it to determine which “Create” type classes will need to be used (or have the option of being used), how many times to use each, and what other information needs to be passed on to them (the “Create” type classes) to properly build out the desired scenario.

“Create” type Class

Use the information passed down to them from the ScenarioManager to create objects that satisfy the needs of the desired scenario. Within these bounds, in then adds variation to what it creates to vary its creations while still meeting the requirements given by the ScenarioManager

All the “Create” type classes will need an interface or inheritance of some kind to make them all similar types of objects to make grouping them and using them a bit easier.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 02 – Working with Multiple Subscriptions

digm520admin / / Programming, Tutorial, TutorialList, Unity, UnityLearn
Novemeber 5, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Working with Multiple Subscriptions

Creating a Parameterized Event

Parameterized Event: an event that takes in at least one parameter

Points of Reference

A subscriber must have a reference to the publisher (class raising the event) in order to be able to subscribe to that event.

The general pattern for making delegates and events from how they have done it so far is that you create the overall delegate type that you will want the events to use outside of a class definition and public (so that all classes that want to make an event of this delegate type can use this single delegate type as a reference). The events themselves are then within the class definition, and use that newly created delegate type.

Example Breakdown

I broke down the tutorial example in order to better understand it.

The parameterized event is created in the EnemyController script. This is done by creating a delegate called EnemyDestroyedHandler outside of the class definition in the EnemyController script (this delegate is of type void and takes an int parameter, so any event using this must do follow the same signature). They then created a public event of type EnemyDestroyedHandler named EnemyDestroyed within the class definition of EnemyController.

Since subscribers need references to the publishers in order to subscribe to their events, they go to the GameSceneController class to subscribe to the EnemyDestroyed event since it already has references to the EnemyController class in its spawning methods. Here they add a method (Enemy_EnemyDestroyed, the default name) from within the GameSceneController class to the EnemyDestroyed event. It matches the signature (return type void, with a single paramter of type int). Now, when the EnemyDestroyed event is called in the EnemyController script, the parameter input given there is the same parameter input used for all methods subscribed to that event. So in EnemyController, EnemyDestroyed(pointValue) ends up calling Enemy_EnemyDestroyed(pointValue) from within the GameSceneController class.

The GameSceneController also creates its own event of type EnemyDestroyedHandler named ScoreUpdatedOnKill. This uses the same delegate type created in the EnemyController script, so they just need to create the event here in the GameSceneController script. It should be noted that this can be done simply because they are using the same signature delegate type here, it does not necessarily even have to do with the fact that its a similar game related event. This event is then called within the Enemy_EnemyDestroyed method, which is subscribed to the EnemyController EnemyDestroyed event already. So this creates a chain of method calls from a single event.

This event, ScoreUpdatedOnKill, is used to update the HUD score value. To accomplish this, we need the HUDController class to subscribe to the event. So they go to the HUDController and create a reference to the GameSceneController class (since subscribers must have a reference to the publisher). Since the GameSceneController is an object that will persist throughout the entirety of the game, they simply create the reference to it and subscribe to the event within the GameSceneController within the Start method of the HUDController.

ScoreUpdatedOnKill, the GameSceneController event, is given the method GameSceneController_ScoreUpdatedOnKill from the HUDController. This method simply calls the method UpdateScore which changes the text to match the new score.

It is important to note that since this is a chain of events, as opposed to multiple subscribers subscribing to a single event, the value passed throughout the chain can change. The EnemyDestroyed event in EnemyController uses the int pointValue, so that the GameSceneController method Enemy_EnemyDestroyed subscribed to it adds that value to the totalPoints, which is held within the GameSceneController. The GameSceneController then passes totalPoints (not pointValue) into its event, ScoreUpdatedOnKill, which is the event the HUDController subscribes to in order to update the score. This makes sure it displays the new total score as opposed to just the value for the last score gained.

I wanted to make this difference clear since I also noted that multiple subscribers to a single parameterized event will all use the same parameters. This chain of events simply use the same delegate type because they just happen to want to use the same signature (return type void with a single int parameter) and nothing more.

Multiple Subscribers

You can have several classes subscribe to the same event.

What was weird for this example was that they just wanted to reenable the firing mechanism for the player when an enemy was destroyed, using the same ScoreUpdatedOnKill event. This event requires a method of return type void with an int parameter. So they made a method satisfying this, but it doesn’t use the int parameter at all. It simply calls another method that is just void return type with no input parameter, EnableProjectile (which lets the player fire again). Since you can simply subscribe to an event with a method that just calls another method, your method actually doing work does not particularly have to match the signature of the original delegate type.

Conclusion

Actions (C#): types in the System namespace that allow you to encapsulate methods without explicitly defining a delegate

Actions are inherently delegate types so they keep you from having to separately define a delegate when creating an event. They mention that they will just use actions from here on for the course, so I assume this is generally better and cleaner practice this way. This does make more sense with my recent understanding that the delegate signature type is not particularly that crucial for the actual outcome when dealing with this subscriber and publisher pattern.

SUMMARY

Subscribers need a reference to their publisher in order to use their events, so look for places where you are already creating this reference for improved efficiency. An event can have multiple subscribers, so calling that event can call multiple methods from multiple objects. You can also create chains of actions that call methods while starting other events. Actions are a more compact and cleaner way to create an event without the need for separately creating the delegate.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 01 – Handling Events

digm520admin / / Programming, Tutorial, TutorialList, Unity, UnityLearn
Novemeber 4, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Handling Events

The Demo Project

This section focused on handling inter-object communications. They covered direct object calls, tight coupling, and loose coupling. This topic was covered using mostly delegates and events.

Events: something that happens within the context of one object to be communicated to other

The first objective of the tutorial was to restric the rate of fire of the player ship so that it could only have one projectile on the screen at any time. They could not fire again until that projectile was destroyed (which in this case, only occurred once it left the screen).

Direct Object Calls

Direct Object Calls: directly make a call from within one object to a method in another object (usually through public methods)

Example: The ship needed to be able to fire again when the projectile reached the end of the screen. The projectile used a reference to the PlayerController to call a method within it when the projectile reached the end of the screen to reenable the firing mechanism.

Costs: This forces you to expose a lot of methods within objects so that others may access them.

Tight Coupling

Tight Coupling: making objects dependent on one another; can be done by having one object call a method found in another object

Costs:

  • Difficult to maintain and debug
  • Not easily scalable
  • Impedes collaboration (like Git or Collab)
  • Complicates Unit Testing

Delegates and Events

This section looks to use delegates and events to get around the issues found with direct object calls and tight coupling. These allow for loose coupling.

Important Notes
  • One way to think of delegates is that they are method variables.
  • All events have an underlying delegate type.

Example: The ProjectileController script created a public delegate and public event. It then called that event within its code somewhere (which would then execute any methods assigned to that event). The PlayerController assigned one of its methods to that public event when instantiating the projectile. The ProjectileController could then effectively call that PlayerController method by calling the event within it.

SUMMARY

Delegates and events can provide a nice way to create loose coupling, which can lead to better and easier to maintain ways to allow your objects to communicate between one another. Be careful with direct object calls and tight coupling as they can reduce encapsulation and lead to tricky debugging problems down the road.