For our first goal, to allow the player to move sideways, forward and backward. The approach chosen is to accumulate inputs from normal frames, and apply them on the physics frames.

Both GetInputs() and AcumulateDelocation() are called on Update, and OperatePhysicsMovement() is called on FixedUpdate. When a physics update happen, all inputs since the last one are operated. This allows us avoid dealing with physics out of place. This script operates on a gameobject that has a rigidbody, and it demands one in order to add itself to the object.

The second goal is a little more tricky than it looks.

What we want is :

• The horizontal movement of the mouse should delocate the Camera AND the player's front, rotating around the up -axis.
• The vertical movement of the mouse should delocate just the Camera, rotating it around its own right-axis.
• The camera should not be allowed to rotate 360 degrees around its own right-axis.
• There player should not be hidden behind objects in a way the camera can't see him.
• The Camera should not rely on player's rotation, it must always adjust itself, keeping it's “target”, and preserving those 4 rules.

One thing that took me more time than it should was that i tried to keep the camera as a child object of our player, so it could follow it easily. However, since im not entirely sure our player won't be able to rotate when walking through slopes, i decided to keep it as a separate object.

The second thing was that i was trying to limit the up and down rotation of the camera by rotating the camera exactly the amount required to reach it's limit when it was close to it. This approach end up in some complex conditionals that end up confining the camera on the limit because of some numeral instabilities lol. I've given up on doing this so “flawlessly" and decided to just reroll rotations that extrapolate the limit. This approach should not cause problems since the camera speed won't hit absurd levels.

A important thing was also added : locking and hiding of the cursor in the center of the screen, as well as temporary crosshair as a child of the camera.

Now with more details, the code :

The update was divided in 5 steps.

Step 1: Gets the mouse inputs, normalize them and apply our camera speed to it ( proportionally to the frame duration),

Step 2: Defines where the camera should point at, based on its target and a vertical delocation predefined. Move the camera along the line connecting this postion and the camera current position, by a maximum distance or till it hits an object that repels it ( this definition is done by picking specific layers on the editor ). IMPORTANT : a little bit of offset must be applied so the camera doesn't end up exactly at the colision point.

Step 3: Rotates the camera around the axis defined by the target position, and the world up-axis. and align the player with this new “forward”. Notice that for now the player's forward is defined by the projection of the camera forward on the XZ plane, but in the future this may need to be adjusted if the player interacts with slopes, as described earlier ( when talking about parenting the camera to the player ).

Step 4: Rotates the camera around the axis defined by the target position and the camera right-axis, but before doing so, creates a backup of the current position and rotation. After applying this rotation, verify the angle between the camera's forward and it's projection on the XZ plane, if it exceeds our predefined limit, reverts the rotation using our backup.

Step 5: Updates the camera orientation in order to properly look at its target. This step only exists for safety measures, since there is no other moment in the code where this is done, but it's very plausible.

And thats it for our first update =)

Upcoming : Jumping action and baby steps with animations.