All lessons this week are strictly educational, so there is no deliverable based on these, but I strongly recommend trying to follow along as these systems are very useful for developing your own games.

Part 1: Level Prototyping (with ProBuilder)

ProBuilder is a very useful plugin for Unity, extending the editor by offering simple (but significantly improved) modeling and alignment tools.  Once its own standalone product in the Asset Store, Unity has purchased it and now offers it free in the package manager.

ProBuilder is helpful if you need to quickly prototype some objects, rough out a level design, or generate a quick mesh for collisions.  This provides enhanced mesh generation, and access down to the vertex level, as well as a quick way to create and adjust UV mapping for objects.   

Another plugin from the same creators, PolyBrush, lets you sculpt, shape, and paint your meshes.  It is also available for free in the Package Manager.

Installing ProBuilder

• Open the “Package Manager”, accessed by clicking on Window > Package Manager
• Select the “Unity Registry” option to see all available packages
• Scroll down until you see the “ProBuilder” entry, and then click “Install”  

ProBuilder Interface

To start ProBuilder, navigate the top menu to Tools > ProBuilder > ProBuilder Window. 

This will launch a window with either Text or Icon buttons.  You can switch between modes by right-clicking a blank area in the window and selecting the other menu type.

Notice that when you launch ProBuilder, you will also see a small icon menu in your Scene window.  This indicates the selection type when interacting with a ProBuilder object.

These are, from left to right:

• OBJECT Selection
• VERTEX Selection
• EDGE Selection
• FACE Selection

The ProBuilder Button menu will change depending on the selection type that is active.

By using these selectors, you can grab just a part of an object and use the various transform tools to deform them into the shapes that you want. The ProBuilder menu contains a number of tools that can split, offset, subdivide, and transform these. Additionally, you can use the “shift” key to generate new geometry, including Shift-Move (face) to Extrude and Shift-Scale (face) to create an inset poly.

