# XNA projectile physics

Page 1 of 1

## 10 Replies - 5274 Views - Last Post: 10 September 2013 - 12:12 PM

### #1 Aythan

Reputation: 0
• Posts: 4
• Joined: 08-September 13

# XNA projectile physics

Posted 08 September 2013 - 02:20 AM

Hello,
I am currently working on a (2d) XNA game and am having trouble getting the physics of my projectiles right.
What I would like to achieve is the projectile follow an exponential curve, somewhat like:

Any help would be greatly appreciated, cheers.
Is This A Good Question/Topic? 0

## Replies To: XNA projectile physics

### #2 andrewsw

• quantum multiprover

Reputation: 6776
• Posts: 27,944
• Joined: 12-December 12

## Re: XNA projectile physics

Posted 08 September 2013 - 04:43 AM

Where is your current code? Please post it wrapped in [ code ] tags.

[I have closed your duplicate post in the C# forum. If it wasn't in the correct forum then it would be moved, so there is no need to duplicate.]

### #3 Aythan

Reputation: 0
• Posts: 4
• Joined: 08-September 13

## Re: XNA projectile physics

Posted 08 September 2013 - 06:12 AM

Looking to manipulate x and y coords for a vector 2.

Current code:

``` public void shoot()
{

if (Keyboard.GetState().IsKeyDown(Keys.S))

newvomit.velocity = new Vector2(10, 6);
if (player.left && !Keyboard.GetState().IsKeyDown(Keys.S))
newvomit.velocity = new Vector2(-10, 0);
if (!player.left && !Keyboard.GetState().IsKeyDown(Keys.S))
newvomit.velocity = new Vector2(10, 0);
newvomit.position = spritepos;// spritepos + newvomit.velocity * 5;
newvomit.isVisible = true;

if (vom.Count() < 20)
vomits += 1;

}

// vomit class //

class vomit
{
public Texture2D texture;
public Vector2 position;
public Vector2 velocity;
public Vector2 origin;
public int frame, vomwidth;
public Rectangle vomrect;
public bool isVisible;

bool left;

public vomit(Texture2D newTexture)
{
texture = newTexture;
isVisible = false;
frame = 9;
vomwidth = 48;

}

public void update(GameTime gameTime)
{
if (Keyboard.GetState().IsKeyDown(Keys.A))
left = true;

if (Keyboard.GetState().IsKeyDown(Keys.D))
left = false;

public void Draw(SpriteBatch spriteBatch)
{ position.Y = position.Y + 1;
vomrect = new Rectangle(frame * vomwidth, 0, vomwidth, 33);

if (frame <=8)
frame += 1;
else frame = 0;

spriteBatch.Draw(texture, position, vomrect, Color.White, 0f, origin, 1f, SpriteEffects.None, 0);

```

### #4 BBeck

• Here to help.

Reputation: 792
• Posts: 1,886
• Joined: 24-April 12

## Re: XNA projectile physics

Posted 08 September 2013 - 06:36 AM

If you want to make it act like a true projectile, you need to implement gravity.

Basically, that "curve" in the real world is just the fact that it is falling. Your drawing shows the projectile starting off on a flat path, which never happens in the real world once the projectile leaves the barrel. After that it constantly falls. Basically, the drawing is accurate if the flat part of the trajectory is while it's still in the gun.

The reason people don't "perceive" it following that path is that when you shoot, the barrel is actually tilted upward slightly. Your sights or scope will be setup with the barrel pointed upward when it's on target.

So, you basically just have two vectors: one that moves the projectile forward at a given velocity per second, and another that is gravity. There's a reduction to that forward velocity which is drag. And in the real world the situation can be complicated a little bit by things like crosswinds and such (but you probably shouldn't worry about that for this).

So, basically, if you can make the projectile fall 9.8 meters per second every second you will be simulating gravity and the forward path will basically result in a curve. You just need a vector that accelerates it towards the ground at a rate of 9.8 meters per second every second until it reaches terminal velocity or is stopped by the ground.

### #5 BBeck

• Here to help.

Reputation: 792
• Posts: 1,886
• Joined: 24-April 12

## Re: XNA projectile physics

Posted 08 September 2013 - 06:42 AM

I might also add that in the real world you get bullet rise (because the barrel is pointed upward) and then bullet drop. Your sights are set on a flat line and so the sights are only accurate at the point they are sighted in on. Normally, you sight in at 100 yards/meters with a rifle. So it will rise before 100 meters and then fall until at 100 meters it is aligned with the sights and then fall further after that.

The overall trajectory of the projectile will be more flat the faster it travels because gravity acts at a constant rate and so if it travels 100 meters per second, it will fall the same amount as if it traveled 1000 meters per second. It will fall by the same amount, but in the second case it will have moved forward 900 extra meters during the time that it fell by that amount. So, you'll get a "flatter" flight path.

### #6 Momerath

• D.I.C Lover

Reputation: 1021
• Posts: 2,463
• Joined: 04-October 09

## Re: XNA projectile physics

Posted 09 September 2013 - 08:52 AM

You could get a path close to the one he specified by having a high initial velocity and rapid deceleration.

### #7 lordofduct

• I'm a cheeseburger

Reputation: 2668
• Posts: 4,786
• Joined: 24-September 10

## Re: XNA projectile physics

Posted 09 September 2013 - 09:14 AM

1) that's not an exponential curve

2) implementing "true" physics on projectiles like bullets is usually over kill in a game (things like grenades and the sort are normal)

