# Move player to mouse click

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?

## 3 Answers

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.
• Thanks! I wanted to use AddForce because ive understood that in Unity the rigidbody.velocity should not be manipulated if one wants the physics to work. But i guess it would have to something i need to think about. My idea is a track proppelled veichle. So i guess i could move it by its transform.position and if it is hit i can stop moving it by the position and add force for a while. When the force has settled down the player can move again. – Daarwin Jan 28 '14 at 1:45
• @Lautaro You shouldn't manipulate RigidBody.velocity but you can achieve what Jason said by calculating the position (see my post). But since you are modeling a propelled vehicle, maybe AddForce is really what you want (so you can have the inertia effect). – Roberto Jan 28 '14 at 2:02
• I see. Im not quite getting what you mean i should use to move the object if not AddForce or .velocity. Could you clarify? – Daarwin Jan 28 '14 at 2:37
• The 'velocity' variable is "owned" by the physics system -- messing with it will break the systems internals in nasty ways. A tracked vehicle is actually one of the cases in which using AddForce is appropriate. Just be careful to dial down the speed as you approach your destination or your character will overshoot, turn around, and come back, potentially looping forever! (Unless you are only doing this when the mouse is held down, of course.) – user41442 Jan 28 '14 at 3:12

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.

• Even if i didnt choose your answer, thank you very much for insight and taking your time! – Daarwin Jan 28 '14 at 1:42

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.

• A lot of info. Thank you! I dont fully grasp all of it but i will save it and return to read it when ive learned more. – Daarwin Jan 28 '14 at 2:02