Additionally, you can use Vertex Color to set the color tint of surfaces. You can also set materials, and make adjustments to the UVW mapping (the way that texture images are applied to the surfaces.

ProBuilder can also Export a model into common 3D formats, including OBJ and STL. (I recommend using .obj as that tends to be the most common amongst other modeling applications).

ADVICE: ProBuilder is great for quickly generating or editing assets, but is not recommended to be used throughout the entire process. The procedural generation of the mesh at runtime makes it susceptible to small errors, at which point your work may be lost without an option for recovery. Once you are happy with an asset, it is highly recommended that you run the EXPORT process to convert it into a mesh file in your Asset folder.

Resources

• ProBuilder Resources (Unity)
• ProBuilder Documentation (Unity)

Part 2: The Character Controller

In this section, we cover the how to implement Unity’s character controller as a FPS controller. Unity does have a premade FPS-style player object available in their Standard Assets, however it requires that you upgrade your project to the newer Input system. Since our lessons have focused on the legacy input system, we go about implementing our own version using the CharacterController component.

The first step is to create an object that will be our Player, and for this I like to use a Capsule primitive, as it roughly translates to a human-sized object of 2 units tall and 1 unit in diameter. I disable the Capsule Collider, and instead add the CharacterController component from the list of Physics components.

The CharacterController also uses a capsule-shaped collider, however this particular collider behaves differently than others. First, it does not rotate, so we don’t have to worry about tipping over. We will not be using a Rigidbody component to move this, rather we will write a different script that will move (or attempt to move) the collider, much in the same way that we commanded our 2D collider to “move” in each update. Next, this controller does not return Collision events, instead it has its own collision method that is thrown when it contacts a collider.

You may notice that the controller has some unique settings, such as Step Offset and Slope Limit. These are settings that give the controller information about what is considered “traversable” (meaning that we can travel on it). A slope climb above this range (expressed in degrees) or a vertical step above the offset value (in units) will prevent the character from making that movement.

We move the CharacterController with one of two commands – Move( ) and SimpleMove( ). SimpleMove allows us to move only in the X & Z planes (and ignores Y data from the Vector3) and it automatically applies gravity, so this method is best for games where jumping is not an option. Since we want the ability to jump, we are going to use the Move( ) command instead. In either case, you should only make one call to Move or SimpleMove per frame, due to the way that Unity processes these.

To make our character move, we are going to create a new script that I call PlayerFPS, and use the sample code from the CharacterController.Move( ) page. By running this, we see that our player is movement is not quite what we might expect. Our character movement is restricted to the two axis, and there is a “turning” that does not affect what way we move, even though we turn partway. We are going to have to make some edits.

public class Example : MonoBehaviour
{
    private CharacterController controller;
    private Vector3 playerVelocity;
    private bool groundedPlayer;
    private float playerSpeed = 2.0f;
    private float jumpHeight = 1.0f;
    private float gravityValue = -9.81f;

    private void Start()
    {
        controller = gameObject.AddComponent<CharacterController>();
    }

    void Update()
    {
        groundedPlayer = controller.isGrounded;
        if (groundedPlayer && playerVelocity.y < 0)
        {
            playerVelocity.y = 0f;
        }

        Vector3 move = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
        controller.Move(move * Time.deltaTime * playerSpeed);

        if (move != Vector3.zero)
        {
            gameObject.transform.forward = move;
        }

        // Changes the height position of the player..
        if (Input.GetButtonDown("Jump") && groundedPlayer)
        {
            playerVelocity.y += Mathf.Sqrt(jumpHeight * -3.0f * gravityValue);
        }

        playerVelocity.y += gravityValue * Time.deltaTime;
        controller.Move(playerVelocity * Time.deltaTime);
    }
}

In this example version, the Update( ) function does the following:

1. Gets the value of controller.isGrounded. This returns a boolean indicating whether or not the most recent move caused the controller to intersect with a collider underneath it.
2. If isGrounded is true, it sets the y-value of the “playerVelocity” variable to 0. This is because the controller is considered “on the ground” and so is “resetting” the effect of gravity. PlayerVelocity is the vector representation of the speed with which a player is moving downward, to replicate gravity.
3. Next a “move” directional vector is created using the horizontal and vertical axis, and the Move( ) command is called with that vector multiplied by speed and Time.deltaTime to indicate how far it should move in this frame.
4. The next part rotates the game object to face the movement direction. This is not necessary for our purposes and we will comment this out of our version.
5. Now the script checks the “jump” input button. If true, and if the player is grounded, it will apply a positive y force to the playervelocity variable.
6. Finally, the player velocity adds the gravityvelocity (-9.81) multiplied by Time.deltaTime to create the effects of gravity, and again issues the Move( ) command. Yes, this goes against Unity’s own advice about not calling Move( ) twice in one frame, but it works here because one call handles X-Z movement, and one handles Y movement only.

In the accompanying video, I outline these changes:

• First, I remove the “turning” function from step 4.
• I set a camera as the child of the player object (and make this our primary camera for game view)
• Next I create a MouseLook function to control our player object. Using Input.GetAxis(“Mouse X”) I can translate horizontal mouse movement into player rotation around the y-axis (or up-axis).
• Now that our player body is being rotated, I redefine our PlayseFPS movement command to use the Horizontal and Vertical input axes as scalar values to apply towards the “forward” and “right” vectors of my player transform. This will return the world vectors of our local directions. I pass that value into the Move command and this allows us to move and strafe in a classic FPS style.
• Next I update MouseLook to rotate the camera up and down in response to the Mouse Y movement, implementing a Clamp to make sure we don’t rotate too far.

One key difference in using the CharacterController is that we are not using a standard collider. If we attempt to have our object run into objects with Rigidbodies, we will simply stop as though they are a solid wall. Instead, we must use OnCharacterColliderHit( ) that will inform us that a collision has occurred. Using the sample code from Unity’s site, we can see that we find the rigidbodies that we have hit, and use that to push the object.

public class Example : MonoBehaviour
{
    // this script pushes all rigidbodies that the character touches
    float pushPower = 2.0f;
    void OnControllerColliderHit(ControllerColliderHit hit)
    {
        Rigidbody body = hit.collider.attachedRigidbody;

        // no rigidbody
        if (body == null || body.isKinematic)
        {
            return;
        }

        // We dont want to push objects below us
        if (hit.moveDirection.y < -0.3)
        {
            return;
        }

        // Calculate push direction from move direction,
        // we only push objects to the sides never up and down
        Vector3 pushDir = new Vector3(hit.moveDirection.x, 0, hit.moveDirection.z);

        // If you know how fast your character is trying to move,
        // then you can also multiply the push velocity by that.

        // Apply the push
        body.velocity = pushDir * pushPower;
    }
}

Part 3: Physics

ForceMode Types

When we first started using Rigidbody Physics way back in the days of Pong (or BingoBangoBongo, as we called it), we set our ball in motion with a push that we created using AddForce( ). We passed a rather large force vector to make such a small and light object move at the speed we anticipated. This is due to the methods which Unity uses to apply forces to an object, known as the ForceMode.

There are four types of ForceMode:

• Force
• Acceleration
• Impulse
• VelocityChange

ForceMode.Force (default)

The default mode, ForceMode.Force is designed to apply a force over time to an object. It takes the mass of the object into consideration, so it will take more force to move heavier objects. It is designed to be used in FixedUpdate( ), as it will calculate the force to apply across that fixed time. The unit of force is calculated as:

(mass * distance) / (time^2)

This explains why our force needed to be so high to push a 1 kg object around the field of play. Our game provided one super quick burst, while this method is designed to be called repeatedly over time. A good use case would be a “thruster” that is called during every fixed update command.

ForceMode.Acceleration

Similar to ForceMode.Force, a force calculated over the time of FixedUpdate( ), except the force is applied equally to objects without regard to mass. Useful for purposes such as gravity effects, or driving games where the mass of the vehicle does not matter. The unit of force is applied as:

distance / (time^2)

ForceMode.Impulse

This mode takes the application of time out of the equation and delivers the force in one single burst, while taking mass into consideration. This mode is best for explosions, with an instant release of energy, but larger objects will affected less by it. The unit of force here is expressed as:

(mass * distance) / time

ForceMode.VelocityChange

Similar to impulse, but mass no longer has an effect. This mode instantly alters the velocity of the affected object by the value applied. (Remember, velocity is expressed as units per 1s). The “force” unit here is expressed as:

distance / time

For our experiment, we created a ball prefab with the following script. We set up two balls side by side, one with a weight of “1” and the other a weight of “50”. We created a similar pairing for each ForceMode, and set the applied force value to be equal across all eight balls.

ForceMode.Force required the most effort, rapidly clicking the mouse to barely move the heavy ball, while making some progress getting the light ball up the hill. ForceMode.Acceleration made things a little easier, as the heavy and light ball responded equally to each click. ForceMode.Impulse had a much greater effect, moving the heavy ball a greater distance than Acceleration had, and launching the light ball off of the board. ForceMode.VelocityChange launched both light and heavy balls far into the distance.

Raycasting

Detail Here

Overlay Sphere

Part 4: The Navmesh

While it is fun to wander around blowing things up, I created this level for something more. I want to create enemy objects that have some intelligence and can pursue me through the level. In order to do this, I created a prefab variant of the Barrel that I named “AngryBarrel”. The Angry Barrel is recognizable by it’s greenish hue, it’s white cube on top to help indicate forward direction, and it’s ever present bloodlust.

In order to make this object “intelligent”, or at least smart enough to figure out how to navigate my level, I need to define the areas that it is capable of travelling. This involves generating a surface shape that is comprised of all of the valid positions that one of the intelligent agents could occupy, which we call a Navmesh.

To create a NavMesh, you must first open the Navigation window, which can be reached by going to Window > AI > Navigation. This will open up another panel usually in the same area as the Inspector.

In order to create a Navmesh, you must tell the system which objects to include, and what the rules are about what is and is not accessible terrain. With the Object tab active, I selected all of the mesh objects that I wished to be part of my navigable layer, and checked the Navigation Static property, which indicates that this is an element to be included in the baking process. (You can include any object with either a Mesh Renderer or Terrain component)

Next, I set the conditions for the Agent Size that the bake should consider. This will analyze your navigation objects, and generate a simplified mesh that outlines the valid locations where an agent with these dimensions would fit. Finally I hit the Bake button, and soon I have my navmesh.

The “slope” property defines the maximum sloped angle to be considered traversable. The “step height” indicates how many units high the agent can “step up”. Thanks to the step settings, I was able to create a somewhat safe zone where the enemy cannot follow me up a slope, but must instead go around to use the stairs.

Next we add a Navmesh Agent component to our enemy objects, and then a small script to tell that Agent component where to go. If we feed the agent a position, it will automatically move at the designated speed to to that point considering the shortest path and moving around obstacles and other agents.

PlayerFPS.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class PlayerFPS : MonoBehaviour
{
    private CharacterController controller;
    private Vector3 playerVelocity;
    public bool groundedPlayer;
    public float playerSpeed = 2.0f;
    private float jumpHeight = 1.0f;
    private float gravityValue = -9.81f;

    public float pushPower = 2.0f;

    private void Start()
    {
        // controller = gameObject.AddComponent<CharacterController>();
        controller = gameObject.GetComponent<CharacterController>();
    }

    void Update()
    {
        // checking for the ground, and stopping our fall if grounded
        groundedPlayer = controller.isGrounded;
        if (groundedPlayer && playerVelocity.y < 0)
        {
            playerVelocity.y = 0f;
        }

        // moving the character on XZ
        // Vector3 move = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));

        float x = Input.GetAxis("Horizontal");
        float z = Input.GetAxis("Vertical");

        Vector3 move = (transform.right * x) + (transform.forward * z);
        
        
        controller.Move(move * Time.deltaTime * playerSpeed);

        /* unnecessary
        if (move != Vector3.zero)
        {
            gameObject.transform.forward = move;
        }
        */

        // application of jumping
        if (Input.GetButtonDown("Jump") && groundedPlayer)
        {
            playerVelocity.y += Mathf.Sqrt(jumpHeight * -3.0f * gravityValue);
        }
        // application of gravity
        playerVelocity.y += gravityValue * Time.deltaTime;
        controller.Move(playerVelocity * Time.deltaTime);
    }

    // this script pushes all rigidbodies that the character touches
    
    void OnControllerColliderHit(ControllerColliderHit hit)
    {
        Rigidbody body = hit.collider.attachedRigidbody;

        // no rigidbody
        if (body == null || body.isKinematic)
        {
            return;
        }

        // We dont want to push objects below us
        if (hit.moveDirection.y < -0.3)
        {
            return;
        }

        // Calculate push direction from move direction,
        // we only push objects to the sides never up and down
        Vector3 pushDir = new Vector3(hit.moveDirection.x, 0, hit.moveDirection.z);

        // If you know how fast your character is trying to move,
        // then you can also multiply the push velocity by that.

        // Apply the push
        body.velocity = pushDir * pushPower;
    }

}

MouseLook.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class mouseLook : MonoBehaviour
{
    public Transform playerBody;
    public float mouseSpeed = 100.0f;

    public float tiltRotation = 0.0f;

    // Start is called before the first frame update
    void Start()
    {
        Cursor.lockState = CursorLockMode.Locked;
    }

    // Update is called once per frame
    void Update()
    {
        float mouseX = Input.GetAxis("Mouse X");
        float mouseY = Input.GetAxis("Mouse Y");

        playerBody.Rotate(Vector3.up * (mouseX * mouseSpeed * Time.deltaTime));

        // tilt rotation
        tiltRotation -= mouseY * mouseSpeed * Time.deltaTime;
        // clamp
        tiltRotation = Mathf.Clamp(tiltRotation, -90.0f, 90.0f);
        // rotate the camera
        transform.localRotation = Quaternion.Euler(tiltRotation, 0, 0);

        // visualize the gaze direction
        Debug.DrawRay(transform.position, (transform.forward * 5.0f), Color.cyan);
    }
}

BarrelScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class BarrelScript : MonoBehaviour
{
    public GameObject smokePrefab;
    public GameObject explosionPrefab;
    
    
    public float forceRadius;
    public float forceApplied;
    public ForceMode forceMode;

    private bool _isLive = true;

    public void BarrelImpact()
    {
        // barrel has been hit, make it explode
        if (_isLive) { StartCoroutine(BarrelBurning());}
    }

    private void BarrelExplode()
    {
        _isLive = false;

        // make the barrel blow up
        Instantiate(explosionPrefab, transform.position, Quaternion.identity);

        Collider[] hitColliders = Physics.OverlapSphere(transform.position, forceRadius);

        foreach(Collider collider in hitColliders)
        {
           
            BarrelScript thisBarrel = collider.gameObject.GetComponent<BarrelScript>();
            if (thisBarrel) { thisBarrel.BarrelImpact(); }

            Rigidbody rb = collider.gameObject.GetComponent<Rigidbody>();
            if (rb)
            {
                rb.AddExplosionForce(forceApplied, transform.position, forceRadius, 10.0f, forceMode);
            }


        }


        Destroy(this.gameObject);
    }

    private IEnumerator BarrelBurning()
    {
        // start the smoke
        Instantiate(smokePrefab, transform.position, Quaternion.Euler(new Vector3(-90, 0,0)), transform);

        // wait for the fuse
        yield return new WaitForSeconds(2.0f);

        // time to die
        BarrelExplode();
    }

}

RaycastScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class RaycastScript : MonoBehaviour
{
    private AudioSource audio;
    public AudioClip gunshotSound;

    private void Start()
    {
        audio = GetComponent<AudioSource>();
    }

    void Update()
    {
        if (Input.GetMouseButtonDown(0))
        {
            // make the gun noise
            audio.PlayOneShot(gunshotSound);

            // check for a valid shot
            Transform cameraTransform = Camera.main.transform; // kind of a singleton

            // build my ray
            Ray ray = new Ray(cameraTransform.position, cameraTransform.forward); // return pos-z axis ray
            RaycastHit hit;

            if (Physics.Raycast(ray, out hit))
            {
                if (hit.transform.tag == "Barrel")
                {
                    // tell the barrel to explode
                    BarrelScript barrelScript = hit.transform.GetComponent<BarrelScript>();

                    // verify that I have a component
                    if (barrelScript)
                    {
                        barrelScript.BarrelImpact();
                    }
                }
            }

        }

        
    }


}

EnemyScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.AI;

public class EnemyScript : MonoBehaviour
{
    private NavMeshAgent agent;

    public Transform player;

    // Start is called before the first frame update
    void Start()
    {
        agent = GetComponent<NavMeshAgent>();
        StartCoroutine(UpdateTarget());
    }

    // Update is called once per frame
    void Update()
    {
        
    }

    private IEnumerator UpdateTarget()
    {
        while(true) { 
            bool foundRoute = agent.SetDestination(player.position);
            Debug.Log("Destination = " + foundRoute);

            yield return new WaitForSeconds(2.0f);
        }
    }

}

Part 1: Simplifying our Controller

One aspect of our initial controller continues to bother me, and that is the Ground Transform object that we ended up using. On the one hand, it is convenient because when we flip our character, that child object also inherits that flip. On the other hand, we have to select the object that is NOT our controller in order to adjust the transform position.

In the first part of today’s lesson, we rewrite aspects of the SideScrollerController that handle the ground-check position. Along the way we encountered some issues, because Vector3 math can be selective at times. Our process was to replace reference to that GroundCheck child object with a simple offset value (recorded as a Vector2) that we would add to the transform of our character object.

This created issues when we attempted to add a Vector2 to a Vector3, but this was resolved by simply converting the Vector2 into a Vector3 by declaration. Then we added that offset to the object position. Also, to account for conditions where we face opposite directions, we multiply the Vector2 value by transform.localScale (which is how we are flipping our character)

void FixedUpdate()
{
    Vector3 groundCheckOffset = groundCheckPosition * transform.localScale;

    // Check if player is grounded
    Collider2D[] colliders = Physics2D.OverlapCircleAll(transform.position + groundCheckOffset, colliderRadius, groundLayer);

    // check for a grounding collider
    isGrounded = colliders.Length > 0 ? true : false;

}

There was also an unfortunate bug introduced by the “conveyer” aspects that we added last time. This prevented us from initiating movement from a standstill. Removing the “conveyer” components of our move commands resolved this issue.

Part 2: Other Enemy Death Options

Next we adjusted our enemy object to die differently. We created a simple cylindrical object that would serve as our enemy. We adjusted our EnemyScript to get these objects out of the way by placing them on a different layer (one that would interact with the “Ground” layer, but nothing else). This prevents the player from colliding with them once the death trigger has been hit. We also used the SpriteRenderer’s “Color” property to change the sprite to gray, and turned off the “freeze rotation” option on the Rigidbody2D. Finally, a slight velocity assured that our character would “fall over”.

private void EnemyHasDied()
{
    // no longer alive
    _isAlive = false;

    // destroy the instance
    Destroy(this.gameObject, 3.0f);

    // change the color
    sprite.color = Color.gray;

    // roll over
    rb.freezeRotation = false;

    // put this on the dead layer 
    this.gameObject.layer = 13;
    rb.velocity = Vector3.right;

}

Part 3: Pushback

Up to this point, our enemy has been capable of one-shotting our Player character, but many times these games feature a “health” system, which allows for multiple hits before player death. One issue commonly encountered when first coding these health-based mechanics is accounting for multiple successive hits. Our enemy characters keep pushing ahead, often times this can cause multiple hits before your player has time to react. To address this, we introduce two mechanics – The first is a “stunned” state, where the player is incapable of controlling movement, but is also invulnerable for a period of time.

We accomplish this by introducing a “stunned” boolean to the character controller, and testing that when we use our input or process collisions with enemies. We only process the collision if stunned == false, otherwise we ignore it. If we DO get hit, then we set “stunned” to true, and run an animation (here we keyframe the color value of the sprite to give a red tint that fades out over one second). We use Animation Events to call another function that ends our stunned status, setting the value back to false.

The second mechanic is a “pushback” force… if we are hurt by an enemy, we should be propelled back in the opposite direction. here we accomplish this by drawing a line between the two characters and applying a force in the opposite direction.

private void OnCollisionEnter2D(Collision2D collision)
{
    if (collision.transform.tag == "Enemy")
    {
        if (controller.stunned == false)
        {
            // take damage
            controller.stunned = true;

            // run the hurt animation
            animator.SetTrigger("Stunned");

            Vector3 pushback = collision.transform.position - transform.position;
            GetComponent<Rigidbody2D>().velocity = pushback * -pushbackForce;


        }
    }
}

Part 4: Melee Attacks (Hitbox and Hurtbox)

Often times our characters have attack animations, such as the one in the Ninja pack that we used for today’s class. These attack areas often fall outside of the original sprite dimensions, meaning that we must define a volume that will be the area of the attack’s effect. This is know as a hitbox and conversely, the area that is vulnerable to damage is the hurtbox. In the case of our Enemy object, the Box Collider trigger is our hurtbox. (Our player, on the other hand, is one giant hurtbox.)

To define this hitbox, we created a similar system to our “Ground Check” – defining an point relative to the player object, and a radius of effect. Once we attached this to an “attack” animation, we noticed that the death was instant, before the sword even reached the enemy objects. To counteract this, we created another Animation Event that calls the hitbox check midway through the swing, which improves the timing to match the movement.

Player.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Player : MonoBehaviour
{
    public int score = 0;

    public bool isAlive = true;

    private SideScrollerController controller;
    private Animator animator;

    public float pushbackForce;

    [Header("Attack Check Values")]
    public float attackXOffset = 0;
    public float attackYOffset = 0;
    public float attackRadius = 0.5f;
    public LayerMask attackLayer;

    private void Start()
    {
        controller = GetComponent<SideScrollerController>();
        animator = GetComponent<Animator>();
    }

    private void Update()
    {
        if (Input.GetButtonDown("Fire1"))
        {
            
            if (!controller.stunned)
            {
                // call the attack
                PlayerAttack();

            }
            
        }
    }

    private void PlayerAttack()
    {
        // queue the animation
        animator.SetTrigger("Attack");

        // make the attack happen



    }

    public void ProcessAttack()
    {
        // offset vector
        Vector3 offset = new Vector3(attackXOffset, attackYOffset);

        offset.x *= transform.localScale.x;

        // run physics
        Collider2D[] colliders = Physics2D.OverlapCircleAll(transform.position + offset, attackRadius, attackLayer);

        foreach (Collider2D thisCollider in colliders)
        {
            // yell "hit" at the object
            thisCollider.gameObject.SendMessage("SuccessfulHit");
        }

    }

    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.transform.tag == "EndOfLevel")
        {
            LevelManager.S.NextLevel();
        }
        
        if (collision.transform.tag == "EndOfGame")
        {
            LevelManager.S.GoToStartMenu();
        }

    }

    private void OnCollisionEnter2D(Collision2D collision)
    {
        if (collision.transform.tag == "Enemy")
        {
            if (controller.stunned == false)
            {
                // take damage
                controller.stunned = true;

                // run the hurt animation
                animator.SetTrigger("Stunned");

                Vector3 pushback = collision.transform.position - transform.position;
                GetComponent<Rigidbody2D>().velocity = pushback * -pushbackForce;


            }
        }
    }

    public void StunExpires()
    {
        controller.stunned = false;
    }

    public void PlayerHasDied()
    {
        LevelManager.S.RestartLevel();
    }


    private void OnDrawGizmos()
    {

        // offset vector
        Vector3 offset = new Vector3(attackXOffset, attackYOffset);

        offset.x *= transform.localScale.x;

        // Draw a yellow sphere at the ground check position
        Gizmos.color = Color.cyan;
        Gizmos.DrawWireSphere(transform.position + offset, attackRadius);


    }

}

EnemyScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class EnemyScript : MonoBehaviour
{
    public float speed;
    public bool faceLeft = true;

    public bool _isAlive = true;

    private Rigidbody2D rb;
    private SpriteRenderer sprite;

    // Start is called before the first frame update
    void Start()
    {
        rb = GetComponent<Rigidbody2D>();
        sprite = GetComponent<SpriteRenderer>();
    }

    // Update is called once per frame
    void Update()
    {
        /*
        if (faceLeft && sprite.flipX)
        {
            sprite.flipX = false;
        }
        else if (!faceLeft && !sprite.flipX)
        {
            sprite.flipX = true;
        }
        */

        if (faceLeft == sprite.flipX) { sprite.flipX = !sprite.flipX; }
    }

    private void FixedUpdate()
    {
        if (_isAlive)
        {
            float direction = faceLeft ? -1 : 1;
            rb.velocity = new Vector2(direction * speed, rb.velocity.y);
        }

    }

    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.gameObject.tag == "TurnAround")
        {
            faceLeft = !faceLeft; // invert faceleft
        }

        if (collision.gameObject.tag == "Player")
        {
            EnemyHasDied();
        }

    }

    public void SuccessfulHit()
    {
        if(_isAlive)
        {
            EnemyHasDied();
        }
    }

    private void EnemyHasDied()
    {
        // no longer alive
        _isAlive = false;

        // cue the death animation 
        // GetComponent<Animator>().SetTrigger("EnemyDied");

        // increase the score
        // GameManager.S.IncreaseScore(50);

        // destroy the instance
        Destroy(this.gameObject, 3.0f);

        // change the color
        sprite.color = Color.gray;

        // roll over
        rb.freezeRotation = false;

        // put this on the dead layer 
        this.gameObject.layer = 13;
        rb.velocity = Vector3.right;

    }



}

SideScrollerController.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

/*
 *  SideScrollerController - created for UGE Summer 23
 *  Based on Sharp Coder 2D Controller (https://sharpcoderblog.com/blog/2d-platformer-character-controller)
 */

public class SideScrollerController : MonoBehaviour
{
    // Player Movement Variables
    public float maxSpeed = 3.4f;
    public float jumpHeight = 6.5f;
    public float gravityScale = 1.5f;
    float moveDirection = 0;
    public bool isGrounded = true;
    public bool isConveyer = false;
    public bool facingRight = true;

    public LayerMask conveyerLayer;

    // public Transform groundCheckObject;
    [Header("Ground Check Values")]
    public Vector2 groundCheckPosition;
    public float colliderRadius = 0.5f;
    public LayerMask groundLayer;

    private Animator animator;

    public bool stunned = false;



    // components
    Rigidbody2D r2d;
    CapsuleCollider2D mainCollider;
    // Transform t;

    // Start is called before the first frame update
    void Start()
    {
        // set the component variables
        r2d = GetComponent<Rigidbody2D>();
        mainCollider = GetComponent<CapsuleCollider2D>();

        // setting some component properties
        r2d.freezeRotation = true;
        r2d.collisionDetectionMode = CollisionDetectionMode2D.Continuous;
        r2d.gravityScale = gravityScale;

        // set the initial facing right value
        facingRight = transform.localScale.x > 0;

        animator = GetComponent<Animator>();
        
    }