3) Should this projectile be causing damage during the fall arc of its path? If not, what's the point of even having it?

4) if you're attempting to actually simulate REAL rifle trajectory, you should read about what real rifle trajectory looks like.

A simple rifle with a single sight (a simple notch) is usually a straight shot rifle and has a range of accuracy (usually pretty short)

A high-end sight will have several marks in the sight with numbers next to them. The angle of the sight marks to the barrel creates various paths depending your target range. You often will end up with a upward arc.

A straight shot trajectory will look more like this:

Thing is, this all really only matters on what YOU want to simulate. If you're making something like a hunting simulator, the accurate trajectory might be what you want... if it is, learn the real trajectory of a bullet.

If you just want shooting in your game for a simple FPS, just go with a simple ray cast straight line shot with range. One single RayCast through your world and you're done.

If you want something in between... give me more information, and I could probably help with it.

Should we consider time duration? Allowing fast moving objects to dodge.

Do you have velocity/range damage? (bullets slow down as they travel, low speed near the end of the curve causes less damage)

Would you like to support variable ranges and strengths so you can have several different guns?

How would you want to manipulate those values (maybe draw a simple trajectory spline, calculate from real physics values, calculate from more human readable values)

This post has been edited by lordofduct: 09 September 2013 - 09:20 AM

### #8 BBeck

• Here to help.

Reputation: 792
• Posts: 1,886
• Joined: 24-April 12

## Re: XNA projectile physics

Posted 09 September 2013 - 10:51 AM

One thing I've always wondered is how to simulate bullet drop. It would apply to arrows too but they obviously move a lot slower. And I'm thinking in 3D here.

I mean, if you did simple ray casting you could just simply determine whether the ray and the object collide. I think most top notch video games have done it that way. So, it's instantaneous and simulates a laser rather than a bullet. (Actually, even light takes time to travel, but it would be near instantaneous at these ranges.)

And the lack of realistic physics has always annoyed me a little on that. I would like to actually see an arc.

But of course, the problem then is how to determine the collision. With an arrow, the flight path might take so long that the target has actually moved by the time the arrow arrives, likewise with a bullet at long range and a moving target.

An arrow may actually move slow enough that you can just use bounding objects and see if they collide. But a bullet may move so fast that it's on one side of the object in one frame and on the other in the next frame. So, the collision objects never intersect and the bullet "passes through" with no collision.

So then, how do you determine there was a collision between frames? Oh wow! I just came up with an idea as I was writing that last paragraph! I meant to pose this as a question, but I think I may have just found my answer. If you kept the position of the projectile from the last frame, I think you could determine the frame where the projectile is on the other side. Assuming a rather slow moving target, you could ray cast between the position in the previous frame and the current frame and see if it intersects the target. It's a "little" un-accurate because you don't have the arc but it would be arcing for all frames except the two that it happens between. So, the flight path would become basically flat during that 1/60th of a second (or whatever the frame rate is), but otherwise would still be arcing throughout it's flight path. It seems it would be more accurate than a ray cast from the gun to the target in terms of flight path.

So, if the bullet flew at 300 meters per second and the frame rate was 1/60th of a second that would be 5 meters in every frame. That could easily be on one side of the target in one frame and clean on the other side in the next frame without a collision unless the target is more than 5 meters thick. If you were to ray cast between the position in the previous frame and the current position, that would be a flat trajectory for 5 meters, but unless it's at point blank range that's still much more of an arc'ed trajectory than a straight line between the gun and the target.

But then I'm thinking, "You need to know which object, before you can test which side of it the projectile is on." Maybe you could do simple spherical collision detection between the projectile and everything in the game world that might be a target. The collision sphere might be the size of the distance that the projectile could fly in a frame. That would be a pretty quick collision check. And then you could determine which side of an object it is on for only the objects that collided in the spherical test, and do a more accurate collision test on just the objects that it collided with in the spherical collision test.

Anyway, any ideas on a different way to handle it?

### #9 Aythan

Reputation: 0
• Posts: 4
• Joined: 08-September 13

## Re: XNA projectile physics

Posted 09 September 2013 - 08:53 PM

This is way beyond what I was trying to implement. For the level of complexity, think "Binding of Isaac" style projectiles how they travel and then suddenly drop. My game is a simple 2D side scroller style game.

The green balls are the projectiles, namely vomit (don't ask) .

### #10 BBeck

• Here to help.

Reputation: 792
• Posts: 1,886
• Joined: 24-April 12

## Re: XNA projectile physics

Posted 10 September 2013 - 05:45 AM

After it reaches a certain distance (or time) you could start applying a very short (extremely short actually) downward vector, by adding it to the motion vector(velocity I believe) every frame. Then you could stop once it reaches the ground.

### #11 lordofduct

• I'm a cheeseburger

Reputation: 2668
• Posts: 4,786
• Joined: 24-September 10

## Re: XNA projectile physics

Posted 10 September 2013 - 12:12 PM

@OP - what Beck just said, have a range... move bullet in straight line across that range, then apply accelerative gravity when it reaches its end range to have it fall to the ground (accelerative gravity so it gets that nice arc as opposed to a angle drop).

@Beck - If you wanted a amunition that had true physics, and took true time to travel a distance then you're pretty much in line with how I would do it.

There's no efficient way to calculate continuous arcs, and instead have to do it as small pieces of line strung together. If the distance traveled per frame is reasonably long, I might break that up into a couple steps over one frame. But that's about it.