VG1, Quest 9 - Adventure, PT1

Scene Clean-up

Our adventure genre prototype has a very similar foundation as the SplitScreen assignment. We will repeat a few steps from the prior assignment in new files, so that the SplitScreen scene will still work even after you finish this assignment. Begin by DUPLICATING the SplitScreen scene and renaming the new copy Adventure.

Be sure that all new edits take place in the Adventure scene.

This assignment will be singleplayer. Remove the SmoothDamp camera and its target player by deleting MainCamera and Player.

Allow Camera2 to take up the whole screen.

Fix the zoom level by changing the Orthographic Size on the Virtual Camera.

Because our camera is now too big for our level design, remove the Virtual Camera Confiner.

Reset the tint color of the player to the default white.

To avoid breaking the SplitScreen assignment, remove the PlayerController component. We will replace it with a different file.

Right-click Player2 in the hierarchy and unpack the prefab so we are no longer hooked up to the SplitScreen prefab.

Create a new PlayerController in the /Assets/Code/Adventure/ folder. Attach this to the Player object in the Adventure scene.

We will use the Adventure namespace. At present, the code is identical to what we wrote in the prior assignment, but now we can add more to it without breaking the SplitScreen scene.

Configure the player's controls and movement speed.

Playtest with this configuration ensure you have a single player that is able to move with the camera still following.

Animator and Animations

Store all of your Adventure Player animations in /Assets/Animations/Link/

Attach an Animator Component to the Player and open the Animation Window.

Create an IdleUp animation using frame 8 at a Sample rate of 1 frames per second.

Create an IdleDown animation using frame 4 at a Sample rate of 1 frames per second.

Create an IdleLeft animation using frame 10 at a Sample rate of 1 frames per second.

Create an IdleRight animation using frame 6 at a Sample rate of 1 frames per second.

Create a WalkUp animation using frames 8 and 9 at a Sample rate of 5 frames per second.

Create a WalkDown animation using frames 4 and 5 at a Sample rate of 5 frames per second.

Create a WalkLeft animation using frames 10 and 11 at a Sample rate of 5 frames per second.

Create a WalkRight animation using frames 6 and 7 at a Sample rate of 5 frames per second.

Create an AttackUp animation using frame 30 at a Sample rate of 1 frames per second.

Create an AttackDown animation using frame 26 at a Sample rate of 1 frames per second.

Create an AttackLeft animation using frame 35 at a Sample rate of 1 frames per second.

Create an AttackRight animation using frame 28 at a Sample rate of 1 frames per second.

With all these animations, the Animator screen is full of a lot of possibilities and would actually be very unwieldy if you only used transition techniques from previous projects.

Animator Parameters

Set up the following four Animator Parameters:

• movementX (float)
• movementY (float)
• speed (float)
• attack (trigger)

To reference the Animator Component from the PlayerController, add an outlet and fill the reference during the Start event.

We previously wrote our physics interactions are in the FixedUpdate loop because it is synchronized with the physics engine. Momentary input interactions such as our sword slash should be handled in the Update event with the animations or some inputs may be dropped.

Blend Trees

This project would benefit from a new Animation technique known as Blend States because our many animations fit into distinct categories (idle, walk, and attack) and directions (up, down, left, and right).

In chart form, our many animations are just the intersection of these categories and directions. Recognizing this pattern allows us to drastically simplify our animation logic rather than creating a tangled web of transitions.

Our Categories will become 3 "Blend States" that blend 4 directional "motions".

First, we will actually delete all 12 animations from the Animator window. (This simply removes then from the flow chart. The animations we did in prior steps still exist in the project files.) Then right-click to add a New Blend Tree.

Click the new Blend Tree and in the Inspector, rename it "Idle".

Double-click the Blend Tree to see its details. Notice how the Animator portrays navigation and hierarchy.

Click the Blend Tree and view the details in the Inspector.

First, set Blend Type to "2D Simple Directional". You can use parameters to specify the amount that you blend Animations/Motions together. If you use two parameters, you can create a two-dimensional blend. We will use the two parameters of "movementX" and "movementY" in combination to extrapolate direction.

With these settings, any combination of X and Y movement values will activate the appropriate Up, Down, Left, or Right animation

Return to the Base Layer and copy and paste the "Idle" state twice. Rename one to "Walk" and rename the other to "Attack". All 3 categories will use similar directional blending.

Update the "Walk" blend tree to use walk animations.

Update the "Attack" blend tree to use attack animations.

Blend Tree Transitions

With all the direction animations categorized into different Blend Trees, transitioning between them works the same as prior animator techniques. Set "Idle" as the Default Layer State and create transitions in both directions between the three states. There should be six transitions in total.

Implement the following settings for each Animator Transition. Be precise and make sure every field matches. Not all transitions are the same.

Idle → Walk

Walk → Idle

Idle → Attack

Attack → Idle

Walk → Attack

Attack → Walk

If you playtest the game now:

• You should be able to walk in all four directions and the character will appropriately face that direction.
• The player will switch between idle and walk animations depending on whether the character is moving.
• Pushing space bar will cause the player to stick out the sword and, after a 0.25 second delay, retract the sword.

There is one major bug at the moment: When you attack, the player sprite moves out of alignment because all the sprites are set to use their center as the pivot.

Notice how our character is pushed outside of his circle collider because of the mis-aligned sprite.

Fix Pivot Points

Spritesheet pivot points are changed back in the Sprite Editor. Select the zelda image file in /Assets/Textures/Adventure/ and click the "Sprite Editor" button from the Inspector.

For each sprite that you used for AttackUp, AttackDown, AttackLeft, and AttackRight, set the Pivot to Custom and use the value shown in the matching image. These values realign the attack sprite to keep the pivot point in the same place as the corresponding Idle direction sprite.

Be sure to apply any changes when asked.

Check that when Link attacks, the sword is shown stabbing outward rather than Link's character being shoved back.

Save and Test

Playtest to ensure all interactions work as expected and that the addition of any new features hasn’t broken any earlier interactions.

Submit Assignment

SAVE any open files or scenes.

Submit your assignment for grading following the instructions supplied for your particular classroom.