Hello! I''m working on something that''ll hopefully be part of a game some day; It''s a sprite that''s supposed to follow another sprite connected to the cursor. My problem is that I can''t make the homing ablilty of the first sprite to work correctly. It follows the cursor sprite to some extent, but in a really shaky way, and when it''s a little way off it just stops getting closer but it''s still shaking. To make the sprite move I first calculate the angle from the sprite to the cursor sprite (in a way that makes right 0 degrees and left 180 deg.), then I use cosine and sine to get the X- and Y-movement needed to make the sprite go in the desired direction, and finally I multiply those values with a speed value to make the sprite move faster. Am I doing something wrong here? It seems to work almost right, but not quite. Does anyone know of a better way to do this? Has anyone any experience of programming homing devices?

What you''re doing seems ok. I suspect the reason it''s going wrong is that the speed value makes the sprite move too far, past the cursor and then keep flipping from one side to the other. To solve it you''d have to alter the speed based on distance to the cursor, and probably just stop the sprite if the distance goes below a certain threshold.

Anyway, if you want a slightly more advanced homing system (although not too hard to understand IMO), I suggest you look at:
http://www.red3d.com/cwr/steer/

Specifically, have a look at the "Persue and Evade" simulation, and possibly also "Arrival". The explanations with all the relevant equations are all in the paper, here:
http://www.red3d.com/cwr/papers/1999/gdc99steer.html

Hope that helps,

John B

Actually it sounds like you are makeing the homeing function more complex then it needs to be...but then I don''t know all the details.

obviously you have the screen location of the mouse (mouse_X and mouse_Y)...and the screen location of the sprite (sprite_X and sprite_Y)...so there are a number of ways to make the sprite follow the mouse, just by useing these numbers as the base...for example (all of the following examples are pseudo code):

XX = mouse_X - sprite_X
yy = mouse_Y - sprite_y

if you then add XX and YY to sprite_X and sprite_Y...then the sprite and mouse would be at the exact same location...but you want the sprite to follow the mouse...so you can do this:

XX = XX / 10
YY = YY / 10

sprite_X = sprite_X + XX
sprite_Y = sprite_Y + YY

Now the sprite seems to follow the mouse around...when the sprite is closer it moves slower...when far it moves faster...instead of divideing by 10...you could experiment with different values (divide by 100)...or multiply by .1 or .01 for example...you can even "clip" the values in XX and YY so the sprite doesn''t move so fast:

IF XX > 5 THEN XX = 5
IF XX < -5 THEN XX = -5

then do the same for YY and add them to sprite_X and sprite_Y...so now the sprite only moves at a certain top speed.

In the example above XX and YY act as vectors...by retaining them between updates...then modifying them during updates before adding the vector to the sprite...you can get the sprite to do a lot of other stuff.

for example:

XX = XX + ((mouse_X - XX) * .1)
YY = YY + ((mouse_Y - YY) * .1)

sprite_X = sprite_X + XX
sprite_Y = sprite_Y + YY

This can make the sprite appear to "buzz" around the mouse like a fly...and changeing the multiplication values (.1) to different values the sprite can appear to be more/less interested in the mouse...

this stuff also works in 3D space too...and by finding the angle between the sprite and mouse (or sprite and its XX/YY vector) it can be graphicly rotated.

hope this helps

Thanks alot for both of your answers! It's great to get such quick responses. I haven't had the time to test anything of what you suggested, but I surely will try it.

quote: Original post by JohnBSmall
I suspect the reason it's going wrong is that the speed value makes the sprite move too far, past the cursor and then keep flipping from one side to the other.

No, it's not like that. The "whole lotta shakin'" that's going on is only sideways, and the sprite always stops before it arrives at the cursor sprite.

Both of you suggest that I make the sprite go slower the closer it gets to the cursor sprite, but since I'm going to apply this on a hockey player chasing a puck it might not always be very realistic if he slows down just before he picks it up. Another thing is that I'm sure it can be done some other way (which I might find when I read the paper that John B suggested), I mean think if it was supposed to be a homing missile, then it would be kinda odd if it slowed down more and more before the impact, wouldn't it?

[edited by - Flare on September 9, 2002 6:21:56 PM]