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.

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.

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.

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.

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.

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.

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?).

@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)

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.

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?

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.

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...?

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.

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.

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.

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]

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.

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.

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.

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?

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