    // Update is called once per frame
    void Update()
    {

        // Movement controls
        moveDirection = Input.GetAxis("Horizontal");


        // set animation controls
        // animator.SetFloat("speed", Mathf.Abs(moveDirection));
        // animator.SetBool("isOnGround", isGrounded);

        // TO-DO:  Implement Change Facing Direction

        if (moveDirection > 0 && !facingRight)
        {
            facingRight = true;
            transform.localScale = new Vector3(Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }
        if (moveDirection < 0 && facingRight)
        {
            facingRight = false;
            transform.localScale = new Vector3(-Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }




        // Jumping
        if (Input.GetButtonDown("Jump") && isGrounded){
            r2d.velocity = new Vector2(r2d.velocity.x, jumpHeight);
        }


    }

    void FixedUpdate()
    {
        if (!stunned) { 
            r2d.velocity = new Vector2((moveDirection) * maxSpeed, r2d.velocity.y);
        }

        Vector3 groundCheckOffset = groundCheckPosition * transform.localScale;

  
        // Check if player is grounded
        Collider2D[] colliders = Physics2D.OverlapCircleAll(transform.position + groundCheckOffset, colliderRadius, groundLayer);

        // check for a grounding collider
        isGrounded = colliders.Length > 0 ? true : false;


    }

    private void OnDrawGizmos()
    {

        Vector3 groundCheckOffset = groundCheckPosition * transform.localScale;

        // Draw a yellow sphere at the ground check position
        Gizmos.color = Color.yellow;
        Gizmos.DrawWireSphere(transform.position + groundCheckOffset, colliderRadius);


    }

    /*
    private void OnCollisionEnter2D(Collision2D collision)
    {
        if (collision.transform.tag == "Enemy")
        {
            // Death happens here

            // queue the death animation
            animator.SetTrigger("Death");
        }
    }
    */

}

Part 1: Animation Events

Today we created a classic element from the old side-scrollers, the coin box. Super Mario Brothers featured these boxes throughout their levels, and they were a wonderful devices. A player would jump from underneath, the box would shift up slightly to indicate that your actions caused a reaction, and a spinning coin would pop out, increasing your coin count and playing a happy coin sound to reinforce that a good thing happened, and your brain would release just a little more dopamine. Ahhh….

To construct our coin box, I first created a prefab element that contains a box sprite from our environment sprite sheet, and that sprite has a box collider to receive the impact event, and the animator component so that we can make it move. (Remember, if you make the moving object a child of the prefab parent object, then the transform animation will be in relationship to its steady parent object. This way the box will work the same wherever the prefab is placed and we do not need to use Apply Root Motion to keep it in place)

I generated two animation clips, a quick upward bump animation (at a sample rate of 12 frames per second) and a single frame idle animation that will be our default state. I generated a Trigger parameter that we can fire off when the player touches our Box Collider 2D. This will move us to the Bounce animation. Rather than set an exit condition to this clip, we select “Has Exit Time”. This way, once the clip has run, the exit transition will automatically be processed and we will return to the idle state.

We wrote a quick script (BoxScript.cs) to attach to the box object that uses OnCollisionEnter2D( ) to detect a collision with the player, and the Animator component to set the trigger. First step completed!

Next, we created a jumping coin. We built this with our spinning coin sequence, running at a higher sample rate of 24fps, and animated the position so it made a quick jump up and back down. We made this a prefab object as well, so that we could call it into existence whenever a box is bounced.

Now it is time to connect the two objects. In our box script, we added a public function LaunchCoin( ) that would instantiate our coin prefab at the box position when called (and then destroy it momentarily afterwards because it’s always good to clean up after ourselves). Because this BoxScript class is attached to the same object as our Animation, and because the function was made public, it is now available to us as an animation event.

At the height of our boxes bounce clip, I added an Animation Event to the timeline. You can see it up there just under the number 3 – it’s the little white marker. To create an event, you hit the “Add Event” button which is located just next to the “Add Keyframe” marker in the Animation window. (Just under the Sample Rate field).

The Event itself can be configured in the Inspector. Select the event marker in the timeline and then use the dropdown in the Inspector to associate it with a public available function attached to that object.

Here our animation event takes no arguments, but you can configure one parameter to be passed when the event is called. This can be either a float, int, string, or object reference. Now we have a coin that pops out of our box. Our coin sticks around a little longer than we would like, so we disable looping on the Animation Clip, and also add the Sprite Renderer’s “enabled” property to the clip so that we can turn off the visual once it has landed.

Finally we created a separate CoinScript that registers the scoring event and commands an attached AudioSource to play a coin sound. Using Animation Events again, we can fine tune the timing of that sound in relation to our animation. Timing sounds to events is one of the more common use case that I have found for these type of event calls, as it allows you to synchronize a sound with a particular frame or feature of animation, such as making a “footfall” sound in a walking or running animation.

Part 2: 2D Effectors

Sometimes our standard platforms don’t quite do what we want them to. Or there are effects we would like to create such as wind, or a conveyor belt, or floating on water. Thankfully, Unity includes a number of “effector” components that modify a standard 2D collider and turn it into a specialty object or zone.

The important thing to keep in mind is that in order for an effector to work, it must be a component on the same object as a 2D collider, and that collider must have the Used by Effector checkbox ticked. Some effectors (like the Platform Effector and Surface Effector) require that the collider be a solid object. Others like the Area Effector and Buoyancy Effector require that the collider be set up as a Trigger. I have a short description of each of these types below, but for more information on how to use them I recommend watching the recording of today’s class.

Platform Effector

The Platform Effector allow us to create platforms that can be accessed from one direction but solid from another. The most common use of this is a platform that you can jump to from directly underneath, such as in the image below. While these platforms were created in a Tilemap, using the TilemapCollider would result in an impervious surface that my player object cannot jump through.

Instead, I have created a series of empty objects with Box Colliders that fit over these platform tiles, and then added the Platform Effector component to each of these objects. I have set the colliders to Used by Effector, and now I have a one-way platform that will let me pass through as long as I am moving in an upward direction. This is the default setting of 180 degrees, and is represented by the arc in the scene window. This arc and the rotation offset of that arc can be set in the component. You can also mask the physics layer of this effect.

Area Effector

The Area Effector take a Collider that has the Is Trigger property checked, and converts it into a force applying zone of influence. This creates a force applied in a single direction, and you can alter the magnitude of the force, and introduce variations to that magnitude that will apply some randomness into the effect. The Force Target determines whether the force is applied directly to the Rigidbody, or to the Collider itself. If it is the collider, this can generate torque (rotation) if not coinciding the the center of mass. Applying directly to the Rigidbody is the same as applying to the center of mass and so no torque will be generated.

Buoyancy Effector

The Buoyancy Effector is useful for creating water-like settings, where you have a character or objects that have to swim or float within a substance. Here, there is a defined Surface Level and a Density that define how objects should float. The more mass an object has across it’s collider, the less buoyant it is considered to be, and will sink further into the area. You can also define a Flow force to be applied as well, if you want your body of water to have a current.

Surface Effector

Finally, the Surface Effector creates a conveyor like system, where a tangent force is applied along the surface of the collider, at a set speed. The Force Scale is used to adjust how the effector attempts to get the colliding object to arrive at the set speed. A value of 1 will override all other movement such as walking, so a lesser value is recommended. The Use Contact Force option is similar to the Area Effector’s Force Target. If checked, the force is applied at the contact point of the collider, if unchecked the force is applied to the collider as a whole. (Point of Contact can cause rotational forces to be applied, which made the box in the bottom image spin)

UI: Canvas

When you create your first UI element, Unity will automatically create a Canvas object inside of your scene, along with the “EventSystem” object that you can ignore for now.

The Canvas is the two-dimensional object that holds your user interface objects. Text, buttons, images, sliders, dropdowns… all of these UI type objects need to be contained inside of a Canvas object. All objects on the canvas are placed using the Rect Transform, a method of rectangular transformation for 2D objects. A Rect Transform defines a rectangle of pixel dimensions W (width) and H (height), and the offsets X and Y measuring the distance the pivot of the object should be placed from the “anchor”. The anchor is a method of defining how it should be offset from it’s parent object, and can be placed at a normalized value horizontally or vertically. The Anchor presets give you options for placement from the Top, Middle, or Bottom vertically, or Left, Center, or Right horizontally. These presets work similarly to text alignment in a word document or spreadsheet cell.

There are two settings inside the Canvas object which are particularly important for setting up your UI. The first is the Render Mode inside the Canvas component. There are three modes available:

• “Screen Space – Overlay” is the default setting and will be your most common use case. This setting causes the canvas objects to be drawn over top of your content on the screen. The canvas will cover the entire area of your screen, and resize if your window resizes. This is similar to the concept of “compositing” video by adding graphics overtop of a video feed. The two do not interact visually at all.
• “ScreenSpace – Camera” works similar to the Overlay method, however it sets the screen out at a distance from the camera, and the camera’s perspective will apply, as opposed to the overlay’s planar projection style.
• “World Space” creates a canvas object in the scene, as opposed to an overlay. This object is a rectangle but has a transform (and thus a position and orientation) within the environment itself. This is what is commonly referred to as a “diagetic” interface, in that it exists within the world itself, rather than just from the perspective of the player/observer.

The Unity Manual has more descriptions and examples of these modes.

The Canvas Scaler controls the way in which objects will respond to different window sizes. You may have noticed that often that the size and placement of UI objects in your game window do not match their size and placement when you run the game at full screen. This is because the Canvas Scaler is set by default to Constant Pixel Size. In this mode, objects retain their width and height values, unaffected by the larger screen. I recommend using the second option, Scale With Screen which will scale the size and positioning of UI objects up and down with the game screen size, thus preserving your layout as it appears in your editor.

UI: Panels

If you want to group your buttons into a more formal menu, you can use the Panel object. This simply creates a UI Image object, but one that has a background that mimics the button background, only more transparent. By default, the Panel will fill the screen, but by changing the Rect Transform you can resize it and make objects children of this object.

Panels are an easy way to collect buttons and other UI elements into one place, and can be activated and deactivated. This can be useful for making menus that slide up or over, or populating a tabbed menu. Panels are also useful for gathering UI elements into one location, and for providing contrast for the UI elements against the game view itself.

Unity’s default panel uses the rounded rectangle UI Sprite to soften it’s edges. If you would prefer to use a solid color, just set the Source Image setting to “None”.

UI: Buttons

Creating Buttons

To create a button, select Create > UI > Button. This will generate a simple grey button with black text on your screen, and place it in your Canvas. (If you have not created a Canvas yet, Unity will generate one for you.)

You can use the Rect Transform to position the object. Clicking the Anchor diagram will call up the Anchor Presets option. Note the modifiers listed at the top for the Shift / Alt keys. Pressing “Shift-Alt” and clicking the center object will move your button to the middle of the screen.

The text of your button is actually a separate text object – to change the text, find the button object in your hierarchy, and expand it to see the child objects (in this case a “Text” object) and edit the value in the Text field.

Button Actions

To assign a function to a button, you must first have an object in your scene that has a script with a public function. In this case, we are accessing the “UIScript” class that has been attached to the “UIManager” object and lives in the scene.

With the button selected, look at the “Button” component and find the On Click ( ) panel a the bottom.

Click the “+” symbol to add a new On Click action. You’ll see an empty Object field.

Drag the object that with the script or component that contains the method you want to trigger with this button into the Object field.

Next, click the dropdown (currently showing “No Function”) and select the script or component, and then the function you want to run. Now the button press will call that function when clicked. Button Actions can also have up to one parameter.

Button Sounds

We can use the same On Click ( ) panel to emit a sound when a button is pressed. We created an empty object and added an audio clip to it, which generated an AudioSource component.

In the OnClick( ) section of our button we add another action, this time adding our sound object, then setting the function dropdown to AudioSource > Play( )

AudioSource is exposed because it is a component of the object, and the Play( ) command is available publicly. Another handy tool is the AudioSource > PlayOneShot( ) method, which lets us play a single pass of an audioClip. Selecting this opens another field of the AudioClip type, and we can drag that directly from our Assets folder into the field, and now it will make that noise when clicked.

Button Sprites (Color & Image)

One way to change the visual appearance of your game is to edit the color of the buttons to move away from the default light gray button that Unity provides. In the Button’s Image component, you can set the Color value to customize the appearance.

The Button component gives you access to the states of the button so that you can provide feedback for selections, presses, and active vs. inactive states. The default Button object uses Color Tint as the method for changing these states, which provides a subtle adjustment to the overall brightness of the button image (but not the text object)

Another way to customize this is to create your own custom button states using sprites. If you ever created your own buttons to build a website, this process will feel familiar – you generate similar images for each and then swap their placement when in the various states. We will look more at this in the next project.

Button Navigation

You may have noticed that when we have a button selected, we can use the arrow keys to cycle through the selected option. This is thanks to the Navigation system. By default, Navigation is set to “Automatic”, which means that Unity will try to figure out the logic for itself. Sometimes this logic does not make a great deal of sense, so if you want to see what is going on, click the Visualize button and you will see a flow diagram appear between your UI elements.

The yellow arrows indicate where the selected state will transition when a horizontal or vertical button is pressed. If you want to set these yourself rather than rely on Unity’s automatic setting, open the dropdown and deactivate the items so that only “Explicit” is selected, then you can define the object by dragging it into each directional slot.

Part 1 – Scenes

In the early days of gaming, developers would divide a game up into small chunks called “levels”.   While they were useful for players to measure their progress, their real purpose was to minimize the amount of data a game had to hold in memory in order to be playable.   Even today, as games allow us to explore cities, countries, worlds, galaxies… the “level” is commonly used as a way to divide up content.  It would be silly to hold the final boss battle of a game in active memory when a player is hours away from encountering it.   Each draw call would have to consider every polygon in the entire game, every object and behavior would have to be set just so.  In short, it would be chaos.  Computationally expensive chaos.  Why spend all of those cycles considering things that are hours away from use?

So instead we break up our game into smaller chunks and these load into memory when they are needed, hence the “loading” screen that so many games have.  (You may be thinking “but what about sandbox games?”  Well, those are divided into smaller areas as well – and not just areas, even objects inside those areas have various levels of detail that can be called up.  The loading of that content happens in the background, and will swap places with a lower quality model when ready, usually fading between the two so as to disguise the effect and not distract the eye.  Most often this happens in the distance, and the game is using predictive algorithms to determine which content you are most likely to need yet and start to load it.)

When Unity was first created, they also included a level system, which became known as Scenes.  You will recognize this today as the format that we save our files in.  Scenes have evolved to be much much more than just game levels, and are frequently seen used for other cases such as UI screens/menus, code and asset loading, and animated cutscenes.  Sometimes entire games will be saved as scenes.   Projects (the things we open when we launch Unity, and where our Assets and such are stored) can contain multiple scenes, and when we build our game we will designate which of the scenes we create will be included in the build.  (This is particularly useful when you’re working on branches or variations of your game – you can simply swap one out for another if you need to!)

For our in-class demo, we changed the name of our main game scene from the Unity default “SampleScene” to “Level01”. We also created a new scene (“StartMenu”) to house our UI, and a quick small game scene we named “Tutorial”.

NOTE – Don’t worry too much today about the buttons, we will take a deeper dive into the UI system in the next class.

Part 2 – Setting up Buttons

Unity’s UI buttons are easy to generate by going to Create > UI > Button or in the top menu GameObject > UI > Button.  This will create a new button object as a child of the Canvas object (which will also be created if you don’t already have one).  Buttons consist of two parts, the Button object, and a child Text object.   The Button object has two Components to note – the “Image (Script)” component where you define the look of your button, and the “Button (Script)” component where you can define the behaviors and transitions of the buttons.  The default button transition is a color tint, but If you have pre-made images for your button states, you can use the “Sprite Swap” transition to show them.  The child text object is optional.

Now for the complicated part – adding an action to your button.  Buttons have an “OnClick()” message that they send when a user clicks them but accessing them is not as simple as accessing collider messages.  At the bottom of the “Button (Script)” component you will see an “OnClick()” panel that is empty.  If you click the “+” button it will create a new action.  This action requires an object to be associated with it in order to access its scripted functions.   You can add a script to the Button object, but then you will have to self-associate the button with itself.   NOTE: The object HAS to be an object currently in the hierarchy.  Linking to a prefab does not work.

In class, I created an empty game object (“LevelManager”) and added a script (also called “LevelManager”) which contained a single function that we would use to move to the next scene (“btn_StartTheGame”). In the OnClick( ) menu I associate the script object and select a function from the dropdown on the right by going to the specific component “LevelManager” and selecting the function I want to use.

NOTE:  Any function that will be accessed by a Button must be PUBLIC, and VOID.  It can only take up to one (1) parameter, that parameter can only be a Float, Int, String, or Object.

Part 3 – Scene Manager

Now that we have a button in place, let’s connect some scenes.  I’m going to make our LevelManager script handle our first scene jump.

First, I have to add a new library to the code, so I start the file by adding this line:

using UnityEngine.SceneManagement;

Now we can access the scene management commands.   I can create a button command, so looking at our button example above to make us jump to the Level01 scene, I create the following in button script.

public void btn_StartTheGame()
{
    SceneManager.LoadScene("TutorialLevel");
}

Again, please note that this must public and void for the editor to see it.  Here, ours takes no arguments.    And the command itself is rather simple – we run the LoadScene( ) function and pass in the string name of our level.   We can also pass in an integer that corresponds with the scene index.  Speaking of…

Part 4 – Adding Scenes to the Build

In order to load scenes, Unity has to have those scenes associated with the build.  You can do this by going to File > Build Settings, and dragging the scenes you will be using from the Asset panel into the scene list in Build Settings.  Notice that when you add a scene, it also assigns it an indexed location.

Once you have associated the scenes, you can close the window.  (There is no save button to worry about, your changes are automatically registered.)

Part 5 – Staying Alive (DontDestroyMeBro!)

If we are making a game, chances are we want to do things like keep track of the score, or the number of lives remaining.  A GameManager script seems like the best candidate for this. We created an empty object, assigned it a GameManager script which sets up a singleton, and converted it into a prefab. We made sure to include this prefab in both of our platform game scenes, as we will need it to handle our logic for events like player deaths, inventory, and of course, the score.

We edited our Level Manager to also be a singleton (so that we can automatically access it within a scene) and added a public string to hold the name of the next scene we should visit upon successful completion of the level.

If our player successfully reaches the end of a level, we reward them by sending them to the next one. To support this, we set a trigger at the end of the level, and tagged it with a “EndOfLevel” tag. If the Player object enters the trigger with that tag, it calls the NextLevel( ) command from the LevelManager and that sends the player to the appropriate scene.

private void OnTriggerEnter2D(Collider2D collision)
{
    if (collision.gameObject.tag == "EndOfLevel")
    {
        LevelManager.S.NextLevel();
    } 
}

In our GameManager script, we define our scene jump like so:

public void NextLevel()
{
    SceneManager.LoadScene(nextScene);
}

But now we have a problem. GameManager only exists in the scene that I created it in.  As soon as I jump to a new scene, it gets destroyed just like everything else in its host scene and THAT scene’s GameManager instance appears.  I spent all that time collecting those coins, and now they’re gone!

If I want to hold onto things like my score, remaining lives, and inventory, I need to make GameManager persist across the transition from one scene to the next.

To accomplish this, we spare GameManager from an untimely deletion by adding the following line to the Start ( ) function in the GameManager script.

DontDestroyOnLoad (this);

DontDestroyOnLoad ( ) preserves a game object across transitions.  It actually creates a little side scene in the Hierarchy and moves the object into it during runtime, as seen below:

Now when we jump scenes, this object remains, and our score persists as we play through.

But… (you knew there would be one, didn’t you?)

For our game to run correctly, we need to have GameManager running in every scene. This means that either we would ALWAYS have to start our game from the very beginning in the scene where we first instantiate it and play all the way through – not fun, especially when we just want to test one tiny thing in level 5 – OR we have to find a way to include it in EVERY scene. This is why we chose to make our Game Manager a prefab, and drop an instance of it into every level.

But… if we are not destroying our Game Manager and we load a scene with another instance of Game Manager, won’t there be two Game Managers?

Yes there will, and that is a problem.  Because now not only do we have two game managers, the new one has just declared itself the singleton (S = this) and overwritten the old one, meaning the new object’s score is the one we display and that’s not what we want at all, is it?   And if we move scenes again, since both of these now live within the DontDestroyOnLoad section, we will be adding a third Game Manager and overwritting our Singleton yet again and this seems bad.

So to avoid this situation, we create a small workaround.  We build in a check in our Game Manager start script that checks to see if any instance of the singleton exists.  If none exists, great – we’re first to the party and we set up shop.  But if there is already a singleton defined, we kill this instance of the manager as it is not needed.  The script for that looks like this:

private void Awake()
{
    if (S)
    {
        Destroy(this.gameObject);  
        // Singleton already exists, remove this instance
    } else { 
        S = this;  // Singleton Definition
    }
}

Here we check for the existence of another version of GameManager.  If none exists, GameManager.S will return “null”.  If not null, someone is already here.  We destroy this new version, and we submit a “return” command, which exits our script rather than continuing on.

Once we’ve passed our null-check, the script is still executing so we know we must be the one true game manager. We assign Singleton status and then in the Start( ) method we declare our intention to live forever.

Part 6 – I’m Ready to Go Now

What about when we DO want something to disappear? In the case of our game flow, how do we reset a game if we reach a win or lose state? How to do we go from zero lives remaining back to three, to full health, to an empty inventory? We could write an elaborate script to reset our conditions internally, but the easier method would be to simply let the GameManager die, return to the Title Screen, and let the next GameManager that comes along start the process all over again.

It turns out that the answer to this is quite simple – we Destroy( ) the Game Manager from within itself. DontDestroyOnLoad only preserves objects across transitions – it does not make them immortal.

In this example, we are returning to the title screen (for whatever reason) and we remove the GameManager object.

private void OnTriggerEnter2D(Collider2D collision)
{
    if (collision.gameObject.tag == "EndOfLevel")
    {
        LevelManager.S.NextLevel();
    } else if (collision.gameObject.tag == "EndOfGame")
    {
        Debug.Log("EndOfGame Reached");
        // tell the level manager to go back to the start menu
        LevelManager.S.GoToStartMenu();
    }
}

Part 7 – Restarting a Level

My favorite method for managing death and respawning in a platform game is to simply restart the level by reloading it. This means that all objects in the scene will be destroyed and re-instantiated.

Here is a sample script of how you could handle this, by checking for lives remaining. (NOTE: this is not what we implemented in class today)

public void PlayerDied()
{
    livesRemaining--;
    Debug.Log("Lives Remaining = " + livesRemaining);

    if (livesRemaining <= 0)
    {
        LevelManager.S.GoToStartMenu();

    } else
    {
        LevelManager.S.RestartLevel();
    }
}

Here, if my Player dies but I still have lives left, my GameManager script calls RestartLevel( ) which simply loads the same scene by passing it the name of the current active scene. It is a simple and clean solution, if you don’t need to preserve the state of objects or items within the level.

public void RestartLevel()
{
    SceneManager.LoadScene(SceneManager.GetActiveScene().name);
}

If you DO need to preserve states or items , you can store this information in your undestroyed game manager and when the level restarts, have the objects check for relevant data. For instance, if you were building checkpoints into your game you could store a “checkpoint” value with a unique ID for where to place the player.

Better yet, you could make a Level Manager which would store the states of the objects in the level itself, but which would destroy itself when your script moved on to the next level. Then you have a GameManager that lives across the game, and a LevelManager that lives across attempts at a level.

GameManager.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using TMPro;

public class GameManager : MonoBehaviour
{
    public int score = 0;
    public static GameManager S;

    public TextMeshProUGUI scoreText;

    private void Awake()
    {
        if (S) { 
            Destroy(this.gameObject); 
        } else { 
            S = this;  // singleton definition
        } 
    }

    private void Start()
    {
        // set the game manager to persist across scenes
        DontDestroyOnLoad(this);

        // scoreText = GetComponent<TextMeshProUGUI>();
        scoreText.text = "Score: " + score;


    }

    public void IncreaseScore(int scoreAmount)
    {
        score += scoreAmount;
        scoreText.text = "Score: " + score;
    }

}

LevelManager.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.SceneManagement;

public class LevelManager : MonoBehaviour
{
    public string nextLevel;
    public static LevelManager S;

    private void Awake()
    {
        if (S)
        {
            Destroy(this.gameObject);
        } else
        {
            S = this;
        }
    }

    public void btn_StartTheGame()
    {
        // start the game by going to the first scene
        SceneManager.LoadScene("Level01");
    }

    public void NextLevel()
    {
        SceneManager.LoadScene(nextLevel);
    }

    public void GoToStartMenu()
    {
        SceneManager.LoadScene(0);
        Destroy(GameManager.S.gameObject);
    }

    public void RestartLevel()
    {
        SceneManager.LoadScene(SceneManager.GetActiveScene().name);
    }

}

Player.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Player : MonoBehaviour
{
    public int score = 0;

    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.transform.tag == "EndOfLevel")
        {
            LevelManager.S.NextLevel();
        }
        
        if (collision.transform.tag == "EndOfGame")
        {
            LevelManager.S.GoToStartMenu();
        }

    }

