# how to direct an object towards another?

This topic is 2904 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi all

I am trying to implement something theoretically very simple but it just wont work. I'd like for an object (representing a bullet-like thing) to move towards what the position of the player is at the time of creation.

This is the constructor:

 FireBall::FireBall(Vector3 pos, Vector3 tar){ entity.setPosition(pos.x, pos.y, pos.z); target = tar; } 

Where entity stores the vector position and orientation of the object. I have this method to have the object orient its axes to face the target:
 void FireBall::faceTarget(){ dir = entity.getPosition() - target; dir.normalize(); lookAt = entity.getForwardVector(); lookAt.normalize(); float cos = Vector3::dot(dir, lookAt); if (cos >= 0.005){ facingPlayer = false; entity.orient(-FIREBALL_ROTATION, 0.0f, 0.0f); } else if(cos <= - 0.05){ facingPlayer = false; entity.orient(FIREBALL_ROTATION, 0.0f, 0.0f); } else { facingPlayer = true; } 
Where orient rotates the object's axes (yaw, pitch, roll). When facingPlayer is set to true I just move it down its Z axis.... This is probably a very convoluted solution for the problem but it's working fine for having an enemy rotate to face the player, so I thought that it would work here too....but the ball just moves in random directions...

I'm sure there's a simpler solution for moving the object towards a set position, but I can't get anything to work?

##### Share on other sites
When the fireball is facing the target, can you not take the fireball's position vector away from the target's position vector to create a directional vector, normalize it, then move the fireball along that vector every frame?

##### Share on other sites
It seems like this is over complicated rather than made simpler.

For example, a struct for a character(2-D here)can represent a value determining what direction the character is facing.

Another struct can hold the value determining what direction the bullet or such will be facing based on what direction the character is.

You can also do this with global variables.

The value can be checked against upon propelling an object on input, and based on the direction the assigned standing point(character instance)is facing.

Creating the appropriate object towards another based on direction is all you need. The rest, such as velocity, collision, etc. can be stored in Enums or such.

But overall, this is not as complicating as many try and implement it through code, at least not in 2-D.

##### Share on other sites

When the fireball is facing the target, can you not take the fireball's position vector away from the target's position vector to create a directional vector, normalize it, then move the fireball along that vector every frame?

Thanks Calneon, I used your directions to create this solution that works almost completely right:

 //on initialization dir = target - entity.getPosition(); dir.normalize(); ... //on update entity.setVelocity(dir.x * FIREBALL_SPEED, dir.y* FIREBALL_SPEED, dir.z* -FIREBALL_SPEED); entity.update(dt); 

Which basically adds those values to the position times the deltaTime like you said.... The object always misses the player by a constant bit though, but that's probably not too bad as I can use a randomiser to add a different offset to the target each time and make it a bit more challenging for the player to avoid the fire balls...

Thanks quiltkickkiller for your input too, i'll definitely look into that solution too!

##### Share on other sites

It seems like this is over complicated rather than made simpler.

For example, a struct for a character(2-D here)can represent a value determining what direction the character is facing.

Another struct can hold the value determining what direction the bullet or such will be facing based on what direction the character is.

You can also do this with global variables.

The value can be checked against upon propelling an object on input, and based on the direction the assigned standing point(character instance)is facing.

Creating the appropriate object towards another based on direction is all you need. The rest, such as velocity, collision, etc. can be stored in Enums or such.

But overall, this is not as complicating as many try and implement it through code, at least not in 2-D.

WTF are you smoking.

##### Share on other sites
Neo if you want the fireballs to try and predict the player's location after they have travelled a distance similar to player distance at launch time:

using s2 = fireball speed and s1 = player speed.

time to travel = (s2 - s1)/(magnitude of distance between player and fireball at launch time) <- you have this vector and normalize it immediately.. grab the magnitude before normalizing.

now you need direction of travel. well the player will keep travelling in whichever direction they were going to begin with.

the fireball has to pick a direction. here's how to solve this.

Assuming player started at P1.. their future position Pfuture will be P1 + (s1 * timeToTravel)*(normalized vector of current player travel)

then the direction to actually shoot the fireball is the normalized vector of Pfuture - Plaunch. <- call this dir.

at time timeToTravel, fireball travelling at fixed speed in direction dir, should closely meet the player that started at Point P1 and travelled at constant player speed in players existing direction of travel.

t = (s2-s1)/(MAG(Plaunch-PplayerLaunch)

Pcontact = PplayerLaunch + s1(t)*(normalized player travel vector);

This can also allow players to wiggle to try to fake out fireballs.. the farther out the launch point, the farther they will miss. but should the player keep going in a straight line, the fireball should hit them in the future.

This whole shpeel was incase this is what you wanted to happen instead of just launching at the current position of the player, ignoring their direction and speed of travel.

##### Share on other sites

WTF are you smoking.
[/quote]

I'm guessing that means you're disagreeing with what I said or are confused in some sense.

My point is that you don't need object-oriented programming to perform such a task, such as propelling one given instance on the screen towards another.

One would say classes can be more convenient in some ways.

In the end it basically comes down to preference and choice.

I just don't think everything should be binded down to an object-oriented programming paradigm.

I say this because I notice so many do incorporate OOP in any project and I find it very exaggerated in many cases.

I believe OOP is a media/industry driven programming paradigm that is being enforced upon many programmers when it's not absolutely necessary, and even though blunt, to some, will agree OOP is not useful to their programming needs at all. I can show you several professional programmers(professional quality)who can write pretty large-scale games, such as Super Mario Bros., Super Mario RPG, Final Fantasy 6, etc., without any OOP at all in the same time it would take for one who did use OOP or less(and yes, even 3-D games as well). And they have no "major" difficulties managing and referring to their code and such.

But OP, sorry if I carried on. My point was just to show that you don't need class inheritance, constructors, destructors or OOP in general to calculate positions. You can manage data with structs, enums, global variables/containers and namespaces.

And if you get lost and/or confused, there's always comments.

##### Share on other sites
Original code:

1. Typo:
if (cos >= [color="#FF0000"]0.005){...} else if(cos <= [color="#FF0000"]- 0.05){...}
2. The missile is supposed to turn until it is perfectly aligned, not until it is almost aligned. Every step, measure the angle A between its movement direction and the vector to the target; the missile should turn by A if it is small enough (-FIREBALL_ROTATION <= A <= +FIREBALL_ROTATION), or by the maximum FIREBALL_ROTATION if A is too large to correct in one step. Having a dead zone causes the missile to fly slightly astray until it is too close to turn effectively.
3. The cosine of the angle between the normalized vectors dir and lookAt varies from -1 (fireball straight away from the target) to 0 (constant distance from the target) to 1 (perfect alignment towards the target). Comparing it with small positive and negative thresholds is quite wrong; maybe you meant to use the sine of the angle. The cosine could be useful to decide whether, in addition to turning, the fireball should brake (when negative) or accelerate up to top speed (when positive).

##### Share on other sites

My point is that you don't need object-oriented programming to perform such a task, such as propelling one given instance on the screen towards another.

The techniques you have been describing, to the extent that I can make any sense out of them... are perfectly compatible with OO. OO is not about having a lot of classes and following rules out of a textbook for how to hide data members (that isn't even what "encapsulation" really means in the first place).

If you want to pick on things like, for example, needless use of accessors and mutators, then do that. Point out the part that's actually complicated; don't just say "it looks like what I think of as "OO" so it must be too complicated".

OOP does not require "inheritance" by many definitions, and while it is normal for OOP languages to include the concept of a constructor, the concept of a destructor is actually pretty specific to C++ (where you don't have automatic garbage collection) and other languages that have to interface with C++ APIs. A finalizer is something different again, and also very, very rarely needed.

In C++, structs are classes. They can have member functions, and the only thing the differs is the default for access protection, which can be overridden. In C#, the picture is similar, except that structs are value types and classes are reference types. Instances of either are still objects, however. You pick the object-type with the semantics that make sense for your problem.

Comments cannot solve the problem of fundamentally flawed design, and aren't really relevant to the discussion anyway.

Although honestly, this entire mess is irrelevant to the discussion. What you seem not to have understood is that the OP is having trouble understanding the actual algorithms.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 12
• 9
• 11
• 15