# How do you get the camera to always be behind the ball whatever direction it is moving?

OK I give up!

How do I make the camera follow the ball always behind it, no matter which direction the ball is moving.
But without this happening:

I have figured out how to make the ball always point in the direction it is moving, having prevented it from rolling.

I am in the process of turning the ball into a ‘pacman’ with a face, so I can’t have it rolling.

Is there an easy way to do it? Or is it going to be a hard maths slog?

``````using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Pacman : MonoBehaviour
{
private Rigidbody m_rbPacman;
public float m_fSpeed;

// Start is called before the first frame update
void Start()
{
m_rbPacman = GetComponent<Rigidbody>();
}

void RotatePacman()
{
float fAngleMovement = Mathf.Atan2(m_rbPacman.velocity.x, m_rbPacman.velocity.z) * Mathf.Rad2Deg;

if (fAngleMovement == -90.0F)
fAngleMovement = 270.0F;

transform.rotation = Quaternion.Euler(new Vector3(0, fAngleMovement, 0));
m_rbPacman.angularVelocity = Vector3.zero;
}

// Update is called once per frame
void FixedUpdate()
{
float fHoriz = Input.GetAxis("Horizontal"),
fVert = Input.GetAxis("Vertical");

if ((fHoriz == 0.0F) && (fVert == 0.0F))
{
m_rbPacman.velocity = Vector3.zero;
RotatePacman();
}
else
{
Vector3 vect3Force = new Vector3(fHoriz, 0.0F, fVert);

RotatePacman();
}
}
}
``````
``````using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class MainCamera : MonoBehaviour
{
public GameObject m_goPacman;

// Start is called before the first frame update
void Start()
{

}

// Update is called once per frame
void FixedUpdate()
{
Vector3 vect3Movement = Vector3.zero;
Debug.Log("XXXXX" + m_goPacman.transform.rotation + "XXXXX");

}
}
``````

What is “this happening”? I know what the image shows… but i have no idea how you did that, or why i would have to specifically consider it a problem while thinking about your problem. While talking about the things you did… it might also actually be a good idea to tell us what you did. Like, with some code.

Anyways, yes thats possible. You only need to know where the ball is moving in some way. This depends on your project. For a physics based project, you might simply use rb.velocity. If you calculate your own movement vector, you could use that. Or you base it on the player inputs. It depends on the game.

Once you have some ball-direction vector, you can simply normalize and flip it. Now you got a vector pointing behinds the ball. Multiplying it with some fixed or dynamic distance gives you the new XZ position of your camera. Add some other mechanism to determine its height, call LookAt(ball), and you are mostly done.
Additionally you probably want your camera to smoothly move towards its new target location, rather than setting it, or prevent it from going through walls, but those are additional topics.

If you don’t want to deal with math consider using cinemachine. It has components with examples for most the of the camera beaviors commonly found in for various styles of games.

Aye indeed… Camera stuff is pretty tricky… Cinemachine can be installed from the Unity Package Manager.

There’s even a dedicated forum: https://forum.unity.com/forums/cinemachine.136/

And tons of tutorials on Youtube.

Sorry, I should have included the before image.

The camera starts off at 45 degrees angled down to see the balling in the play field.

But as soon as I do anything to change the angle directly in transform.rotation, through a Quaternion, the camera then always returns to the horizontal and stares into scene infinity.

Actually thinking about it overnight, I think a better approach would be to use the direction the ball is facing (0 to 359 degrees) to rotate the camera position around the ball position without changing the camera’s transform.rotation.

I think that stands up mathematically doesn’t it?

I imagine it might work… the trick will be the sharp changes of direction as your velocity vector slows to near zero and goes the other way… the camera would whip around instantly, but you could mitigate that by clamping the rate of possible direction change.