Category: UnityLearn

Novemeber 21, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Overview and Character Controller

Navigation and Animation Review

This part of the tutorial just gets you familiar with the NavMesh setup they have and the animator they are using on the player character. Some of the items are a bit off since they are using an older Unity version (2017), like where the Navigation tab is located (it is now under Window -> AI).

The player character animator has a blend tree that holds a speed parameter. This parameter appears to determine how much to blend between an idle animation and a running animation, as well as how fast the animation plays.

Controlling Motion with C# and Unity Events

This tutorial portion started with adding a NavMesh Agent component to the Hero character to have it interact with the baked NavMesh in the scene.

The next step was to edit the MouseManager class to actually move the character according to its NavMesh Agent and the created NavMesh. This would require a reference to the NavMesh Agent component. They did not want to use a public field (as this creates a dependancy that can lead to issues down the road), so they turned to making an event.

They needed to create this event, which they did so as a new class within the MouseManager script, but outside of the class. This was done in the following way:

[System.Serializable]
public class EventVector3 : UnityEvent { }

The base class UnityEvent lets it send vector3 information through an event.
They then created a public field of the type EventVector3 named OnClickEnvironment. This was then used to do the following:

if (Input.GetMouseButtonDown(0))
{
OnClickEnvironment.Invoke(hit.point);
}

The public field created a box within the inspector similar to UI events in Unity. You could drag an object in as a reference, and select a component and method to call when that event happened. In this case they used the Hero object, and called the NavMeshAgent.destination method.

Synchronizing Animation with Motion

They start by simply referencing the NavMeshAgent speed and passing that value into the animator’s speed parameter. They then begin to alter the NavMeshAgent component’s properties to fine tune the movement to feel better to play with. They significantly increased the Speed, Angular Speed, and Acceleration, and turned off Auto Braking. This felt much better, but led to an issue where the player would run back and forth near their destination.

The issue is caused by turning off Auto Braking and not having a Stopping Distance. I assume since the character has trouble “perfectly” reaching the value of its given destination, the Stopping Distance of 0 means it will keep trying to get there even though it cannot.

Setting the Stopping Distance to 0.5 fixed this issue. This allows the agent to stop moving once it is within 0.5 units of the given destination. There was still a strange issue where the character would move slowly around stairs, but they said they would cover this issue.

Handling the Passageway

This portion deals with adding code to allow the character to traverse the special passageway section of the level. The passageways have unique colliders to inform the cursor that a different action should take place when they are clicked. These colliders also have direction, which will be used to determine which way to move the character through the hallway.

They then go back to the MouseManager to show where the cursor is detecting the unique collider (currently just to swap the mouse icon with a new icon). This is where they add extra logic that if door is true (a doorway has been clicked) that they want to grab that object’s transform and move a fixed distance (10 in this case) in that object’s z-direction. This is why the collider’s orientation is important.

This setup seems very bad to me. This only works for passageways that are all exactly the same distance since the value is hard coded in. You can still click on areas between the passageway entrances, so the character just gets awkwardly stuck in the middle with the camera pressed up against a wall. There is no limitation when taking a passageway, so the player can click again midpassage and alter their character trajectory which can be weird or buggy.

I think I would prefer a system that somehow links the two passageway entrances so that no matter where they are, when the player clicks one they will enter it and come out of the other one (use their transform with some offset). Player input should also be limited somehow during the passage because there is no reason to do anything else within the passage, this only allows for more errors.

Note:

The MouseManager uses a lot of if/else conditional statements, and from the previous lessons, I think it could possibly benefit from having a small state machine setup. While I think it is just on the edge of being ok in its current setup, the Update method for the MouseManager is already looking a bit bloated and any more complexity may start to cause issues.

SUMMARY

I think this tutorial was mostly focused on just getting you used to finding and using some different features of Unity, such as NavMesh and the Animator. Nothing here seemed to be that deep or well done, so it felt very introductory. Getting a refresher on NavMesh agents was definitely useful at least, and working with animation never hurts.

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.