Java-Gaming.org Hi !
 Featured games (83) games approved by the League of Dukes Games in Showcase (580) Games in Android Showcase (162) games submitted by our members Games in WIP (632) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1] 2
 ignore  |  Print
 Physics of shooting  (Read 6638 times) 0 Members and 1 Guest are viewing this topic.
Wildern

Junior Devvie

 « Posted 2010-03-08 15:25:17 »

I am working on an asteroids-ish game and am just not seeing what I need to do with the shots.
The ship is always in the center of the screen.
The behavior I am trying to achieve is that no matter how fast the ship is moving, firing in any direction results in shots moving away from the ship at a constant rate.
In other words, if the ship is moving very fast from upper right to lower left, then a shot fired at the lower left corner should take the same time to reach that corner as a shot fired towards the upper right corner.

Currently, the new shot object starts out with the same movement vector as the ship and I add a fixed amount of thrust in the direction of fire.  This results in variable speed and apparent direction when moving fast.  I know I need to adjust based on the current movement vector, I am just not sure of the operation(s) I want to perform.
ryanm

Senior Devvie

Projects: 1
Exp: 15 years

Used to be bleb

 « Reply #1 - Posted 2010-03-08 15:37:42 »

So you're wanting your bullets to have a fixed speed relative to a stationary point, regardless of how fast the ship is moving?
Just don't add the ship's velocity on to the bullet's initial velocity.
Wildern

Junior Devvie

 « Reply #2 - Posted 2010-03-08 15:50:17 »

It is a perceived stationary point, I want a fixed speed relative to the ship, which is moving.
I am achieving the movement effect by keeping the viewport centered on the ship.
Not setting the bullet's initial velocity to match the ship results in greater perceived inaccuracy.
To get the effect I am gong for, shots fired in the opposite direction of the vector of the ship's movement will need to have greater speed then shots fired in same direction as the vector of the ship's movement.

Does that make more sense?
dishmoth
 « Reply #3 - Posted 2010-03-08 16:18:13 »

It is a perceived stationary point, I want a fixed speed relative to the ship, which is moving.

If I'm understanding your question correctly...

Store the bullet's position relative to the ship (so initial coordinates are (0,0)).  Bullet's velocity is independent of ship's velocity.  To find the bullet's "true" position just add the ship's current position.

Is that the sort of thing?
Simon

Wildern

Junior Devvie

 « Reply #4 - Posted 2010-03-08 16:59:32 »

Sort of, I don't want to have to do special bullet calculations every movement update separate from my existing object system.  I should be able to do a single calculation at time of fire to get the correct magnitude for the shot vector.

Let's say the center of the screen is 50 pixels away from any given corner.
I want my bullets to move at 10 pixels per second, so a shot at any corner should take 5 seconds to arrive.
Let's say the ship is moving towards the lower left corner at 20 pixels per second.
A shot towards the lower left corner would need to have 10 pixels per second added to it.
While a shot towards the upper right corner would need to have 30 pixels per second added to it.
And forcing the magnitude of the shot vector to always be the sum of the desired speed and the ship speed, doesn't really work either, though it is close.

I guess my problem stems from the fact that the desired vector is always changing based on the vector of the ship and the direction of fire.
 « Reply #5 - Posted 2010-03-08 17:03:40 »

Just dont move the ship?

Ok I guess it was a stupid comment.

If you want to make it look like the ship is not moving from the point of view of the shot.
Here is the solution :

Let suppose that :

- A shot have an initial speed and an angle of fire
- Each game step you move the ship and the shots

When you move a shot, take the velocity of the ship at this current game step and add it to the shot velocity. Then move the shot, then reset the shot speed to it's original one.
Wildern

Junior Devvie

 « Reply #6 - Posted 2010-03-08 17:11:38 »

The ship has to be able to move for the game to work, the playing field is much larger than the viewport.
dishmoth
 « Reply #7 - Posted 2010-03-08 18:22:20 »

