Hi
I tried to make a simple 2d platformer game . I am going to implement a boomerang weapon for the player by generating a fixed bezier curve path and then make the boomerang follow the path , Everything works fine except the boomerang doesnt return to the player if he changed his position ...
Anyone can give me an idea to fixed this issue or to implement the boomerang in another way ?
PS: The weapon "Rolling Cutter" boomerang style of Megaman is what i want to achive
The easy (cheating) way is to make the bezier curve centred on the player, If they aren't moving too fast that looks ok.
Othwerwise you have to update the control points as the boomerang is in flight, again you can centre it on the player but keep updating the control points as the player moves, with the final point always on the player.
You could also make the boomerang miss and wait until it is picked up again/destroyed before letting the player use it again, I think 2d zelda did this, not sure. However that was just a back and forward along a straight line boomerang not on a bezier.
Most games, off the top of my head, seem to cheat and just use some sort of gravity/force/acceleration on the boomerang that is towards the player, and don't use a planned path. So the toss/throw gives it some initial velocity in a direction, and then every physics update it gets a small acceleration towards the player. Furthermore, they tend to either cheat and have it go through walls/obstacles, or if it does collide with something solid, it stops, and the player has to go pick it up.
EDIT: After watching a video of rolling cutter in action, the bezier is probably the way to go. As usual, I will point to catmull-rom, since it's a curve that goes through all it's control points, and if I recall correctly, is nice and local, ie changing control point 6 will not change the path of control point 3, so should probably be one of the easiest to implement. All you really have to do is continually update the very last control point to be that of the player.
"All you really have to do is continually update the very last control point to be that of the player."
- this was my thought exactly. Catmull-rom may be the way to go (I am not familiar with it) but if you go with a plain vanilla Bezier curve, take a look here: http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/Bezier/bezier-move-ct-pt.html
you can see a nice formula for modifying a single control point. In your case, the displacement vector v would be how far your player moved from its initialize location. This may or may not improve your performance depending on how you implement it, but it may at least simplify your code.
"All you really have to do is continually update the very last control point to be that of the player."
- this was my thought exactly. Catmull-rom may be the way to go (I am not familiar with it) but if you go with a plain vanilla Bezier curve, take a look here: http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/Bezier/bezier-move-ct-pt.html
you can see a nice formula for modifying a single control point. In your case, the displacement vector v would be how far your player moved from its initialize location. This may or may not improve your performance depending on how you implement it, but it may at least simplify your code.
Except for at the very end where it states:
Changing the position of a control point causes the shape of a Bézier curve to change globally.
In other words, moving one control point of a bezier curve will cause the boomerang to no longer be on the curve. I highly recommend using Catmull-Rom splines.
(Though you could probably have the boomerang head towards the nearest point on the curve or something, but it might look weird.)
EDIT: Nm, changing just the end points seems to be the exception for the bezier curve, so you'd be okay for that case.
You can also apply an heuristic since the beginning of the flight: slightly different paths depending on the player's expected position after a certain time, when the boomerang comes back. Adjusting the endpoint as others have suggested can then take care of the prediction error.
In the simplest case, you can distinguish between walking and standing still; the player can be expected to, respectively, walk in the same direction for a large fraction of the flight time and for a very small fraction of the flight time. In some kinds of platform game you might be able to predict jumping down a ledge, interacting with an obstacle, and other variations.
Omae Wa Mou Shindeiru
I think it would be rather nice to do it more real world.
In RL if you throw a boomarang, it doesn't come back straight to your hand every time, it's a bloody good throw if it does 
I just think instead of the standard lego batarang that always comes back it would be nice to just give it a flight path and energy and give it to the physics system.
Makes it a much more interesting choice, do I throw it at that target and possibly not be able to get it back? Do I save it until I really need it?
Interesting game play issues.
And not a reference to a dodgy song from the 70's
I think it would be rather nice to do it more real world.
...
Makes it a much more interesting choice, do I throw it at that target and possibly not be able to get it back? Do I save it until I really need it?
+1
I agree with this. It's easier and more realistic to give it to the physics system or just have it follow that static path; players should be able to learn the expected path and make the character jump to intercept it... or if not, then go fetch it.
Otherwise, using a gravity-like mechanic as others mentioned would work.
If you want a particular shape path, you can tweak the variables to achieve this.
Worst case, it orbits you like a planet if you keep dodging it.
Using a curve, you could get some very bizarre behavior quite regularly by moving the end-point in flight.
The OP seemed to really want to mimic the Rolling Cutter effect from MegaMan:
EDIT: And after some further thought, you could probably do this fairly simply by not even using a curve, but just linearly interpolating along some points that get generated from some set offsets from the player at the time of the throw, with the last point always being the players most current position.
