Movement mechanics

The first part of the game I wanted to finish was the movement mechanics. I knew I wanted the controls to feel "floaty", but also to self-correct so the player won't continue to drift in one direction forever. To do this I initially implemented movement by adding force to a RigidBody, but that caused problems when strafing was introduced - the RigidBody would keep its momentum when coming out of strafe causing a constant force to be applied in one direction. To fix this I switched to calculating the physics manually by setting a target velocity based on the user's input and lerping the player's actual velocity with the target velocity. The calculated velocity is then added to the player's position every frame. A RigidBody is still used for collision detection.

Strafing took a while to figure out - I knew the player needed to maintain a constant distance from the target, but I also wanted the player to be able to change their distance from the target as well. To make this work I added a global variable that keeps track of the player's distance to the target while strafing. When strafing, the position the player would move to if not strafing is first calculated, and then the player is moved to the point closest to that position on a sphere with a radius of the current distance to the target. The camera and player's body are then rotated to face the target. After this, the distance to the target can be changed and the player will start moving to this new distance on the next frame.

The camera situation took some creativity to implement as well. I wanted the player to have limited control over the camera while strafing but for the camera to still "follow" the target. This necessitated tying the camera to a chain of three parents - CameraBase, CameraPivot, CameraElevation, and then the camera, in order of parent to child. When not strafing, only CameraPivot and CameraElevation are used. CameraPivot only rotates around the y axis and CameraElevation around the x axis. It is necessary to use two different transforms here as otherwise the rotation around the y axis will be applied last, causing horizontal camera movements at an elevation to orbit around the player rather than maintain the same height.

CameraBase is used when strafing - it is made to look at the targeted object while CameraPivot and CameraElevation now act as offsets. The offsets can be reset to zero and the target recentered by pressing a button.

The final piece of the puzzle was getting the target object centered in the player's crosshairs. Because the three camera transforms are close to the player's origin but the camera itself is offset to the player's right, the targeted object would be to the left of the crosshairs when centered. The optimal solution here would be to find the line tangent to the sphere centered on the three transforms with radius equal to the camera's x offset from the origin, and which goes through the target objects position. This would allow the exact angle to offset CameraBase's rotation to the left to be found, but it also involves a lot of math. Instead I used a shortcut - have CameraBase point to the location the same offset distance to the left of the object. The difference is so small that it doesn't matter.