Would anybody know how the best way to have an arrow (for example) be shot for a 2d platform game? I want the projectile to have a curved trajectory but can't figure out a good way to do it. Obviously it must require some sort of math equation but I'm pretty awful at any semi-complex math.
Also how would you incorporate a math equation into the projectile's X & Y co-ordinates? Fastloops?
Thank you!
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
this is basic projectile motion. speaking physically, there's no force on the arrow in the x direction, but there is a gravity force in the y direction. this means that the x velocity will remain constant, and the y velocity will be constantly changing by a fixed amount.
let's define our variables. X & Y are obvious. dx is velocity in the x direction, dy is velocity in the y direction. these values will be set when the arrow is fired.
for every frame update, you want your new X,Y values as such:
X = X + dx
Y = Y + dy
the crucial step is to also have a rule that changes dy on every frame, also:
dy = dy + g
where g is your gravity constant. something real small, and probably negative.
then, you would start with a positive dy (arcing up the screen), and it would gradually be reduced to zero (reaching the peak of the arc) and then it would go negative (falling back to the ground). meanwhile, it translates at a constant rate to the left or right.
this all assumes you have dx and dy at the moment when the arrow is shot. instead you'll probably have an idea of your speed and angle (5 pixels per second at 45 degrees). thankfully there's some real easy trig to find dx and dy given the angle and magnitude. i've worked up a picture:
oh! i got so caught up in physics that i forgot we're talking about a klik game here. in practical terms, the X,Y values of the object can only be integers. hence you should use 4 alterable values to store the X,Y,dx,dy , and construct your formulae so that klik treats them as values with decimal places.
then, after calculating new positions and velocities in terms of these variables, just add one last rule that sets the object's X & Y values to the appropriate variable values. it will round to integers automatically
otherwise, the motion will come out choppy and weird, and only work at certain angles, etc.
one trick I learned in MMF is that if you use the formula:
A = A + 5
then it treats A as an integer. instead, if you usse
A = A + 5.0
it keeps track of the decimal places. you can see if MMF is handling the decimal places properly by using the debugger and checking the arrow's alterable values.
Yeah I found that out before when I wanted enemy health bars to display their % of HP left. I wouldn't work unless I set their HPs with a .0 at the end, weird but it worked.
I also saved your picture above, with all this I'm sure I can make something work.
As for angles, I really only need to have 2 so I can experiment with that works / looks best and go from there.
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
I've personally always had trouble making it distinguish between integers and reals, even trying the +x.0 trick. Personally i hold the X and Y values in AValues as you described, but I basically multiply them by 100.
so a block at x10 y10 has the location alterable values xpos1000 ypos1000. But then when i am positioning on the screen (with an always loop to set x and y position) id do a:
"set x position to xpos *0.01" (divide has had issues before in my experience, with the same integer/decimal problem, i could proolly figure out why i had trouble ages back, but i find it easier to simply do a 1/x in my head and multiply instead)
Basically giving it a simulated 2decimal points, which imo is more than enough.
Plus, this way you don't need any +x.0 in your formatting, gets a bit simpler to code in my opinion, you might see it differently though.
But, yeah, derailed a little here, a basic static engine will sort out an arrow
One thing you might want to add though is angle. I cant recall the exact equation, arc tan or something, but you can just usethe direction calculator to do that for you anyway. Just use like
set direction to direction(arrowx,arrowy,(xarrow+xinertia),(yarrow+yinertia)) so it's basically pointing in the direction from where it is, to where it is + where it's going.
That would be accurate for a well shot arrow anyway, once had a game where you could call in a giant hail of arrows shot by peasants (good 'ol castle defense game), and simply had a flat rotation rate applied to them, so half of them didn't land straight, to give it a sort of amateur effect
Hm, I've always done trajectory just with an event like Every 0.20 seconds add (or subtract) 1 to arrows direction as long as it isn't already pointing downwards
Yeah, creates a realistic enough effect, although the most accurate would of course be to have an angle calculation. But it's a bit complicated for something so minor anyway, So I usually use that method too .
when coding, the simplest method that accomplishes your aims is the best, so go with what works! i like your method of circumventing the integers / floats issue in klik, i'll probably use that for my own peace of mind in the future. i keep coming across old, subtle bugs that happened just because i forgot a .0 somewhere...
if you really want the most physically accurate rotation, the arrow should always be looking along its direction of motion, so it should match the angle of the velocity, angle = arctan ( dy / dx )
when mixing the 32 directions, 360 degrees, floats and integers, and weird signatures for x and y (who thought this coordinate system was a good idea?!), the coding can become unnecessarily messy. which is why i say go with what works! a simple hack is usually just as good.
Yes, it just depends on what you need for your project. If you don't really need accurate trajectory, use the simple method but if you really want to create some fine coding, I think that MrMcFlurrys example should not be overlooked I will have a go at trying that out in MMF later.
i rly dun understand much of what u guys are talking but... if it helps, i had to do something similar, i made my player throw a grenade in an arc, so what i did was give the grenade a pinball movement and instead of "shooting it" it creates it in front, and depending on the time held the button, its the initial speed, and when it appears i made it go in a 45 angle so it goes all "arc-y" and stuff
Well here's what I was able to come up with but I haven't got the angle exactly right yet (but I will with some more trial and error).
When [space bar] is pressed ->
Create object "projectile" at 0,0 from object "enemy"'s action point
+Set alt val "Y1" of object "projectile" to Y pos of object "projectile"
+Set alt val "Z1" of object "projectile" to -15
(It should be noted here that the projectile object has a ball movement going to the right with it moving at start)
Then these are always going on too:
Always add 1 to alt value "Z1" of object "projectile"
Always set Y pos of object "projectile" to (alt val "Y1" of object "projectile" + alt val "Z1" of object "projectile")
--
I think that's pretty close, I don't have the code in front of me. What it does is pretty much what I wanted it to do though- launch a projectile up in a smooth arc and have it come down. Since the projectile has a ball movement anyhow & it's moving you're right I don't have to worry about the object's X pos at all.
Edited by Del Duio
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
Should work well enough for an object at constant speed, though you could come into some aliasing issues with that method, especially if you start having speeds change or slow down. (Like in the future with other objects)
If you start seeing odd movement from your objects what you need to do is what i was describing before, whenever you set or add to Y1 and Z1, you multiply the value by 100, like
Create object "projectile" at 0,0 from object "enemy"'s action point
+Set alt val "Y1" of object "projectile" to Y pos of object "projectile"*100
+Set alt val "Z1" of object "projectile" to -1500
then
Always add 100 to alt value "Z1" of object "projectile"
Always set Y pos of object "projectile" to (alt val "Y1" of object "projectile" + alt val "Z1" of object "projectile")*0.01
Or, as discussed you can stick x.0s everywhere like,
+Set alt val "Z1" of object "projectile" to -15.0
So the alterable values are treated as floats. Whichever feels neater to you, both methods have their pros and cons.
I'm going to have to simplify it when I have time, because the whole centiseconds thing makes it more complicated, but the Moving at Angles part should help with your problem. If you want to push it a little further, that's what the Friction, Air Resistance part is for.
I wrote that article sort of before fast loops were popular, so now, I think you can put it in a fast loop and should work fine, but you'd have to combine it with the Move Safely object if it moves too fast.
A little explanation on radians, since you're probably wondering. Sin(angle) or cos(angle) needs the angle in radians, not degrees. Radians are actually much easier than degrees. Simply put, Pi rad = 180 degrees (half a circle).
Pi*2 rad = 360 degrees (full circle)
Pi/2 rad = 90 degrees (half of half a circle)
So to get the right angle, you just multiply or divide pi by half circles... if you want an eight of a circle, it's pi/4 radians.
sin(angle) finds the up down ratio of an arc, between 1 and -1.
cos(angle) finds the left right ratio, between 1 and -1.
You just multiply that with the power behind the arrow, and you get your trajectory.
The only reason it doesn't go up into space is because gravity pulls it down.. the longer it stays in the air, the faster it goes down, that's why arrows go in an arc once the speed (velocity) of going down overcomes the velocity of it going upwards.
Yeah, that's basically what it means
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Advertisement
Post Reply
Edited by Rick Shaw
.
