// Puzzle
// BOSS (work in progress)
Tutorial Deisgn
Switching between cameras, using a special swap camera, and combining these mechanics can be a lot to take in at once. That’s why the first few levels serve as a tutorial, breaking down the core concepts:
-
Switch cameras to navigate the space.
-
Use the special camera to swap the positions of blue objects.
-
The swap only works when both blue objects are visible in the special camera's view.
These foundational lessons prepare players for the more complex puzzles ahead.
Tutorial - Navigating
First Design - All cameras in a sequence are looking at the same room
What works:
The player has no trouble associating each camera view and constructing a mental map
What doesn't work:
Lacking variation
Each camera looks at the room from different angles, even though the shape of the rooms could vary, the experience long term feels flat and static.

Second Design - There are more than 1 room in each camera sequence
What works:
Multiple rooms could be connected/disconnected, it gets more challenging to construct a mental map
Opens up design possibility
What doesn't work:
Could be very confusing at first
The views lacked visual anchors / spatial references, the player gets disoriented
If the player switches a camera but don't see the player character with in the new view, they immediately gets confused about the space

Third Design / Modification - There are more than 1 room in each camera sequence, with some visual anchors
Successfully mitigated spatial confusion, but he lack of variation in visual anchor / spatial references would still confused the player from time to time
The visual anchor is a good design direction, but I need something more unifying, rewarding to help guide the player



Last Significant Modification - Adding a guidance water ball
A companion water ball that flies from room too room. The flying path is triggered by the player when they get to certain check points
The player is still navigating through sequence of cameras but with the help of this water ball - a unique element that is visible in most of the camera views, the player could construct a mental map more easily while still be challenged and reward
Level 1
The ball travels from Room 1, through the middle corridor, to Room 2
In a straight line
The ball lands at the entrance of Room 2
The pathing of the ball is the designed critical path for the player.



Level 2
The water ball flies over an obstacle. The pathing of the water ball is not the designed critical path. Player must find other way to reach the ball. The game prompts the player with instructions on how to switch between cameras again. Player needs to find an alternative path to get to the water ball.




Level 3
The water ball flies over an obstacle. The pathing of the water ball is not the designed critical path. Player must find other way to reach the ball. In addition to the water ball flying over an obstacle, the camera also breaks the 180 rule. There are visual anchors in the level to aid the player to mentally map out the space.




Tutorial - Swap
Conditions to SWAP -
Both the water ball and the swappable block are visible to the camera
The water ball is not being held by the player character

Swap Tutorial Level 1
The goal of this room is to teach: The water ball and special blocks can swap positions
I've minimized the amount of actions player can take in the room. Player can walk around, and swap, that's it.
Swap Tutorial Level 1
The goal of this room is to teach:
The player can move the water ball around, which would give the player full control over where they want the swappable block to be.

Character Controller
The Design Problem
There are many instances in the game where the player need to either:
maintain walking in a straight line after a camera switch, and
slightly maneuver the direction after a camera switch
In the early version of the game, the forward vector of the player character would immediately update immediately after camera switches.
Imagine two cameras facing each other. Let's say the player is walking away from camera one, and they decide to switch to camera two. The player forward camera would immediately switch to the forward vector of the new camera.
The gif below demonstrates the issue.
It's not a severe problem, the game would still be playable without improving the player controller.
But the fluidity of the game feel would be compromised if I don't address it and find a clever solution.

My Solution
The first step to solve this issue is to identify when exactly does the player forward vector need to be updated:
1. If the player character is not moving, and the camera is switched, then the game should immediately update the player forward vector
2. If the player switch to a new camera while the player character is moving
a. if the player character is not turning, maintain the old forward vector
b. if the player character is turning, the game should update the forward vector
CameraForward
The forward vector of each camera, this is the vector that will become the forward vector of the player character depending on which camera the player is looking at
PlayerForward
This vector determines which direction is forward with respect to the camera position.
StickDirection
This is the input vector. This vector gets translated into movement based on the PlayerForward vector.


When the player switches to a new camera, and the player character is moving, the game starts to check if the dot product of the stickDirection and playerForward exceeds a threshold.
If the dot product exceeds the threshold, then the game would lerp the old playerForward vector to the new cameraForward vector.

Team
Director: Robert Li
Engineer: Robert Li
Designers: Nicolas, Yiyi, JC, Jaehyuk
Composer: Tilkey
3D Art & Tech Art: Luciano, Tim
2D Art: Ink Sun
Animation: Luciano