    public void PlayerHasDied()
    {
        LevelManager.S.RestartLevel();
    }

}

Yesterday, we made made animations by selecting sprites that would play in sequence. We also used the created moving platforms by adjusting the values of the position over time. Today, we will combine those methods to create new animations clips using Sprites in the Animation window, and to generate behaviors as we transition between those clips.

Part 1: Animating Properties

Our enemies here are relatively simple, and they only need to have two states – walking, and dying. Our first step is to create our walking animation, which we will do from the sprites included in the sprite sheet.

Since our enemy object already exists, and the prefab has been placed into multiple places, it would be easier for us to add the sprite animation to the existing object. We open the prefab, select the enemy object, and open our Animation Window. You should see a message indicating that there is no Animator or Animation Clip associated yet, and a button to let you create those. Click that button, and give your walking clip a name (and location, if you’re trying to keep your file structure neat).

Now this will create an empty Animation Clip. From here, the sprite animation is easy to create. We can simply grab the sprites from the Asset Folder and drag them directly into the Dopesheet on the Animation Window. This will create a sprite animation.

If you play this, you will notice that it moves very fast. That is because Unity by default creates animation clips to run at a sample rate of 60, meaning it holds 60 timing frames per second. Since we are dealing with sprites, turn this setting down to 12, which is the default setting for sprite animation.

Next, create a new clip that will be our “dying” clip. Here, we are going to use the Animation Clip to manage a few properties for us, saving us the trouble of having to make these happen through programming. Our intended behavior is that when an enemy is hit, it will stop moving, blink rapidly, then disappear. During this time, it’s colliders should also be turned off so that the player cannot be affected by accident.

Inside of our empty dying clip, I add new properties, specifically the “enabled” property for both colliders. This will start them with a keyframe at the first and last frame, which I will set to be unchecked. Next I will add the Sprite Renderer > Enabled property, and set keyframes every few frames to cycle this property on and off quickly to create a blinking movement.

Next, I set up the clips in my Animator to move from Walking to Dying only when a particular trigger is called (I’ve called mine “Dying”).

Lastly, I make some modifications in my script by setting the rigidbody to isKinematic so that it will no longer move, and setting the velocity to 0, calling the SetTrigger( ) function from the Animator, and putting a 1 second delay on the Destroy( ) call so that the death animation has time to run.

Part 2: Player Animation States

The principles behind our player animation are very similar to those of our Enemy object, except now we have many more clips to move between. For this section, I highly recommend watching the video walkthrough, as a writeup will not do the process justice. However, here is a brief summary of the various animation states we attach to the player object.

We set up parameters to assist with the various conditions that we will want to cause a transition to occur. These include:

• speed: a float value that will determine if our character should walk, run, or stand idle.
• isOnGround: a boolean that we will use to determine if our player is mid-air or grounded.
• Death: a trigger that we will call as events to move us between states

Above is our finished controller, with transitions in place. Here is how I have them configured:

1. Entry: This step is automatic. Anytime the animation controller is enabled, or if another animation passes through the “Exit” state we will reset to here. Immediately moves to the default state, “player_idle” which holds our idle animation.
2. Idle/Walk: uses the “speed” float as a condition to move between states. If we are Idle and speed is > 0.1 we will move to “player_walk”. If the current state is Walk and speed is < 0.1 we will move back to “player_idle”.
3. Walk/Run: Similar to Idle/Walk, transition occurs when the speed crosses a value of 0.9
4. Jump: All three of these transitions will use the “grounded” boolean, which we will populate from the “isGrounded” property of our character controller. A value of “false” will trigger this transition.
5. Exit from Jump: Rather than creating multiple return paths and testing each path for speed values inside a range, we end our jump by exiting the animation when “isOnGround” equals “true”. This sends us back to the “Entry” state, which moves us to Idle and then evaluates based on our current speed to arrive at the correct position.
6. Death: Because we may die at any time, we build the transition to the “Death” animation from the “Any State”, and set the condition to the “Death” trigger.
7. Exit from Death: We did not use this path this year, but in past years I have also set a trigger “PlayerRevive” to act as a singular event that can move us out of the “Death” state. By going to Exit, we re-enter the flow at the “Entry” point and our animation starts again. However, this only makes sense if we are going to have our player object continue to exist. Since we are likely going to reset by destroying and instantiating, or by simply reloading a scene, this is extraneous and so we did not use it this year.

For all sprite transitions, I recommend turning off the Has Exit Time checkbox and setting the Transition Duration to 0 to assure instant transition from one clip to the next.

Animations can be looped by selecting the individual animation in the Asset Window and checking the Loop Time box in the Inspector. Our “Death” animation does NOT loop, as we do not want to die over and over again.

Part 3: Connecting the Parameters

Now we need to send values into the parameters. Previously, we have only used the SetTrigger( ) command, which is similar to calling a function. And because this was a one-time event, we simply ran the GetComponent<Animator> method in-line.

But now we want to submit regular updates to our Animator, indicating our current speed (for the walk cycle) and our grounded state (for the “jump” clip).

We first define an Animator type variable, and assign our component in the Start( ) command, so that we have a steady reference to it.

private Animator animator;

...

void Start()
{  
    ...
    animator = GetComponent<Animator>();
}

Next, we pass in our values – “moveDirection” for the speed and “isGrounded” for the grounding status. Previously we used Input.GetAxisRaw for movement, but because we want to have our character’s speed ramp up, we changed our input to Input.GetAxis. That still returns values between -1 and 1, but our speed check is only looking for numbers between 0 and 1, so we find the absolute value using Mathf.Abs( ).

We place this check inside of the Update( ) command rather than FixedUpdate( ), because we only need to update the values when the frame is preparing to draw.

    void Update()
    {

        // Movement controls
        moveDirection = Input.GetAxis("Horizontal");


        // set animation controls
        animator.SetFloat("speed", Mathf.Abs(moveDirection));
        animator.SetBool("isOnGround", isGrounded);

        ...
     }

We use the SetFloat(string, float) command to say which float parameter, and the value (here an absolute value). We pass the grounded status with SetBool(string, bool), and this will make our character enter the jump animation whenever he leaves the ground.

Finaly, we set our Death animation to occur upon a collision with the Enemy Object, using the SetTrigger() method.

EnemyScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class EnemyScript : MonoBehaviour
{
    public float speed;
    public bool faceLeft = true;

    public bool _isAlive = true;

    private Rigidbody2D rb;
    private SpriteRenderer sprite;

    // Start is called before the first frame update
    void Start()
    {
        rb = GetComponent<Rigidbody2D>();
        sprite = GetComponent<SpriteRenderer>();
    }

    // Update is called once per frame
    void Update()
    {
        /*
        if (faceLeft && sprite.flipX)
        {
            sprite.flipX = false;
        }
        else if (!faceLeft && !sprite.flipX)
        {
            sprite.flipX = true;
        }
        */

        if (faceLeft == sprite.flipX) { sprite.flipX = !sprite.flipX; }
    }

    private void FixedUpdate()
    {
        if (_isAlive)
        {
            float direction = faceLeft ? -1 : 1;
            rb.velocity = new Vector2(direction * speed, rb.velocity.y);
        }

    }

    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.gameObject.tag == "TurnAround")
        {
            faceLeft = !faceLeft; // invert faceleft
        }

        if (collision.gameObject.tag == "Player")
        {
            EnemyHasDied();
        }

    }

    private void EnemyHasDied()
    {
        // no longer alive
        _isAlive = false;

        // cue the death animation 
        GetComponent<Animator>().SetTrigger("EnemyDied");

        // destroy the instance
        Destroy(this.gameObject, 1.0f);

        // disable rigidbody
        rb.velocity = Vector3.zero;
        rb.isKinematic = true;

    }



}

SideScrollerController.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

/*
 *  SideScrollerController - created for UGE Summer 23
 *  Based on Sharp Coder 2D Controller (https://sharpcoderblog.com/blog/2d-platformer-character-controller)
 */

public class SideScrollerController : MonoBehaviour
{
    // Player Movement Variables
    public float maxSpeed = 3.4f;
    public float jumpHeight = 6.5f;
    public float gravityScale = 1.5f;
    float moveDirection = 0;
    public bool isGrounded = true;
    public bool facingRight = true;

    public LayerMask groundLayer;

    public Transform groundCheckObject;
    public float colliderRadius = 0.5f;

    private Animator animator;

    // components
    Rigidbody2D r2d;
    CapsuleCollider2D mainCollider;
    // Transform t;