I guess my problem stems from the fact that the desired vector is always changing based on the vector of the ship and the direction of fire.

Yes, if the velocity of the ship is changing then the behaviour of the bullets may look strange, particularly if the ship's speed can be faster than the bullet's speed (which looks to be the case for the numbers you're quoting).

For example, if the ship is moving right at 20 pixels per second (velocity (+20,0) relative to the map) and it fires a bullet to the left with a relative speed of 10 pixels per second, then the bullet's velocity relative to the map is (+10,0).  To the player this will look fine -- on the screen the bullet moves to the left at a speed of 10 pixels per second.  But relative to the map the bullet is actually moving to the right, only slower than the ship is.  So if the ship slows to a stop then the bullet catches it up and hits it.  Not what the player expects!

So using relative velocities may not give quite the effect you're expecting.  But then I still don't fully understand what it is you're doing.

Simon

Wildern

Junior Devvie

 « Reply #8 - Posted 2010-03-08 19:13:04 »

I am trying to replicate a very old game.  I suspect that game had special handling for shots in that they moved only in the viewport and not in the world.  The shots always moved at a constant speed and always straight in the direction of fire.

Currently, I am simply adding a fixed amount of thrust to the shot in the direction of fire.  Since the shot started out with the same velocity as the ship, this works OK in a line with the direction of the ships movement.  Shooting backwards results in slower shots than shooting forward and shooting at an angle to the line of movement results in the shot leaving the ship noticeably off from the desired shot direction.

I don't want it to matter how fast the ship is moving; I would like the shot travel to always look the same.  At this point, though, I would settle for the shot going in the correct direction.
 « Reply #9 - Posted 2010-03-08 19:23:53 »

Karmington

Senior Devvie

Medals: 1
Projects: 1

Co-op Freak

 « Reply #10 - Posted 2010-03-08 19:33:08 »

sounds like you really want to completely disconnect the ship and the shots:

consider the shots to be on their own screen layer which doesn't give a damn about
where the ship is flying.

Hitting enemies will have to take into account this screen-relative collision of course,
but you wont have shots wobbling about depending on which way you turn your ship.

dishmoth
 « Reply #11 - Posted 2010-03-08 20:04:11 »

Currently, I am simply adding a fixed amount of thrust to the shot in the direction of fire.  Since the shot started out with the same velocity as the ship, this works OK in a line with the direction of the ships movement.  Shooting backwards results in slower shots than shooting forward and shooting at an angle to the line of movement results in the shot leaving the ship noticeably off from the desired shot direction.

There seems to be an inconsistency here.  By "adding a fixed amount of thrust to the shot" I'm assuming you mean something like the following.  If the ship's velocity (moving right relative to the map) is (+20,0) and the magnitude of the thrust is 10, then a bullet fired to the right will have velocity (+30,0), a bullet fired to the left will have velocity (+10,0), and a bullet fired up will have velocity (+20,+10).  Unless the ship's velocity changes, the player will see the bullets move on the screen with speeds (+10,0), (-10,0) and (0,+10).

But from what you're saying, this isn't the case -- if you fire directly upwards the path of the bullet on screen appears to be at an angle.

If that's true then either the ship's velocity is changing (you're accelerating? turning?), or something's gone wrong with your calculation of the bullet's velocity (are you imposing a maximum speed on the bullet?), or your rule for moving the bullet is something other than "new_position = old_position + time_step * velocity" (the velocity of a bullet is constant, right?).

Simon

Wildern

Junior Devvie

 « Reply #12 - Posted 2010-03-08 20:07:47 »

@Gudradain - yes, I read your post.  I am really trying to avoid special handling of the shots after they have been fired.  With the short time to live on the shot and the inability to quickly reduce speed, it should be very, very hard to shoot yourself.

Maybe I need to subtract the movement vector from the shot vector and use the magnitude of that result as the magnitude of the shot vector.

@Karmington - yes, a completely separate layer would get me to where I want to be in terms of appearance, but I want to get there without special handling the shots/collision

@dishmoth - that is the case when the ship isn't moving, when the ship is moving, say (5,5) then you have (15,5) (-5,5) and (5,15)
h3ckboy

JGO Coder

Medals: 5

 « Reply #13 - Posted 2010-03-08 20:25:40 »

have you tried looking in the source of another astroids clone and finding the answer....
Wildern

Junior Devvie

 « Reply #14 - Posted 2010-03-08 20:34:17 »

Unfortunately, it isn't an asteroids clone, I just said Asteroids-ish.
In all of the asteroids games I have seen, the ship moves around the screen while the background stays stationary, and the field of play is the screen size.
In mine, the ship stays centered and viewport moves around the much larger playing field.
I said Asteroids-ish in that the controls are similar, you ship can turn, apply thrust, and fire.
Jono
 « Reply #15 - Posted 2010-03-08 21:08:14 »

It seems like it ought to "just work" if you are following the approach dishmoth described.

Perhaps one point of confusion could be the relationship between the world coordinates and the viewport. How do you handle this? Do the ship, bullets and other world objects all use the same coordinate space? Then at render time the view is translated so the ship is at the centre?

Maybe it's just time to go bug hunting...
Wildern

Junior Devvie

 « Reply #16 - Posted 2010-03-08 21:44:33 »

Yes, everything uses the same world coordinate space, and the view remains centered on the ship at render time.

I have been bug hunting as I thought that method should "just work" as well.

If you match speed/direction with an asteroid and attempt to shoot it from the side, you will always miss as the shot appears to leave from a different angle than the one you are aiming.  That part is hard to describe.  There are 32 angles you could turn the ship to and fire from.  The sideways shots, when moving fast enough, appear to come from one angle past the current ship angle and always leading the target.  The closer the angle of the ship matches line of travel, the less this error is.  So, it has to be something I am doing incorrectly with initial velocity of the shot that is getting magnified by the increased initial velocity imparted by the ship.
Karmington

Senior Devvie

Medals: 1
Projects: 1

Co-op Freak

 « Reply #17 - Posted 2010-03-08 22:51:42 »

time to do a screencap youtube video or applet test or something... lets see it in action?

CommanderKeith
 « Reply #18 - Posted 2010-03-09 01:11:38 »

So you want to add the ships velocity to the bullet, but not in a realistic way, because you want the bullet to hit where the mouse was cllicked (rather than at the angle of the mouse relative to the ship...?

SimonH
 « Reply #19 - Posted 2010-03-09 01:19:17 »

So you want to add the ships velocity to the bullet, but not in a realistic way, because you want the bullet to hit where the mouse was cllicked (rather than at the angle of the mouse relative to the ship...?
Lol! Beaten to it!
Don't forget the MVC thing:- Model, View, Controller.
Think in meters and seconds for the model and in pixels and fps for the view.

People make games and games make people
Wildern

Junior Devvie

 « Reply #20 - Posted 2010-03-09 02:16:20 »

If you look at the following image, the green line represents the direction the ship is actually moving.
The blue line is direction the ship is facing, and the direction I would like the shot to travel.
The red line, is the actual shot trajectory.

Jono
 « Reply #21 - Posted 2010-03-09 02:18:33 »

Edit:missed the latest post.

So in that picture the bullet's velocity is unrelated to the ship's velocity. Just don't add anything when you create the bullet..
Wildern

Junior Devvie

 « Reply #22 - Posted 2010-03-09 04:19:30 »

No, if I don't add the ship's velocity, it is much worse.
It needs to be a combination of the ship's vector and the shot vector, I am just not sure the combination.

Riven
« League of Dukes »

« JGO Overlord »

Medals: 959
Projects: 4
Exp: 16 years

 « Reply #23 - Posted 2010-03-09 06:56:44 »

Looks like you got the physics of ship-movement wrong, with multiple bugs canceling out eachother. The bullet physics in this case are so simple that if it doesn't work (and your last image shows that) then there must be a bug somewhere else. So take a few steps back, fix it, until the code makes sense (instead of: it appears to work), and then add the bullets.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Wildern

Junior Devvie

 « Reply #24 - Posted 2010-03-09 17:29:17 »

OK, I found a solution.

I needed to add the ship's movement vector with the shot's vector and then set that as the length of the shot's new vector while forcing the angle to be the desired firing angle.

Previously, I was starting with the shot moving the same as the ship and trying to apply a force to it in order to move it in the correct direction.

Just updating this post as this solution didn't work.  I needed to add the ship vector and the shot vector and make the resulting vector the shot's new vector.
Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #25 - Posted 2010-03-09 17:31:42 »

I haven't read anything except the posts with the pictures, so I'm pretty sure someone must have said this already.

But.

The ship's velocity does not matter. Let me emphasize it again. The ship's velocity? Yeah. It doesn't matter. You shouldn't be using it.

All you need is the ship's rotation.
 1  2 bulletVelX = cos(shipRotation) * bulletSpeed;bulletVelY = sin(shipRoation) * bulletSpeed;

Seriously, try that code out. It's correct.

If you were using the ship's velocity plus the rotation values, then the bullet would very weirdly continue to travel with the ship (if it maintained velocity) but still travel along whatever way you're pointing. Imagine a laser beam; it would stay attached to the front of the ship, or so appear to. That's not what you want. Say the ship is flying directly to the right, you turn it to the left (it will maintain its velocity to the right) then shoot a bullet. If the ship is going faster than bulletSpeed, then by adding the ship's velocity and the rotation values you would end up with a bullet traveling backwards.

[EDIT] I actually read a few posts. Okay, so you do in fact need the ship's velocity (so the ship can't overtake a bullet). But as mentioned above this creates problems if you turn and shoot to fire opposite your velocity. [/EDIT]

See my work:
OTC Software
Wildern

Junior Devvie

 « Reply #26 - Posted 2010-03-09 19:32:18 »

Actually, it was still behaving a little off, I needed to use the result of the vector addition.
Just add the two vectors and the new vector is the shot vector.
I could have sworn I had tried that first, but I must not have.

@DemonPants, no issues with firing backwards relative to ship movement.  While it is true that shot will be moving in the same direction as the ship if the ship is traveling faster than the shot speed, the ship cannot decelerate fast enough to get hit by its own shot.  Any enemy holding pace with or overtaking the ship from behind will still get hit by the shot.  Like throwing a tennis ball from the front seat of the car to the back, it still hits the back seat even though it is moving forward almost as fast as the car.
Riven
« League of Dukes »

« JGO Overlord »

Medals: 959
Projects: 4
Exp: 16 years

 « Reply #27 - Posted 2010-03-09 21:52:24 »

[EDIT] I actually read a few posts. Okay, so you do in fact need the ship's velocity (so the ship can't overtake a bullet).[/EDIT]
Indeed.

But as mentioned above this creates problems if you turn and shoot to fire opposite your velocity.
go inside an airplane, moving at 1000km/h, and shoot a bullet traveling 800km/h (?) from the tail to the nose of the plane. I can guarantee you, the bullet will not move towards you at 200km/h. You will not shoot yourself (if you are standing behind the gun, obviously). The velocity of the bullet relative to the object that fired it, at the instant of firing.

fire a handgun when standing still: the bullet travels at 800km/h forward, 0km/h sideways.
fire a handgun when driving your car at 60km/h: the bullet travels at 860km/h forward, 0km/h sideways.
fire a handgun when driving your car at 60km/h in reverse: the bullet travels at 740km/h forward, 0km/h sideways.
fire a handgun when walking/strafing to the left at 5km/h: the bullet travels at 800km/h forward, 5km/h sideways.

The INITIAL bullet velocity is ALWAYS: GUN_VELOCITY_3D + BULLET_VELOCITY_3D

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #28 - Posted 2010-03-10 15:25:58 »

The INITIAL bullet velocity is ALWAYS: GUN_VELOCITY_3D + BULLET_VELOCITY_3D

Well yeah if your bullet is moving much faster than your vehicle then this will be the case. And if I were in an airplane traveling -801 km/s and I fired the bullet towards our velocity so at 800 km/s, it would not come back to hit the place because I will still be going -801 km /s and so will pull away from it, but the bullet will appear to pretty much drop out of the air. No matter what its net velocity will be less than that of the plane so it won't catch up (unless you hit the brakes quickly).

That being said, I was referring more to a fictional environment, like this game: http://www.ambrosiasw.com/games/evn/ . In that game, it is in fact very possible for your ships to fly faster than your bullets, plus you're in a frictionless environment, so all that combining means the situation I mentioned should be able to happen. But, there's something tricky they did with their algorithm that appears to avoid it.

See my work:
OTC Software
Riven
« League of Dukes »

« JGO Overlord »

Medals: 959
Projects: 4
Exp: 16 years

 « Reply #29 - Posted 2010-03-10 15:38:47 »

Well yeah if your bullet is moving much faster than your vehicle then this will be the case.
it will always be the case, regardless of velocity.

And if I were in an airplane traveling -801 km/s and I fired the bullet towards our velocity so at 800 km/s, it would not come back to hit the place because I will still be going -801 km /s and so will pull away from it, but the bullet will appear to pretty much drop out of the air. No matter what its net velocity will be less than that of the plane so it won't catch up (unless you hit the brakes quickly).
If you hit the breaks quickly, it also won't be catching up, as both the speed of your bullet and you will be zero, but that would be nitpicking, right?

That being said, I was referring more to a fictional environment
Nobody in this thread was, and you certainly didn't mention it. In 'fictional physics' anything can happen, you could just as well posted a solution using the square root of *something*.

Anyway, the math of shooting bullets is extremely simple:
 1  2  3  4 bullet.position.x = gun.position.xbullet.position.y = gun.position.ybullet.velocity.x = gun.velocity.x + cos(gun.rotation) * bullet.initalSpeedbullet.velocity.y = gun.velocity.y + sin(gun.rotation) * bullet.initalSpeed

this will always be correct, until you approach the speed of light.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Pages: [1] 2
 ignore  |  Print

You cannot reply to this message, because it is very, very old.

 Waterwolf (20 views) 2015-05-20 15:01:45 chrislo27 (24 views) 2015-05-20 03:42:21 BurntPizza (58 views) 2015-05-10 15:53:18 FrozenShade (44 views) 2015-05-07 09:11:21 TheLopais (208 views) 2015-05-06 13:36:48 TheLopais (191 views) 2015-05-06 13:35:14 TheLopais (198 views) 2015-05-06 13:33:39 TheLopais (214 views) 2015-05-06 13:32:48 TheLopais (214 views) 2015-05-06 13:31:28 ClaasJG (236 views) 2015-04-30 20:33:25
 Spasi 31x BurntPizza 16x DavidBVal 13x theagentd 13x ra4king 12x EgonOlsen 11x Husk 10x KevinWorkman 9x scanevaro 8x princec 8x KaiHH 7x Riven 6x opiop65 6x revers 6x SauronWatchesYou 5x Drenius 5x
 List of Learning Resources2015-05-05 10:20:32How to: JGO Wikiby Mac702015-02-17 20:56:162D Dynamic Lighting2015-01-01 20:25:42How do I start Java Game Development?by gouessej2014-12-27 19:41:21Resources for WIP gamesby kpars2014-12-18 10:26:14Understanding relations between setOrigin, setScale and setPosition in libGdx2014-10-09 22:35:00Definite guide to supporting multiple device resolutions on Android (2014)2014-10-02 22:36:02List of Learning Resources2014-08-16 10:40:00
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org