Move player to mouse click

Question

Im hopelessly not good at algebra and such. But im trying to learn. I want to learn and understand how to use it in game programming rather than modifying snippets or using classes that do it for me.

So what i want to start with is to click on location and have an object move there. This is what i am thinking (in pseudocode and in a 2D world).

        vector2 mousePosition;
        vector2 playerPosition;

        vector2 direction = playerPosition - mousePosition;

        direction.normalize; //ive learned that this should be done, and i understand what it means to normalise a vector, but i am not quite sure of what goes wrong if the vector is not normalised

    //in the players update 
    if (player is not facing destinations direction)
    {
player.transform.direction = Lerp towards direction;

}else if(player IS facing the destinations direction)
{
player.rigidbody.AddForce(vector.forward, 100f);
}

Am i thinking correctly?

Answer 1

It depends on how you want your character to behave. In general, what you wrote is approximately correct, but be careful of a few things:

1. If the player is already at the mousePosition, then direction will have zero length and normalize will be a division by zero! To prevent this, just have an if statement and don't continue unless direction.length > 0.01 (or some other small constant).
2. Similarly, be careful with the directions. The test player is not facing destinations direction is as simple as direction * player.transform.direction < 0.95, where * is the dot product, assuming both directions are normalized (this is why you want to normalize). Basically, as two unit-length vectors (i.e. directions) get nearer to each other, their dot product gets closer and closer to 1, and if they are the same, then their dot product is exactly 1. On computer of course, the is rounding error, which is why you choose a cut-off close to, but not exactly, 1.
3. Finally, I'm not sure what system you are using, but adding a force is almost certainly the wrong way to get something like a character to move realistically, because players rarely have significant inertia, except in space sims. Also, you probably want to use the target direction rather than vector.forward.
4. See http://www.red3d.com/cwr/steer/Arrival.html, and the other behaviours on that site to get an idea of how to control characters which need to slow down/speed up. If your character is a person/creature, these are not what you are looking for, as you need something designed for a character which can start and stop on a dime.

Answer 2

If you did not normalize the vector, the direction would infact be the same, in a sense, but the scale wrong. Take direction vector [2.0, 1.0] and direction vector [1.0, 0.5]. Essentially they are pointing the same way, but if you compare them in your code you would get a false in return. Even worse if you want to accelerate something along the direction vector by multiplying it by a constant you would in the case of the first vector get double the acceleration compared to the normalized second one, so it is important to keep directions normalized.

Without knowing the whole context, I would say you think correctly thus far.

Answer 3

Starting with the normalization, it's the process of getting a vector and resizing it to one unit (one meter, one kilometer, whatever you are using). Why this? Because of this equation:

s = v.t

where s is space, v is velocity and t time. So it tells where your object will be in a given t delta time when on v speed.

But this is for unidimensional space. When you are in 2D space, you can have movement in two dimensions, x and y. So your equation is:

S = V.t

where S and V are 2D vectors. When your V has some speed in x but zero in y, S will result in movement in the x axis and not on y. Hence, we can say V not only tells how fast the object moves, but it also tells which direction it's going, right?

In this case, V is not called speed anymore, it's called velocity, because it contains a direction and it tells how fast the object moves.

But what would be direction = playerPosition - mousePosition? It certainly points towards the mouse position, but you can easily see that the farther the mouse position is from player position, the bigger the direction will be. Which means it's more than just the direction, in fact, it's the distance the player should move to get to the mouse position, which is not what you want. You want a direction, and that's why you normalize, to make a vector of magnitude (size) one, so it just represents a direction. And then we have:

s = v.D.t

where D is the direction vector. See? v.D is equal to V, that is, a scalar v multiplied by a direction D, vector of size one, will give you velocity.

The same thought can be applied to force equations, which the AddForce method uses. AddForce takes a direction vector and a scalar for the size of this force. But you don't need to normalize D because you don't use it to apply the force, you use vector.forward which is a normalized vector.