    // Start is called before the first frame update
    void Start()
    {
        // set the component variables
        r2d = GetComponent<Rigidbody2D>();
        mainCollider = GetComponent<CapsuleCollider2D>();

        // setting some component properties
        r2d.freezeRotation = true;
        r2d.collisionDetectionMode = CollisionDetectionMode2D.Continuous;
        r2d.gravityScale = gravityScale;

        // set the initial facing right value
        facingRight = transform.localScale.x > 0;

        animator = GetComponent<Animator>();
        
    }

    // Update is called once per frame
    void Update()
    {

        // Movement controls
        moveDirection = Input.GetAxis("Horizontal");


        // set animation controls
        animator.SetFloat("speed", Mathf.Abs(moveDirection));
        animator.SetBool("isOnGround", isGrounded);

        // TO-DO:  Implement Change Facing Direction

        if (moveDirection > 0 && !facingRight)
        {
            facingRight = true;
            transform.localScale = new Vector3(Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }
        if (moveDirection < 0 && facingRight)
        {
            facingRight = false;
            transform.localScale = new Vector3(-Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }




        // Jumping
        if (Input.GetButtonDown("Jump") && isGrounded){
            r2d.velocity = new Vector2(r2d.velocity.x, jumpHeight);
        }


    }

    void FixedUpdate()
    {
        // Apply movement velocity
        r2d.velocity = new Vector2((moveDirection) * maxSpeed, r2d.velocity.y);

        // Check if player is grounded
        Collider2D[] colliders = Physics2D.OverlapCircleAll(groundCheckObject.position, colliderRadius, groundLayer);

        // check for a grounding collider
        isGrounded = colliders.Length > 0 ? true : false;
        
        
    }

    private void OnDrawGizmos()
    {
        // Draw a yellow sphere at the ground check position
        Gizmos.color = Color.yellow;
        Gizmos.DrawWireSphere(groundCheckObject.position, colliderRadius);
    }

    private void OnCollisionEnter2D(Collision2D collision)
    {
        if (collision.transform.tag == "Enemy")
        {
            // Death happens here

            // queue the death animation
            animator.SetTrigger("Death");
        }
    }

}

Part 1: Camera Control

Now we have created a player object and let him run through our level, but very quickly the player runs out of view. There are a number of ways to address this. The simplest way to let the camera follow our player is to make the camera a child of the player object. This way, any movement of the player was automatically reflected in the camera. The end result is that the player remains perfectly still as the rest of the world moves around it.

This solution is OK, but does not really fit what we are going for. This should be a side scroller, meaning we move our camera to the side, and so we need a better solution.

Our first step is to move the camera horizontally with the player, but not vertically. We accomplish this by placing a script on the Camera object that would mirror the X value of the player object, like so:

public GameObject player;
void Update () {
    Vector3 playerposition = player.transform.position;
    Vector3 cameraposition = transform.position;
    cameraposition.x = playerposition.x
    transform.position = cameraposition;
}

IMPORTANT NOTE: Although our game is 2D, our transforms are still very much 3D. This means when working with position, we always need to use Vector3 rather than Vector2 structures.

We set a public game object and assign the Player object to it in the Inspector.  Then on each frame, we find the X position and match it.  The result was just OK. The side motion worked but things feel a little jittery.  We want to give our player a little room to move away from the center and have the camera catch up, as though it were controlled by some camera person trying to keep up with the action.  To facilitate that, we used Mathf.SmoothDamp( ), a dampening function to create a gentle curve to the updating X values, giving the camera an eased, elastic feel.

public GameObject player;
private float xVelocity = 0.0f;
// Update is called once per frame
void Update () {
    Vector3 playerposition = player.transform.position;
    Vector3 cameraposition = transform.position;
 
    cameraposition.x = Mathf.SmoothDamp (cameraposition.x, playerposition.x, ref xVelocity, 0.5f);
    transform.position = cameraposition;
}

SmoothDamp ( ) is part of the float math libraries, and takes 4 parameters – the start value, the end value, the current velocity (as a reference), and the time the smoothing should occur.  Velocity here is tricky, as SmoothDamp ( ) will modify it each time it runs.  In order to let that persist, we pass the velocity variable as a “ref”, which is the closest we will get to pointers in this class.  Normally when we call a method we say “here is a value” but in this case by declaring “ref”  we say “here is access to the variable itself”.  SmoothDamp ( ) will update velocity each time it runs.

Playing this again, this is getting better.  My player runs away and the camera catches up again.  Since I’ve decided to use “Mario” rules, I want to make sure that the player can only advance, not move backwards.  I’ll do that by defining two rules.

Rule #1: Any time the player moves right of the midpoint on the screen, the camera will follow.
Rule #2: The player can only move as far left as is currently visible on the screen.

Rule #1 is easy enough to implement.  To do this, we set a condition around the SmoothDamp and transform position update that test to see if playerposition.x is greater than cameraposition.x and if so, it will let the camera follow.

public GameObject player;
// ref value for smoothDamp
private float xVelocity = 0.0f;
// Update is called once per frame
void Update()
{
    // match the player x position
    Vector3 playerposition = player.transform.position;
    Vector3 cameraposition = transform.position;
    if (playerposition.x > cameraposition.x) { 
        // cameraposition.x = playerposition.x;
        cameraposition.x = Mathf.SmoothDamp(cameraposition.x, playerposition.x, ref xVelocity, 0.5f);
        transform.position = cameraposition;
    }
}

Rule #2 is a little trickier, as we don’t really know where the left edge is.  We could do all kinds of math to figure this out, casting rays and such, but we are going to do this the lazy way.

OPTION 1: (the complicated way)  In a previous semester, we included a value called “leftSideOffset” that held the distance in x units that corresponded with the left edge of the screen from the center of the camera.  Since the camera is always the same z-distance from the player, this number can be a constant.  In our update loop, we then check the offset as a bounding x-value for the player, with the following code:  

    Vector3 checkposition = transform.position;
    float leftx = gameCamera.transform.position.x - leftSideOffset;
 
    if (checkposition.x < leftx) {
        checkposition.x = leftx;
        transform.position = checkposition;
    }

OPTION 2: (the cheap way)  For this class, I have implemented a much more rudimentary system. I create an object and assign it a BoxCollider 2D. I size this to span beyond the vertical length of my camera view, and move it to the very left of the camera. Finally, I make this object a child of the Main Camera, meaning that it will follow along wherever our camera goes. This prevents our player from being able to run beyond the edge of the screen. (Once we place enemy objects, you will want to adjust your Collision Matrix in the Physics 2D panel in your Project Settings, just like we did with our 3D collisions in Astral Attackers, so that your non-player objects can pass through unimpeded.)

Part 6 – Enemies and Triggers

Now that we’re moving and jumping, let’s create some enemy objects to interact with.  We won’t worry about colliding with them right now, but let’s at least get them in the scene and behaving the way we expect them to behave (patrolling their platforms)!

We created an object similar to our player but with our Enemy sprite. We added a Circle Collider 2D, and Rigidbody 2D component to it, and created a simplified version of our character controller script to automate its movement. We use a simple boolean in our script called “faceLeft” which will indicate if our enemy is facing left or right, used that value to determine the direction (represented by -1 : 1). We then used the SpriteRenderer component to set the flipX value (which flips the horizontal orientation of the sprite itself)

To create behaviors, we will use Triggers to give our Enemy the illusion of intelligently patrolling its platform. Triggers are a variation of colliders that don’t actually collide – they simply define a volume, and that volume will create a collison-like event when another object’s collider enters it.

For our purposes, we are going to create a “turn around” box – a cube volume that our enemy will enter, register, and react by reversing direction. First, create an empty object, add a Box Collider 2D, and check the Is Trigger box. Create a tag called “TurnAround” and assign it to this box. Make this object a prefab so that we can place them throughout the level. Then we add this to the Enemy script:

private void OnTriggerEnter2D(Collider2D collision)
{
    if (collision.gameObject.tag == "TurnAround")
    {
        faceLeft = !faceLeft;
    }
    
}

Once the Enemy object enters the trigger object, it checks for the “TurnAround” tag, and if it finds one, it will invert the “faceLeft” value of the Enemy causing him to walk in the other direction.  This will only fire when the enemy first enters the volume as OnTriggerEnter2D only occurs at the first point of overlap.  You can use OnTriggerExit2D to register when the overlap has ended, or OnTriggerStay2D to confirm that an overlap is ongoing.

NOTE: Trigger’s use the OnTrigger commands, as opposed to the OnCollision commands. Unity treats these differently, so they will only apply to the corresponding setting for isTrigger. Also, because this is 2D physics, note the 2D designation at the end of each of these. OnCollisionEnter and OnCollisionEnter2D use different physics systems and are not interchangeable, so if your collisions are not registering, check that you are using the proper command.

Part 7: Pixel Perfect Camera

When working with pixel art, you may notice some tearing or flickering lines in your game. This is often due to the slight artifacts created by the camera sampling the artwork at an incorrect distance. Thankfully, Unity includes a package to help correct for this – the 2D Pixel Perfect Camera. Rather than run through all of the features here, check out the Unity Manual which does an excellent job breaking down exactly how this works.

Unity Manual: 2D Picture Perfect

CameraFollow.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class CameraFollow : MonoBehaviour
{
    public GameObject player;
    private float xVelocity;


    // Update is called once per frame
    void Update()
    {
        if (player) { 

            Vector3 playerPosition = player.transform.position;
            Vector3 cameraPosition = transform.position;

            // match the x-value
            // cameraPosition.x = playerPosition.x;

            // if the player is right of the camera midpoint
            if (playerPosition.x > cameraPosition.x)
            {
                // smoothdamp the x-value
                cameraPosition.x = Mathf.SmoothDamp(cameraPosition.x, playerPosition.x, ref xVelocity, 0.5f);

            }


            // update the camera position
            transform.position = cameraPosition;

        } 
    }
}

EnemyScript.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class EnemyScript : MonoBehaviour
{
    public float speed;
    public bool faceLeft = true;

    private Rigidbody2D rb;
    private SpriteRenderer sprite;

    // Start is called before the first frame update
    void Start()
    {
        rb = GetComponent<Rigidbody2D>();
        sprite = GetComponent<SpriteRenderer>();
    }

    // Update is called once per frame
    void Update()
    {
        /*
        if (faceLeft && sprite.flipX)
        {
            sprite.flipX = false;
        }
        else if (!faceLeft && !sprite.flipX)
        {
            sprite.flipX = true;
        }
        */

        if (faceLeft == sprite.flipX) { sprite.flipX = !sprite.flipX; }
    }

    private void FixedUpdate()
    {

    float direction = faceLeft ? -1 : 1;
        rb.velocity = new Vector2(direction * speed, rb.velocity.y);
    }

    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.gameObject.tag == "TurnAround")
        {
            faceLeft = !faceLeft; // invert faceleft
        }
    }

}

Part 1: Finishing the Collider

At the end of yesterday’s class, we had set up most of our 2D Character Controller, making modifications from a script that we had found. One aspect that we did not get to complete was to simplify the means of generating the “ground” detection.

Rather than remeasuring the collider bounds and recalculating the sizes in each fixed update, we instead created a child object that we will use as our “Ground Check” object. We add public variables to our script to hold the Transform of that child object (in order to grab the position) and a float value to measure the radius.

Next, we added a Gizmo to draw a sphere representing that ground check object so that we can see our area of effect and create the proper amount of protrusion just below the curvature of our player collider.

private void OnDrawGizmos()
{
    // Draw a yellow sphere at the ground check position
    Gizmos.color = Color.yellow;
    Gizmos.DrawWireSphere(groundCheckObject.position, colliderRadius);
}

Part 2: Sprites

“Sprite” is a term that has been used in the video game industry almost since it’s inception. In the beginning, it referred to an image of a specific size and type that could be drawn directly to the the screen without having to be processed by the CPU, and was used to improve the performance of a game. These days, the term refers to any bitmap (or image) that is used primarily as a 2D object in a game, rather than a texture or mesh object. 2D games still rely heavily on these for their characters and worlds.

Technically, our Sprite objects in Unity are still mesh objects. Unity generates a simple flat mesh shape, and applies the bitmap to it as a texture, but instead uses an optimized shader to draw this without considering many of the procedure we would include in 3D rendering. Even our text objects generate a simplified mesh and apply the font as a texture to it. For our purposes, however, we will refer to “mesh” objects as those belonging in the 3D realm, and our “sprite” object meshes simply as Sprites.

