You're describing problems in two different areas: one is related to your game camera and the other is related to the player controls.
So, right now I have an empty for the body of the player, and an empty for the head of the player. Then I have a camera parented to the head object
When I rotate however, it looks like the 3d model is glued to the camera.
This behaviour is a direct consequence of parenting the camera to something controlled by the player.
The camera shouldn't be parented to the player character or one of its children. Instead, it should be controlled by a solver
that tracks the player.
A possible definition for a solver is "a software routine that aims to solve a problem given a set of constraints."
Your "3rd person camera solver," a routine\method\function that you call each game tick to reposition and reorient your camera, could have the following constraints:
- If the player is standing still, centre the player character on screen.
- If the player is moving, centre on screen the point between the player character and a point ahead of the player in the direction that he's heading*.
- Prevent level geometry from occluding the player.
- Always mantain a certain distance from the player.
- Always use Ease-In and Ease-Out interpolation when transforming the camera
* This is a feature that is often overlooked in independent\smaller projects, but can be consistently seen in AAA games. It allows you to see "ahead" and anticipate obstacles. The player character is still on screen, but his focus is shared with an arbitrary point ahead of him in the direction that he's heading.
You do this by making the camera aim at exactly the average position between the player character and this point ahead of him. You interpolate between the player position in a manner such that when the player is not moving, the camera is solely focusing on him. The faster that the player moves, the more you focus on the average position between the player character and the arbirtrary point.
I have implemented this in a small demo that you can download here: http://www.gamedev.net/topic/650327-why-do-2d-games-have-main-character-locked-in-the-middle-of-the-screen/#entry5111055
I believe that by far what makes the most difference with controls is regarding the player input for movement as relative to the camera
When you press the "move to the right" key, you transform the [1, 0, 0] 3D vector from the local space of the camera to the world space, and then proceed to move and orient the player character with the resulting world space vector.
A lot of games (especially console games) don't make use of "turn left" or "turn right" keys. Rather, there are only movement keys and when you move the player character, he turns to face the direction that you are moving him with.
In some games you can even steer the player character just by having him move forward and then orbiting the camera around him - this is evidence that the movement is relative to the camera.
This style of control is much more intuitive. Regardless of where your character may be facing, pressing "right" will make him turn to the right side of the camera (for the person playing, it's the "right side of the screen") and move in that direction.
I'm not sure if you're using Unity. This is demonstrated in their documentation for the "transform.TransformDirection()" method:http://docs.unity3d.com/Documentation/ScriptReference/Transform.TransformDirection.html
Edited by Kryzon, 19 April 2014 - 12:51 AM.