Boomerang logic?

[westloar]

I'm currently prototyping a 2d side scroller and I'm looking for some advice on how to plot the path of a boomerang projectile.

For the prototype, the projectile will move in a simple straight line away from and back to the thrower (I know not very realistic). I was thinking of using A* pathfinding to plot the route of the boomerang, but I though it could be possible to create a line object (not rendered) dividing that up equally into nodes and using that to plot the projectiles course.

I know both are possible, but I wondered which is easier to implement and relatively speaking, which is a better implementation?

[kalkitus]

I think it would be even easier to just forget about pathing the boomerang. Just shoot it out like a bullet and have a timer that will expire (or when it collides with a wall/enemy) and tell the boomerang to a "go back to player" state. In this state, it will stop moving forward and instead, track back towards the player (just like a follow missile).

[westloar]

so to track back it would have remembered the route it took and just backtrack that after it's max time out?

Games published by our own members! Check 'em out!

[kappa]

so to track back it would have remembered the route it took and just backtrack that after it's max time out?

No, pathfinding is too expensive an operation for projectiles (especially if you have lots).

To backtrack to the source, you simply get position of source and the projectile and then move projectile closer towards source (at desired speed). You repeat this every frame until projectile reaches the source. To get a more smoother curvey move back just slowly subtract new direction from projectiles current direction.

[Mads]

Instead of a timer you can check the distance from the boomerang to the player, and make it turn around accordingly.

[Z-Man]

Instead of a timer you can check the distance from the boomerang to the player, and make it turn around accordingly.

What if the player moves though? That would throw of the distance between the player and the thrown boomerang. Unless the player has to stand still while the boomerang is in the air.

[Orangy Tang]

I'd probably go for steering behaviours for this ( http://www.red3d.com/cwr/steer/ ), assuming you always want the boomerang to return to the character. Just a simple one which start with a 'repel' and switches to an 'attract' after a certain amount of time would do it.

[Mads]

Instead of a timer you can check the distance from the boomerang to the player, and make it turn around accordingly.

What if the player moves though? That would throw of the distance between the player and the thrown boomerang. Unless the player has to stand still while the boomerang is in the air.

Not the current position, but the one from when it was cast. It should navigate to the current position when it's returning though.

[kalkitus]

so to track back it would have remembered the route it took and just backtrack that after it's max time out?

No, pathfinding is too expensive an operation for projectiles (especially if you have lots).

To backtrack to the source, you simply get position of source and the projectile and then move projectile closer towards source (at desired speed). You repeat this every frame until projectile reaches the source. To get a more smoother curvey move back just slowly subtract new direction from projectiles current direction.

Kappa is correct. You can google examples of follow missiles or homing missiles as they are the exact same logic you want.

Formula I found from google to go towards a target:

1   2   3   4   5   6

int dy = targetY - y;         int dx = targetX - x;         double speed, sep;         sep = Math.sqrt(dx * dx + dy * dy);         speed = scale/sep;

There is a cheaper way than doing square roots but at this point, you shouldn't be worrying about optimization as small as that.

[westloar]

Kappa is correct. You can google examples of follow missiles or homing missiles as they are the exact same logic you want.

Formula I found from google to go towards a target:

1   2   3   4   5   6

int dy = targetY - y;         int dx = targetX - x;         double speed, sep;         sep = Math.sqrt(dx * dx + dy * dy);         speed = scale/sep;

There is a cheaper way than doing square roots but at this point, you shouldn't be worrying about optimization as small as that.

Thanks for all the replies guys, you may have noticed I am new to programming in general, although I'm picking it up fast, so please bear with me !

Could you explain how the above formula works, I don't quite understand where some of the "x" and "y" 's come from.

Games published by our own members! Check 'em out!

[kalkitus]

The x and y are the boomerang coordinates and the targetX and targetY would be your character's coordinates.

Try to get this working, it's simpler:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

// when the boomerang is ahead of the character, move it backwards and move it // forwards when it is behind the character. if(boomerangX > characterX){    boomerangX-=boomerangSpeed; } else{    boomerangX+=boomerangSpeed; } // when the boomerang is below of the character, move it upwards and move it // downwards when it is above the character. if(boomerangY > characterY){    boomerangY-=boomerangSpeed; } else{    boomerangY+=boomerangSpeed; }

[Mads]

Kappa is correct. You can google examples of follow missiles or homing missiles as they are the exact same logic you want.

Formula I found from google to go towards a target:

1   2   3   4   5   6

int dy = targetY - y;         int dx = targetX - x;         double speed, sep;         sep = Math.sqrt(dx * dx + dy * dy);         speed = scale/sep;

There is a cheaper way than doing square roots but at this point, you shouldn't be worrying about optimization as small as that.

Thanks for all the replies guys, you may have noticed I am new to programming in general, although I'm picking it up fast, so please bear with me !

Could you explain how the above formula works, I don't quite understand where some of the "x" and "y" 's come from.

Each object in play needs an on-screen position, hence the x/y. When doing these free-flying objects like you do now, an approach to just very basic physics is to assign a pair more of doubles of the veloctity of the object. Two, because one for velocity on the x-axis and one on the y-axis.
Then when you update position, you can do something like:

1	player.setX(player.getX() + player.getXV());

This is provided that your x/y is also doubles (just cast them to integers when drawing).
Acceleration is as easy as player.setXV(player.getXV() + GameMain.SPEED_FACTOR); and be sure to decrease it as well if you want that

[westloar]

Thank you for the simplified formula kalkitus, much appreciated.

But my main point was that I literally didn't understand which variables were referring to which objects so I only needed clarification for that