A “sprite sheet” refers to an image that contains a collection of images to be used as sprites. Sometimes these are collections of common objects or “tiles” that can be used to create a level, as we will do here, but more often you will encounter them as collections of sequential frames for animation. The reason that these sprite sheets are used is that it is far more costly to load a number of small images into memory and swap them in and out as objects in the scene than it is to have a single large image and instead adjust which coordinates of the image will be drawn in a particular frame.

For this demo, we are going to use three files as sprites:

In this case, we have:

• Our hero, a little Viking Boy (a high resolution drawing, and part of a larger sprite sheet comprised of frames of animation. I’ll be showing these next week)
• An enemy (a very small pixelated dragon, also from a sprite sheet comprised of frames of animation)
• Environment Tiles (a 128×128 sprite sheet composed of 16×16 pixelated blocks, each one intended as a “Tile” for our Tilemap)

Sprite Layering

We start by placing an instance of our Viking Boy into the Scene. You’ll notice when we do this, that we have a new Component, the Sprite Renderer. (This replaces the Mesh Renderer and Mesh components from our 3D games.) You will also notice that the default tool to move the Sprite is the Rect Tool, located to the right of the Scale button. (The hotkey for this is: Y) You can still use move/scale/rotate, but the Rect tool is easier for 2D workflows.

Our Sprite Renderer component gives us access to only a few controls that we will use. The “flip” property is useful for swapping a sprites direction without resorting to rotation or scaling tricks. The “color” property lets you set a tint for the sprite, as well as the alpha (transparency) value. This means that any sprite can be faded. There are no special shaders like what we had to use with our 3D blocks in the last assignment.

Under Additional Settings we find perhaps the most important setting, the Sorting Layer. Unity’s sprite rendering works a little different from what you have experienced up to this point, in that it often doesn’t matter how close or far a sprite is from the camera – the order that sprites are drawn in (and therefore the determination of which sprite will be in front of the other) comes down to a series of comparisons, the most important of which is the Sorting Layer.

Here, we have our Viking Boy on the “Default” layer, but if we access the dropdown and click “Add Sorting Layer…” we go to our Tags & Layers panel and can create new layers. The order of these layers determines which will draw in front of which. Each layer on the list will draw in front of the layer before it, so the objects set to the bottom layer (here we created “Foreground”) will draw in front of everything else.

Also in our Additional Settings, you can see the Order within Layer setting. This takes a numerical value, and when two objects in the same layer overlap, the object with the higher number will render in front of the lower numbered object. (If objects are equal after this, distance to camera is finally considered)

Importing and Editing Sprite Sheets

Sprites and sprite sheets come into our game the same way as the rest of our resources – we import them using Assets> Import New Assets…

Once imported, you will want to select it so that you can make edits to the Import Settings. Remember, these assets are external to your editor. Nothing you do here will change the contents of the sprite sheet, only how the Editor interprets it. Also remember that once you have made changes you will need to confirm the changes by clicking the Apply button at the bottom of the panel.

In your Import Settings, chance the Texture Type to “Sprite (2D and UI”. This tells Unity a bit about how you intend to use the file.  If your sprite is a single image, then the default Sprite Mode setting of “Single” will work for you. However, if this is a sprite sheet, change this to “Multiple”, which lets unity know to expect more than one object will come out of this texture atlas.   Your Pixels Per Unit setting serves as the scale for how big your sprites should be if you drop them into the scene (of course you can always scale them to meet your preference). By default this value is 100 pixels to a unit. This is great for our Viking Boy as this will make him about 2 units high, but our Environment object is only using 16×16 pixels per sprite. We change this value to “16” so that each block will be 1 unit by 1 unit.

Next, we want to correct the “fuzzy” look of our smaller objects. If we post this to our level, we see the edges are blurry. This is because Unity is “sampling” the image to visualize it at a higher resolution. This is great for things like photorealistic textures, but terrible for our pixel art. To correct this, we go to the Advanced Settings and set the Filter Mode to “Point (no filter)”. This setting controls how to handle scaling images. Using “point” tells the editor that we want the images sharp edges to be preserved.

If you are using pixel art, and are still getting images that don’t look quite right (i.e. the edges are sharp, but the sprites themselves are blocky or the colors somehow.. wrong) you might be having issues with the “compression” settings. Unity automatically puts compression on all images that it imports, but for pixel art this can often create a degraded look, and the gains are super minimal because the source images are so small to begin with. To correct this, look at the Default settings at the bottom of Import Settings and set your Compression to “None”. This will remove any adjustment and use your source material as-is.

Now it is time to split the sprites, which we will do with the Sprite Editor, which you access from the sprite’s Import Settings.

NOTE: If you want to use the Sprite Editor with the 3D template, you may need to install the 2D Sprite package, which you can do from the Package Manager. If you are starting from a 2D template, this package is already activated.

For our Environment sprite sheet, go to the Slice dropdown button at the top and select Grid by Cell Count. This will let you define the how the image should be split into pieces. For this object, we want to set the count to 8 columns and 8 rows. Keep the pivot at “Center” (you’ll want this for proper placement in the Tilemap.) Once you are ready, hit slice. You will see that small boxes have been drawn for these, but also that any empty square has been removed. If you update your sprite sheet with more sprites, you may need to run the Sprite Editor again to include the new content.

If you click one of these boxes, you will get a Rect controller, and call up information about the sprite itself. You can adjust values, or change the name of the individual sprite.

When you have completed your set-up & edits, click the “Apply” button in the Sprite Editor window, and then also the “Apply” button in the Import Settings. Now in the Asset window your sprite sheet will have a small arrow in a circle next to it. Clicking on this arrow will expand the list to show the individual sprites contained within this object.

Part 3: Tilemaps

Now that we have set up our sprites, it is time to build a level. While we could place individual sprites and colliders throughout the environment, Unity gives us an excellent tool for designing sprite content – the Tilemap. The Tilemap is a system of components which handles Tile assets and allows you to place them in your scene.

To create a new Tilemap, go to Create > 2D Object > Tilemap. This will also generate a Grid object, and your Tilemap will be a child of this object. (You can create more than one Tilemap, each will become a child of this Grid). This parent object has a Grid component within which you can set the size, spacing, and orientation of the Grid.

You will see this grid reflected in the Scene window…

The Tilemap object will contain the Tilemap Component and the Tilemap Renderer component. The most important setting to notice here is the Sorting Layer setting in the Tilemap Renderer. For our game, we will set up multiple Tilemaps under the same grid, and set them to different sorting layers to create foreground and background objects.

Once your Tilemap is created, you will want to create a Tile Palette – a collection of tiled sprites that you can use to populate the grid cells on your Tilemap. Access this by going to Window > 2D > Tile Palette. Once here, select “Create New Palette…” and give it a location and a name. Then you can drag sprites into this window which will create Tiles for each sprite. (You will see a window asking where you want to save these in your Asset directory. I recommend creating a new folder, as these can get pretty numerous if you are working with even a modestly sized sprite sheet.)

The Tile Palette window features a list of tools at the top. These are:

• Select – allows you to select one or more grid cells
• Move – allows you to relocate a tile (you must first select the tile)
• Paint – select a palette tile or tiles and use this to paint that selection onto your scene’s tilemap.
• Box Fill – fill an area of your tilemap with the selected tile(s) from your palette
• Pick – click on a tile to change your active brush selection to that type of tile
• Erase – click on a tile to remove it
• Flood Fill – fill a large area with the active tile(s)

Below the tile tools is the Active Tilemap setting. If you have multiple tilemaps (which is common with layering) you will want to make sure that you have the correct Tilemap selected before you paint. For this reason, it is recommended to give each of your Tilemaps a unique name that identifies their purpose (such as Foreground, Background, etc)

SideScrollerController.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

/*

• SideScrollerController – created for UGE Summer 23
• Based on Sharp Coder 2D Controller (https://sharpcoderblog.com/blog/2d-platformer-character-controller)
  */

public class SideScrollerController : MonoBehaviour
{
// Player Movement Variables
public float maxSpeed = 3.4f;
public float jumpHeight = 6.5f;
public float gravityScale = 1.5f;
float moveDirection = 0;
public bool isGrounded = true;
public bool facingRight = true;

public LayerMask groundLayer;

public Transform groundCheckObject;
public float colliderRadius = 0.5f;

// components
Rigidbody2D r2d;
CapsuleCollider2D mainCollider;
// Transform t;

// Start is called before the first frame update
void Start()
{
    // set the component variables
    r2d = GetComponent<Rigidbody2D>();
    mainCollider = GetComponent<CapsuleCollider2D>();

    // setting some component properties
    r2d.freezeRotation = true;
    r2d.collisionDetectionMode = CollisionDetectionMode2D.Continuous;
    r2d.gravityScale = gravityScale;

    // set the initial facing right value
    facingRight = transform.localScale.x > 0;
}

// Update is called once per frame
void Update()
{

    // Movement controls
    moveDirection = Input.GetAxisRaw("Horizontal");

    // TO-DO:  Implement Change Facing Direction

    if (moveDirection > 0 && !facingRight)
    {
        facingRight = true;
        transform.localScale = new Vector3(Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
    }
    if (moveDirection < 0 && facingRight)
    {
        facingRight = false;
        transform.localScale = new Vector3(-Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
    }




    // Jumping
    if (Input.GetButtonDown("Jump") && isGrounded){
        r2d.velocity = new Vector2(r2d.velocity.x, jumpHeight);
    }


}

void FixedUpdate()
{
    // Apply movement velocity
    r2d.velocity = new Vector2((moveDirection) * maxSpeed, r2d.velocity.y);

    // Check if player is grounded
    Collider2D[] colliders = Physics2D.OverlapCircleAll(groundCheckObject.position, colliderRadius, groundLayer);

    // check for a grounding collider
    isGrounded = colliders.Length > 0 ? true : false;

}

private void OnDrawGizmos()
{
    // Draw a yellow sphere at the ground check position
    Gizmos.color = Color.yellow;
    Gizmos.DrawWireSphere(groundCheckObject.position, colliderRadius);
}

}

Part 1: 2D Character Controller Setup

At their core, Character Controllers are rather simple, but incredibly important. They manage the important task of moving our character through our levels based upon our input, running, jumping, and not falling through the floor. And by providing situational information such as the answer to “are we on the ground?” which is a critical question when figuring out whether or not we can “jump”.

While Unity provides a 3D Character Controller component for their games, they have yet to release their own 2D controller As such, there are a significant number of controllers that others have created and published. Today, we looked at a lovely little controller script from the Sharp Coder blog that I prefer – it’s simple, straightforward, and uses 2D Physics to handle gravity and collisions. We incorporated much of their code, with some modifications that simplify our process.

You can find their blog post and code here: Sharp Code – Unity 2D Character Controller

The first neat feature about this script is the RequireComponent instruction at the head of the file. This tells the Unity Editor that this script requires these components to be attached to the same object (in this case, Rigidbody2D and CapsuleCollider2D). If you attach this script to an object without these components, they will automatically be added.

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

The next feature that I appreciate about this particular controller is that they modify the rigidbody properties during the Start( ) function, to ensure that the right settings are in place. In this case, they make sure that Rigidbody2D.freezeRotation is set to true (so our character doesn’t roll over) and that the collision detection mode is set to “Continuous” rather than the default setting of “Discrete”. Continuous detection is going to be the preferred method for your player object and probably your enemy objects – you want those collisions running all the time. Finally, it set the rigidbody’s gravityScale to a value defined by this script. This is important because it will affect the speed of your vertical movement.

        r2d.freezeRotation = true;
        r2d.collisionDetectionMode = CollisionDetectionMode2D.Continuous;
        r2d.gravityScale = gravityScale;

We left out all references to camera control from the script, as we will be making our own custom camera controller later in this lesson.

Part 2: Character Controller Inputs

The Update( ) method is used to fetch our user Inputs, which currently consist of moving horizontally, and jumping (which is a vertical motion). We modify the ridigbody’s velocity, which is expressed as a Vector2, in order to move the controller in that direction.

Jumping can only occur when we are “grounded” (more on that in a minute) and simply replaces the velocity’s y-value with whatever we set out “jumpHeight” value to be.

Horizontal movement is a little more complicated. Sharp Coder’s features a lot of logic to determine whether how to set our “moveDirection”.

        // Movement controls
        if ((Input.GetKey(KeyCode.A) || Input.GetKey(KeyCode.D)) && (isGrounded || Mathf.Abs(r2d.velocity.x) > 0.01f))
        {
            moveDirection = Input.GetKey(KeyCode.A) ? -1 : 1;
        }
        else
        {
            if (isGrounded || r2d.velocity.magnitude < 0.01f)
            {
                moveDirection = 0;
            }
        }

This version looks to see if we are pressing the A or D key, AND if we are either grounded, or already moving horizontally (by testing the absolute of the velocity’s x-value). This means that we can move while on the ground, or can adjust our movement in air if we were already moving horizontally in air. Whether or not you can control your character’s horizontal movement while in-air makes for a heated debate amongst designers. Also, what’s up with this line?

moveDirection = Input.GetKey(KeyCode.A) ? -1 : 1;

This is what is known as a “ternary operator”. It’s a conditional that works like a simplified “if” conditional. It’s structure is something = statement ? <true value> : <false value> Here, moveDirection can be set to one of two values, based on “is the A key is pressed”. If true, a value of -1 is returned, if false, 1 is returned.

The else on the original statement says if we are not pressing A or D, then our move direction should be 0. Doesn’t this sound like Input.GetAxisRaw? It sure does, so that’s what we use instead.

// Movement controls
moveDirection = Input.GetAxisRaw("Horizontal");

Part 3: Actual Making things Move

We used the Update( ) loop to take our settings, but for actually *moving* our object, we want to take advantage of FixedUpdate( ). FixedUpdate is called at a steady, regular interval (usually 50 times per second) and is the preferred method for working with Rigidbodies / Physics. Update is frame dependent – and that framerate will fluctuate, which is why we have to include a “deltaTime” measurement when creating motion. With FixedUpdate( ), the interval is the same every time.

Towards the end of Sharp Coder’s FixedUpdate( ) function, we see the code that sets the velocity value of our rigid body.

// Apply movement velocity
r2d.velocity = new Vector2((moveDirection) * maxSpeed, r2d.velocity.y);

This is super-simple – take the horizontal movement direction we have designated, multiply it by the max speed and place it in the x-value. We preserve the y-value of the velocity, as this will be set elsewhere through a “jump”, react to the -y forces of gravity, or return to 0 in the event that we are on a surface.

Part 4: Are we on the ground?

The beginning of the original FixedUpdate( ) function contains a considerable amount of logic to identify a point in space that exists inside of our player collider, and the width of the collider itself. The reason this information is important is that it will be used to create a custom collision check to see if our collider is indeed touching something. The logic goes something like this:

1. Find a point just about the radius point of the lower arc on the capsule.
2. Create a circle that will reach just a little lower than that arc, and check within that circle for any colliders.
3. Take the list of returned colliders and check to see if one of those is NOT the player collider.
4. If you find a non-player collider, you’re on the ground! If not, isGrounded remains false.

This method certainly does work, but I have a few issues with it. First, it just assumes that ANY collider that it detects is automatically the ground – but later we will use colliders with the “trigger” function that our player object will pass through, but this Physics2D.OverlapCircleAll will definitely detect. We saw before how we could use the layer matrix in Physics settings to “mask” layers from one another (like objects in Enemy layers ignoring one another). Since we only care if we hit colliders that represent the ground, why don’t we just use layers to check specifically for that?

In order to do this, I can use the third parameter of Physics2D.OverlapCircleAll( ) – a integer named layerMask. The layer mask is what is known as a “bitmask” – a way of using and manipulating the bits in a byte of information, otherwise known as a bitwise operation. These bits are set on or off, and used as a way to store information as a number. If you look at the Layer panel, you’ll notice that we only have slots in Layer 0-31, or 32 total possible values that can be set to “on” or “off”. We have a data type that is made of 32 bits – the integer. And so there is a single numeric value that represents the over 4 million possible combinations of on-off in those 32 slots. Sound complicated? It is!

Thankfully we don’t have to worry about the math for this, because Unity has already built this into our editor, with the LayerMask type. You’ve seen these variables before, in the Camera Mask settings, which determine whether a camera can view a layer or not. We declare a variable to set in the editor like so:

public LayerMask groundLayer;

This gives us a dropdown that we can use to set the layers we are interested in looking at. I’ve created a layer named “Ground”, and put all of our environment objects on that layer.

Now in FixedUpdate( ) we modify that custom physics call to include the layerMask so that it only returns colliders on the layers that we defined in the editor, which in this case is “Ground” and “Enemy”.

// Check if player is grounded
Collider2D[] colliders = Physics2D.OverlapCircleAll(groundCheckPos, colliderRadius, groundLayer);
        

Now rather than sort through all of the colliders, I can simply check to see if there ARE any colliders returned! I set my grounded variable equal to false, then if there is length, I turn it to true.

//Check if any of the overlapping colliders are not player collider, if so, set isGrounded to true
isGrounded = false;

if (colliders.Length > 0) { isGrounded = true; }

Of course, if I wanted to be fancy, I could use our ternary operator to express these in one line.

isGrounded = colliders.Length > 0 ? true : false;

Tomorrow we will finish our controller by simplifying the physics check, and generating some helpful gizmos to visualize their range of effect.

SideScrollerController.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

/*

• SideScrollerController – created for UGE Summer 23
• Based on Sharp Coder 2D Controller (https://sharpcoderblog.com/blog/2d-platformer-character-controller)
  */

public class SideScrollerController : MonoBehaviour
{
// Player Movement Variables
public float maxSpeed = 3.4f;
public float jumpHeight = 6.5f;
public float gravityScale = 1.5f;
float moveDirection = 0;
public bool isGrounded = true;
public bool facingRight = true;

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
[RequireComponent(typeof(CapsuleCollider2D))]

/*
 *  SideScrollerController - created for UGE Summer 23
 *  Based on Sharp Coder 2D Controller (https://sharpcoderblog.com/blog/2d-platformer-character-controller)
 */

public class SideScrollerController : MonoBehaviour
{
    // Player Movement Variables
    public float maxSpeed = 3.4f;
    public float jumpHeight = 6.5f;
    public float gravityScale = 1.5f;
    float moveDirection = 0;
    public bool isGrounded = true;
    public bool facingRight = true;

    public LayerMask groundLayer;


    // components
    Rigidbody2D r2d;
    CapsuleCollider2D mainCollider;
    // Transform t;

    // Start is called before the first frame update
    void Start()
    {
        // set the component variables
        r2d = GetComponent<Rigidbody2D>();
        mainCollider = GetComponent<CapsuleCollider2D>();

        // setting some component properties
        r2d.freezeRotation = true;
        r2d.collisionDetectionMode = CollisionDetectionMode2D.Continuous;
        r2d.gravityScale = gravityScale;

        // set the initial facing right value
        facingRight = transform.localScale.x > 0;
    }

    // Update is called once per frame
    void Update()
    {

        // Movement controls
        moveDirection = Input.GetAxisRaw("Horizontal");

        // TO-DO:  Implement Change Facing Direction

        if (moveDirection > 0 && !facingRight)
        {
            facingRight = true;
            transform.localScale = new Vector3(Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }
        if (moveDirection < 0 && facingRight)
        {
            facingRight = false;
            transform.localScale = new Vector3(-Mathf.Abs(transform.localScale.x), transform.localScale.y, transform.localScale.z);
        }




        // Jumping
        if (Input.GetButtonDown("Jump") && isGrounded){
            r2d.velocity = new Vector2(r2d.velocity.x, jumpHeight);
        }


    }

    void FixedUpdate()
    {
        Bounds colliderBounds = mainCollider.bounds;
        float colliderRadius = mainCollider.size.x * 0.4f * Mathf.Abs(transform.localScale.x);
        Vector3 groundCheckPos = colliderBounds.min + new Vector3(colliderBounds.size.x * 0.5f, colliderRadius * 0.9f, 0);
        
        
        
        // Check if player is grounded
        Collider2D[] colliders = Physics2D.OverlapCircleAll(groundCheckPos, colliderRadius, groundLayer);
        
        
        
        //Check if any of the overlapping colliders are not player collider, if so, set isGrounded to true
        isGrounded = false;

        if (colliders.Length > 0) { isGrounded = true; }

        // Apply movement velocity
        r2d.velocity = new Vector2((moveDirection) * maxSpeed, r2d.velocity.y);

        // Simple debug
        Debug.DrawLine(groundCheckPos, groundCheckPos - new Vector3(0, colliderRadius, 0), isGrounded ? Color.green : Color.red);
        Debug.DrawLine(groundCheckPos, groundCheckPos - new Vector3(colliderRadius, 0, 0), isGrounded ? Color.green : Color.red);
    }

}

}

Part 1: 2D Basics

An important distinction to make about building a 2D game in Unity is that it is all the same Unity game engine. There are 2D and 3D capabilities built into the engine, but up to now we have dealt exclusively in the 3D realm. To make development (and the file-size of a project) efficient, many of the packages that are specific to 2D are turned off in the 3D templates. The best way for us to activate these packages is to launch a new project, but use the built-in 2D Template instead.

When we launch this, our editor will look mostly the same, with a few small, but significant differences. First, you will notice that our Scene window is set to “2D” mode, with our camera facing the XY plane.

You will also notice that our scene only include a camera – by default there is no directional light, because we will be using sprite rendering in this project instead. Also, our Main Camera is a little different – our Projection is set to Orthographic, and there is no Skybox. (There can be a skybox, but none is included by default, so the Clear Flags option falls back to the Solid Color designation.

While the 2D / Orthographic camera can be used to render 3D content – remember, we did this with our Pong game – the primary method of drawing objects on the screen for 2D content is to use Sprites.

“Sprite” is a term that has been used in the video game industry almost since it’s inception. In the beginning, it referred to an image of a specific size and type that could be drawn directly to the the screen without having to be processed by the CPU, and was used to improve the performance of a game. These days, the term refers to any bitmap (or image) that is used primarily as a 2D object in a game.

For now, we will use Unity’s built-in sprites which are simple shapes that we can use to explore layers and physics.

Part 2: Sorting Layers

Sprite rendering works differently than 3D rendering – there are no polygons to receive and reflect light, and so the images used for sprites are simply presented (and rendered) as-is. The Sprite Renderer has different properties than the Mesh Renderer that we have previously used, including two very important ones – the Sorting Layer and the Order in Layer, and Unity’s rendering engine uses these values to determine which object to draw on top of another.

The Sorting Layer is given top priority in rendering. The higher the Sorting Layer’s index (as defined in the Tags & Layers panel that we’ve used before), the closer to the camera this layer will render, regardless of other attributes like distance (unless the sprite is behind the camera, and thus outside of the view frustrum). These are especially useful as we set up rules for our tilemaps, so that we can generate proper layers without having to worry about actual z-depths.

The next level of sorting priority when drawing is the Order in Layer setting. Overlapping objects that are contained within the same layer will use this numeric value to determine which should draw on top of the other – the higher number sprite drawing over top of the lower numbered sprite. (These numbers can also be negative, and these values can be changed programmatically if need be).

In the event that overlapping sprites do not have different layers or layer orders, then there are a few other comparisons such as distance from camera (as determined by the pivot point). But if you have overlapping sprites, it’s best to use these systems.

Part 3: 2D Physics & a Top-Down Controller

Unity’s 2D physics system relies on a different physics library than the 3D system, and so the sprites that we create will use a separate set of components when operating in the 2D physics world. There is a Rigidbody2D type component that performs the same task as the 3D Rigidbody, but only operates on the XY plane with the only possible rotation happening on the Z axis, towards the camera).

There are also a set of 2D Colliders which work with this system, including a BoxCollider2D, a CircleCollider2D and a CapsuleCollider2D. It is important to note that collision detection also relies upon its own method, OnCollisionEnter2D(Collision2D collision).

As a demo today, we built a simple environment using multiple square sprites (stretched to form rectangles), plus a few sprites with the Rigidbody controller attached. We used the Rigidbody2D.MovePosition( ) function to move our sprite towards a location that we defined as the current position + a directional offset (using the Input.GetAxis( ) for horizontal and vertical dimensions).

TopDownCharacterController.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class TopDownCharacterController : MonoBehaviour
{
    public float speed = 1.0f;

    private Rigidbody2D rb;
    private Vector2 direction;


    // Start is called before the first frame update
    void Start()
    {
        rb = GetComponent<Rigidbody2D>(); // get the rigidbody for this object
        direction = new Vector2();
    }

    // Update is called once per frame
    void Update()
    {
        // get the movement inputs
        direction.x = Input.GetAxisRaw("Horizontal");
        direction.y = Input.GetAxisRaw("Vertical");

    }

    private void FixedUpdate()
    {
        if (rb)
        {
            // move the controller
            rb.MovePosition(rb.position + (direction.normalized * speed * Time.fixedDeltaTime));
        } else
        {
            Debug.Log("Missing a Rigidbody 2D component");
        }
    }
}